Morten Ross
Forum Replies Created
-
Forum: Everything else WordPress
In reply to: Set lang attribute based on post tagI’ve sent you the link to the theme via fullworks.net
Forum: Everything else WordPress
In reply to: Set lang attribute based on post tagI haven’t found such a repository. Yes, it’s Aperture.
Forum: Everything else WordPress
In reply to: Set lang attribute based on post tagI’m not a coder, so writing code is a no for the most part.
It’s an old Wootheme, no longer supported, and language_attributes() is not utilized in code.
That said I don’t see how this function is utilizing tag as a condition for setting the lang attribute. It looks more like the input is the locale setting of the OS/browser, which is not what I need.
Forum: Fixing WordPress
In reply to: Filtering on tag and category simultaneouslyHi Farhan,
Many thanks for your constructive input. I have previously tested Search & Filter and discarded it, but based on your input I’ve purchased the premium version, which does the trick! They respond quickly to support tickets as well, which is definitely a premium feature/expectation.
Morten
Forum: Fixing WordPress
In reply to: Href missing in image linksI have a mirror/staging site where this is not present, nor possible to reproduce, so there is a condition that occurs which resets this, but I don’t know what that condition is. On live site I’ve had to add
//The picture is connected to the media file by default (original link) update_option ( 'image_default_link_type' , 'file' ) ;to the functions.php to force the setting to link image to file. But as I don’t have this in functions.php for staging site it points out an inconsistency in the enforcement this particular setting.
I’ve found several posts regarding this that point to the default behavior of linking to image is not static. There are many scenarios with linking to image that point to an underlying issue with fully controlling the setting to always using link to file.
- This reply was modified 4 years, 5 months ago by Morten Ross.
Forum: Reviews
In reply to: [Disqus Comment System] It doesn’t work anymore | 2020/21Confirmed!
I’ve used Disqus for many years, but no more.
I wondered why comments were nowhere to be found – searched through my email and found them. Deactivated Disqus, and there they were.
I’ve deactivate all plugins except Disqus, and comments are still not showing, so there’s no plugin conflict. All the missing comments were submitted using the plugin, but with 2 years of only WordPress updating, the plugin is obsolete.
Disqus is dead.
Mowing on to wpDiscuz.
Forum: Plugins
In reply to: [LiteSpeed Cache] Lots of 404s from Google crawlerHi,
The problem is that you’re allowing anything in the field. There is no validation of the field. If there is requirement for the input, the entered input should be verified against requirements, before it’s allowed to be saved. This is pretty basic.
Thus, you welcome users to enter whatever they judge to be required, and they deem the input to be verified when the save is completed without any error. The fact that you’re not even verifying whether there’s a missing trailing / is worrying, when the end result will be a disaster.
Best practice is to validate input by user against the underlying rules and requirement before save/commit.
It should not be up to the user to interpret or foresee what each and every input field in any given UI require, as one UI might correctly add the full prefix and trailing / if missing, whilst another simply accepts whatever the user types into the field.
Furthermore – by allowing anything in the input field, search engine bots are still crawling garbage urls with cdn.ross.no in them, and you’ve not produced anything concrete as to where these urls reside. They must be somewhere as the bots are unable to crawl non-existing links. Some edge servers must still contain these incorrect urls, that normally would be obsoleted/erased were they properly formatted.
M
Forum: Plugins
In reply to: [LiteSpeed Cache] Lots of 404s from Google crawlerHi,
Yes, this is confirming the problem.
M
Forum: Plugins
In reply to: [LiteSpeed Cache] Lots of 404s from Google crawlerHi,
Report number: ULHIHHXJ
Report date: 12/27/2020 23:27:45M
Forum: Plugins
In reply to: [LiteSpeed Cache] Lots of 404s from Google crawlerHi,
Yes.
Also notice the rewrite of the rewritten, making the xcdn duplicated:
12/23/20 02:32:24.020 [93.184.119.203:53456 1 ovQ] [CDN] -fill before rewritten: https://www.ross.no/staging/xcdn.ross.nowp-content/2016/03/20160306-DSC_1446-1a1.jpg
12/23/20 02:32:24.020 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.noxcdn.ross.nowp-content/2016/03/20160306-DSC_1446-1a1.jpgThere is also a mix of utilizing http:// instead of https:// for the rewrite of the rewritten url:
12/23/20 02:32:24.521 [93.184.119.203:53456 1 ovQ] [CDN] rewrite http://xcdn.ross.noxcdn.ross.nowp-content/2016/03/20160307-DSC_0463-1a1-220×150.jpg
Forum: Plugins
In reply to: [LiteSpeed Cache] Lots of 404s from Google crawlerHi,
Excerpt from rewrites:
12/23/20 02:32:24.020 [93.184.119.203:53456 1 ovQ] [CDN] -fill before rewritten: https://www.ross.no/staging/xcdn.ross.nowp-content/2016/03/20160306-DSC_1446-1a1.jpg
12/23/20 02:32:24.020 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.noxcdn.ross.nowp-content/2016/03/20160306-DSC_1446-1a1.jpg
12/23/20 02:32:24.500 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://www.ross.no/staging/wp-content/2016/03/20160306-DSC_1539-1a-700×466.jpg
12/23/20 02:32:24.501 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.nowp-content/2016/03/20160306-DSC_1539-1a-700×466.jpg
12/23/20 02:32:24.501 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://www.ross.no/staging/wp-content/2016/03/20160306-DSC_1539-1a-768×511.jpg
12/23/20 02:32:24.501 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.nowp-content/2016/03/20160306-DSC_1539-1a-768×511.jpg
12/23/20 02:32:24.501 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://www.ross.no/staging/wp-content/2016/03/20160306-DSC_1539-1a-1024×681.jpg
12/23/20 02:32:24.502 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.nowp-content/2016/03/20160306-DSC_1539-1a-1024×681.jpg
12/23/20 02:32:24.502 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://www.ross.no/staging/wp-content/2016/03/20160306-DSC_1539-1a-900×599.jpg
12/23/20 02:32:24.502 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.nowp-content/2016/03/20160306-DSC_1539-1a-900×599.jpg
12/23/20 02:32:24.502 [93.184.119.203:53456 1 ovQ] [CDN] rewrite https://www.ross.no/staging/wp-content/2016/03/20160306-DSC_1539-1a.jpg
12/23/20 02:32:24.503 [93.184.119.203:53456 1 ovQ] [CDN] -rewritten: xcdn.ross.nowp-content/2016/03/20160306-DSC_1539-1a.jpgAnd here’s the duplication of the address:
12/23/20 02:32:24.521 [93.184.119.203:53456 1 ovQ] [CDN] rewrite http://xcdn.ross.noxcdn.ross.nowp-content/2016/03/20160307-DSC_0463-1a1-220×150.jpg
12/23/20 02:32:24.521 [93.184.119.203:53456 1 ovQ] [CDN] -rewrite failed: path not match: wp-content
12/23/20 02:32:24.521 [93.184.119.203:53456 1 ovQ] [CDN] rewrite http://xcdn.ross.noxcdn.ross.nowp-content/2016/03/20160306-DSC_9898-1a1-220×150.jpg
12/23/20 02:32:24.522 [93.184.119.203:53456 1 ovQ] [CDN] -rewrite failed: path not match: wp-contentM
- This reply was modified 5 years, 6 months ago by Morten Ross.
- This reply was modified 5 years, 6 months ago by Morten Ross.
Forum: Plugins
In reply to: [LiteSpeed Cache] Mobile theme goes desktop on mobileHi,
>you mean if you disable mobile cache , then this issue no longer happens ?
Yes, that correct.
M
Forum: Plugins
In reply to: [LiteSpeed Cache] Lots of 404s from Google crawlerHi,
Before I’m willing to try that on live site, I need to resolve the garbage urls causing 404.
If I retry, and experience a new set of bad urls that don’t get removed, then I will have two sets of bad urls crawled by search engines and filling up the log.
I used cname on previous setup, but I moved server to get Litespeed, and cname setup (flattening) is not possible on my current isp/server, so the test (using QUIC.cloud DNS), will not be the same as the past one that has failed.
M
Forum: Plugins
In reply to: [LiteSpeed Cache] Lots of 404s from Google crawlerYou requested the log, I attached it. Did you look at it?
4686 404 errors since 1 November. It’s not showing any signs of slowing down.I would not have opened this ticket if anything of what your say in your latest response was working as designed/expected. I have used your services, and it has resulted in a barrage of 404s that did not exist prior to using this plugin/cloud service. The expected result is that when the cloud service is purged/closed, the incorrect urls would cease to exist. That has not happened. The current Lqip is at 0%, but there might have been something left in the previous profile, which was deleted. I created a new domainID and profile.
There is no local reference to cdn.ross.no, as I have purged weeks ago. Nor has there ever been any in the db. If there were references in db I would also not open a ticket here, as I would have done a search and replace and be rid of the problem.
Furthermore: You state that the correct cdn formatting is “https://cdn.exmaple.com/”
The urls requested/crawled are formatted with the cdn in the middle of the url:
/category/plants/cdn.ross.no/wp-content/2017/04/20170414-DSC_6271-4-82-1a-1.4-144×144.jpgwhich means that even if the correct url format was used – e.g.:https://cdn.exmaple.com/
That would have ended up with this url:
/category/plants/https://cdn.exmaple.com//wp-content/2017/04/20170414-DSC_6271-4-82-1a-1.4-144×144.jpg
It should have looked like this:
https://cdn.exmaple.com//category/plants/wp-content/2017/04/20170414-DSC_6271-4-82-1a-1.4-144×144.jpgSo there are two problems here:
1: the injection of the cdn url in the middle of the correct non-cdn/original url – this will never be a working url
2: the lingering of the badly formatted url leading to the 404As the UI accepts any text in the “CDN URL” field in CDN Settings, this could also have been Morten.Ross.org, which in turn would produce this URL:
/category/plantsMorten.Ross.orgwp-content/2017/04/20170414-DSC_6271-4-82-1a-1.4-144×144.jpg
As this input is accepted by the plugin, the question is where this is propagated and how it is dealt with when it further along the cdn-process fails. How does the code validate the saved and incorrect URL, and how is the error handled when it is eventually executed and generates a non-functional destination?
Bingbot and googlebot have found these incorrect urls at one time and are still utilizing them incessantly. These do not show up as 404s in the Webmaster tools, so I cannot control them there. Instead my log is filling up with 404s.
I understand how this should be working, but when it doesn’t, it’s necessary to trace and debug to find out what has actually happened.
The cause is the plugin.
M
Forum: Plugins
In reply to: [LiteSpeed Cache] Lots of 404s from Google crawlerBetween me and you is cloud, QUIC.cloud being the one involved in accepting and maintaining the creation and usage of cdn.ross.no.
