CEMBTW

@letterafterz , a good way to narrow down possible problems would be to just select 2 or 3 images in the media library and use the “Bulk Actions” > “Bulk Optimizer” here instead of for the whole library.

Also (per the “The scanner is too slow!” section of the article @nosilver4u linked), check if your optimization history seems to be very large.

…and the reason I stopped by this thread is that I’m having the same experience:
– Noticed that only the main image was now being converted to .webp, not the thumbnails (I only use this plugin for .webp conversion). Some thumbnail sizes also appear to never have been converted, but now it’s all of them.
– Bulk optimization endlessly spins on Stage 2, even when only 2 base images are being converted. No console or logged errors.
– Optimization history is <300 files overall.

Though I did not see the initial error @aminsoltani referred to, the latter error is ballooning our error logs after the recent update, as well.

This wouldn’t have crashed your site (it’s just a warning), but you will receive these warnings (and others about using array_key_exists() on objects) until either:
1) time.ly updates with 7.4 support
2) You manually update their code (for the warning you cited, you can just change braces to brackets)
3) You change your error reporting settings.

• This reply was modified 4 years, 11 months ago by CEMBTW.
• This reply was modified 4 years, 11 months ago by CEMBTW.

I’m referring to the fact that now, on a search for “ABC” in 404s, the “Delete All” button no longer changes to “Delete all 404s Matching ABC”—a very useful feature—as before.

So now the quickest way to remove all 404s matching a query is page by page.

Was looking for this information, as well. (And thanks to Jesse for providing a link.)

Turn your redirect back on and test it here: https://redirectcheck.com/index.php to see what is actually happening.

Odds are your target url is also matched by your source url, causing an endless loop.

It’s working correctly. The problem is that your target URL is also a match for your your source regex, so it just keeps on redirecting.

Play around with this test tool:
https://regex101.com/

Think about the possible permutations of the url you want to match and type them in the “Test String” section (leave off your domain), and put your target url in the “Substitution” section.

For example, \/author\/(\w*)$ will match “/author/my_userNAME” and will not match the redirected “/author/my_userNAME?type=ads”.

But you also have to think about things like: What characters are allowed in my author names? Do I need to account for trailing slashes? etc., account for those cases in your Test Strings, and rework your regex as needed.

• This reply was modified 6 years, 9 months ago by CEMBTW.

Go look at your server logs. There’s a good chance those requests were already being made, only now have a more visible record of it.

(Also, get something like Wordfence.)

Found the issue. I use the Plugin Organizer plugin to keep some backend plugins, etc. from loading unnecessarily across the site. I thought that a logged-in user, on the backend, would not need Regenerate Thumbnails globally enabled to reach those endpoints. I was wrong.

Everything now working as intended.

Those Apple devices are trying to find icons to represent your site, like a browser looking for favicon.ico. (Windows 8/Phone does the same thing, except different filenames/dimensions.) You can use a plugin like OS Integration or manually upload some.

While there was a cached response that query by this time (I’ve deleted it and excluded /wp-json/), deactivating my caching plugin didn’t fix it. I also tried deactivating anything related to security, plugin loading, REST, etc., without effect. I also re-saved permalink structure (since it’s a 404 error) just in case.

Queries like /wp-json/v2/posts/ and /wp-json/wp/v2/media/ work. Is there a troubleshooting path you can recommend?

I’m using WordPress 4.9.4 and Regenerate Thumbnails 3.0.2.

Regex redirects have capture groups that can be passed to the desired destination.

So a structure like: /oldmembers/myusername/oldposts/ could have a regex like: ^\/oldmembers\/(.*)\/oldposts\/$.

That part in parentheses (now stored as $1—subsequent groups would be $2, $3, etc.) would be called in your destination like: /newmembers/$1/newposts/.

Click the ^ arrow next to “Substitute” here to test them out. https://regex101.com

• This reply was modified 7 years ago by CEMBTW.
• This reply was modified 7 years ago by CEMBTW.

The part to be replaced, /worksop, is also found in your destination URL, thus the infinite redirect (you can see the redirection step-by-step here: https://redirectcheck.com/index.php)

If the /worksop to be redirected is always at the end of the URL, as in your example, you could use an end-of-line token to only match that string at the terminus of a URL: \/worksop$.

Try it out here: https://regex101.com/ and also think whether there would be any unintended effect on other pages.

You want to keep that dynamic part in the destination, or just want it accounted for and caught by the regex?

Do any of your redirects have a hyphen in them?

Is it only one IP repeatedly asking for the same resource?

Any hints from the referring URL?