nosilver4u

It should, though I’ve never used R2 myself. See https://docs.ewww.io/article/22-how-to-use-s3-image-optimizer for instructions regarding custom endpoints and all that.

FRT needs a (local and absolute) file path, not a URL, as FRT cannot operate on URLs, and you need to download the original from the CDN URL to that local path, all within the function you’ve hooked onto the regenerate_thumbs_original_image filter.

See this for an example: https://github.com/nosilver4u/ewww-image-optimizer/blob/5dfc9a4f901c0f852ecccc7709207ec15886c7c4/common.php#L7121

Of course, you don’t need all of that, but it should get you going in the right direction.

Just a quick follow-up, as we’d never recommend replacing existing images with the same name. That’s prone to all sorts of issues with caching, both server side and browser-based, so folks may end up seeing your old images even months after you replaced them.

Forgot to say, the exact line in wp-config.php should be this:

define( 'SCRIPT_DEBUG', true );

Thanks for reporting that, a lot changed in 7.2 though, as the script was completely reworked at that point.

It’s a bit difficult to match up the error, as character 6864 in the original source has nothing to do with a variable named ‘w’. I would recommend the following:

1. Make sure you do not have anything altering lazysizes.min.js. That is, turn off any plugins that would minify JS. The file should be exactly 15,853 characters long.
2. If the issue persists, set the SCRIPT_DEBUG constant in your wp-config.php, and see what the error shows then. We should have a proper line number to reference then (assuming nothing else is trying to minify JS still).
3. Add the site URL where we can see the issue in action.

Hi, that’s a great question! Instead of a CDN URL though, you must provide a local path. So what you can do in that function is download the original image to the local path–would be fine to keep it in the same location. Then use the regenerate_thumbs_post_update action to upload the new thumbs to your CDN and remove the original and thumbs from local storage.

Now, I’m not 100% sure what the plugin will display for results, as it will attempt to check which thumbs were generated after regenerate_thumbs_post_update, and if you’ve removed them, then that will fail. But the regen process itself should work fine, it just might display something that makes it seem like there were failures. You’ll just need to check manually that the thumbs made it to your CDN.

Just released the update to address these issues.

Fixing nonce expiration and resumability for FRT is next on my todo list. I’ll be starting on it either this week or next!

Aha, glad you found the issue!

That does not appear to be an error generated by Force Regenerate Thumbnails itself, and I’m having a hard time pinning down where else it could come from.

Can you provide a screenshot of the error?

Sorry for missing this! As I mentioned in the review, that’s something I’ll be working on soon, but I can’t think of any way around those issues at the moment.

Thanks for your feedback, it’s good to hear what else people need in FRT!

I’d note, if you need to disable thumbs, you can do so with our EWWW Image Optimizer plugin. We haven’t had a lot of other requests for that ability specifically in FRT, but that’s not a bad idea at all!

You’re definitely right about the “resumability” issues, and that’s something I’ll be working on within the next couple months. The expiration has to do with WP’s nonces expiring sometime between 24-48 hours, and I have a fix for that in EWWW IO which I’ll be porting over to FRT. Both are in my queue to work on soon!

I would actually love to see those questions (you can email them via https://ewww.io/contact-us/), but would also point out that we just released an “agency mode” last week which should remove just about anything like that (unless we missed something). Define EWWWIO_WHITELABEL anywhere or use the ‘ewwwio_whitelabel’ filter to enable it.

Hi @wolfganghammersmith,

I can assure you EWWW IO hasn’t been sold, and we have been providing premium services within EWWW IO since the fall of 2013 that make it possible for me to work on the plugin full time (since 2017). With over a million users, 99% of which use the plugin for free, I’ve also hired Adam to help with customer support, and so it takes a good deal of money to keep this ship sailing ??

In addition to the “original” free functionality, a lot has been added over the years. Notably, a few years ago, we added free lossless compression for JPG images via the API for folks on “exec-deprived servers”. Even better, that’s available for unlimited sites and unlimited images at zero cost, so our API compresses millions of images for free every single day. This is only possible because some folks choose to pay for premium features, and I’m greatly appreciative of that fact.

I’m sorry if you feel like we are “nagging” or trying to trick folks into paying for the API or CDN vs. using the local features. That is certainly not our intent, as all notices are dismissible, and include links to the docs regarding exec() or how to install/compile the local binaries.

I try to balance our marketing efforts so that they aren’t too aggressive, but I won’t apologize for making money for what we do either. We strive to offer the best support and help folks make their website faster, and we get constant confirmation that we’re accomplishing those goals. You can support us, or find somewhere you like better, that’s up to you!

Hi John,

I’m not sure that’s really feasible with this plugin. Presumably, you want thumbnails to make theme/plugin images responsive, but for that you’d need control over the HTML the theme is generating. Plus, the thumbs would have to be re-generated every time you update your theme or an affected plugin. Sounds like a mess, though I know technically it IS possible, because we have tools to optimize images within themes/plugins in our EWWW Image Optimizer plugin.

If you’re just using theme-provided images in content that you are building or HTML you can alter, then I’d download those images, and re-upload them into the media library. Otherwise, we’re back to figuring out how one is going to get the theme (or a plugin) to generate responsive img HTML.

If this is HTML you can’t control then, I’d ask the theme (and plugins) to start using responsive image markup for front-end images. But there is potentially one other option! I don’t know if this would work for you, but our EWWW Image Optimizer plugin has a CDN function that works with lazy loading to make ANY img elements responsive. It works by loading a placeholder, checking to see what size of image is needed, and then requesting that exact size from our CDN. It even works with some CSS background images too, if you have anything like that.