Morten Ross

Many thanks for your time, and sorry you have been unsuccessful in reproducing. My issue here is that I’m not a coder, and simply forward what the theme developers communicate. The issue is that with all these images failing generates huge CPU spikes on server, as every time a user scroll the Portfolio these images are recreated for the session, and not read from previous generation as it is expected to, as WP fails to properly either skip the check, or deliver what is expected. This should only happen once, in the first browse of the images. The theme developer declined to open a ticket as they claim they have never seen this with other clients, and it is not a bug in their theme, thus I’m in the middle trying to explain.

I have also activated the 2025 theme on staging.ross.no, but as this issue only happens in archives or photostreams, I’m unable to see the false output by the function. So this never is a problem in post view, only on homepage archive view and photostreams. But when I navigate to a category the post with error belongs to, I don’t see the output to screen, nor find it in (srcset) Inspector, so where is the output?

Don’t know how I missed the date difference – thanks for pointing that out!

That said I don’t now why Google Search Console is reporting a redirect error for this page, as that is the reason I opened this ticket. I have other posts that have a legitimate change in the date, which are indexed, and the old date/url is listed in User-declared canonical.

How to return 410, so Google will remove it from Search Console Redirect error property without having to install a plugin for it?

Thanks for your update. I can provide access to my lab so you can see what happens with the filter functionality when your query_vars is active, and get a better idea of what’s going on. I might have overlooked something you’d see right away.

I’m no coder, I need help in the debug process. As you can confirm the issue, how can this be escalated to WP development team?

I would also need a workaround until this is resolved.

Crawling activity is excessive due to this, and indexing of posts severely delayed (by months) due to the excessive crawl redirects. Google Search Console crawl stats is now reporting a whopping 40% responds with 301 vs just 60% with 200, which should be near 99%. Soon the 301 will overtake as the majority response, which is a huge problem.

As this is a core WP problem we need to properly address the issue with steps to reproduce and addressed by WP developers.

I’m on Windows 10, ImageMagick 7.1.1-31 Q16-HDRI x64, and apparently it is quite a bit less straightforward to set up than on linux.

Your confirmation of it working on PHP 8.3 made me look more extensively, and it paid off. Thanks for your input!

I don’t see how this plugin is regenerating the posts count for the categories, as it focused on reordering and ranking (I have installed it and saw nothing in regards to the regenerating of counts). I just want to regenerate the posts count in tags and categories to the actual number of posts.

I’ve found this wp-cli command that seemingly addresses the issue (but wp-cli is not installed on my hosting):

https://silicondales.com/tutorials/wordpress/tutorial-use-wp-cli-recount-wordpress-taxonomy-terms/

So how is it possible to correct this?

What made me not think of color profile issues, is that this is the same image, same browser, uploaded a second time, with Imagick off/on. But when I saved every instance of before/after Imagick, the images are identical on disk. However in different browser windows (Firefox in this case), the same image appear different. In any case, Imagick is cleared of any wrongdoings.

Many thanks for your input!