Search results

Anything if the guts of the methods are wrapped in try/catch? public function handleScriptLoaderTag($tag, $handle, $src) { try { if (is_string($src) && strlen($src) > 3) { $this->preload['<' . sanitize_url($src) . '>;as=script;rel=preload']...

Okay... one last test (hopefully). If you uncomment those two lines, and also replace the handleScriptLoaderTag and handleStyleLoaderTag methods farther down that file (approx line #223) with this: public function handleScriptLoaderTag($tag, $handle, $src) { if (is_string($src)...

I've been digging and trying to think of various "what if" situations. One possibility I've come up with (and would cause an issue regardless if the new option was enabled or not) would be an invalid script or CSS URL came through WordPress's filter mechanism. It's *supposed* to be a string, but...

May be as easy as adding this to your config.php file once it's ready: define('WP_DEBUG', true); https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/ Did I mention how much I hate that I can't replicate it? 😂

Augh... sorry for all the testing (feel free to not do anything). I really wish I was able to replicate it somehow. In the wp-content/plugins/app-for-cf/src/DigitalPoint/Cloudflare/Base/Pub.php file, if you just remove these lines (around line #20): $cloudflareRepo = new...

Ok... so not that. Did you enable the new option (preload resources)? With that enabled, it does trigger an ob_start() call so any output is buffered (allows us to add the necessary preload header after WordPress generates it's content). So maybe something going on with ob_start(), but that...

Okay, so not that... 🤔 Not sure how willing you are to test things, but unfortunately I'm not able to since I can't come up with a PHP/web server combo that causes any issues. But if you are... If you make a new file on your server with this (can name it test.php or anything really): <?php...

One thought that just came to mind (and maybe why I'm unable to replicate it). It could be that some servers have certain PHP functions/classes explicitly disabled (ones that are being used). Any chance you could check to see if your phpinfo shows anything for disable_functions or disable_classes?

Still haven't been able to replicate this on our end no matter the setup/config I try. I did find some old references to stacking ob_start() being problematic when a PHP is using an internal output handler that doesn't support stacking. Not sure if this is what's going on since I haven't been...

What version of PHP are you using? Do you happen to have access to error log so you could see exactly what the error is? There really isn't a whole lot that changed with the update.

Uninstalling the plugin is the same as disabling R2 in settings (the site wouldn't know anything about R2). URLs would go back to WordPress default. But yes, if you are going to do that, you'll want to move the images back to the local filesystem first.

You could use any tool that supports the standard S3 protocol to download/delete/upload, etc. in bulk. The one I see most people using is rclone. It has a lot of options (because it can do a lot of stuff). I haven't personally used it because I've never needed to move things around a bucket in...

The R2 settings page has the Migrate existing media button. That lets you go both directions (from local to R2, but also from R2 back to local). Can also do it with WP-CLI (both directions).

You can move individual media to/from R2 by clicking on it in the Media browser, then at the bottom hit the Edit more details link. If it’s a situation where the media’s metadata is corrupt somehow, moving it back to local isn’t going to fix it because the plugin doesn’t alter/edit metadata...

If you have multiple plugins doing image transforms when an image is being uploaded, it's probably best to pick one and use just that. For example if you have a plugin you like that is already doing WebP transformations, there's no need to transform it again with the option in the App for...

The file type as registered in the metadata isn't something the plugin needs to look at in order to generate the srcset URLs, so it wouldn't be that. That being said, it does seem strange that file type in the metadata was incorrect, but then correct when you reuploaded. Makes me wonder if you...

Is it only certain media images? There is some internal logic to determine if a srcset URL should be transformed or not. It goes through this (in this order): Is there a R2 media bucket set Is there an external URL set for the bucket (the public domain) Is the image flagged as being in R2 Is...

Hmmm... well glad it's working. But also, even if an object cache evicts something on it's own, it *should* return data as if that object is missing, so not sure why it seems to be returning something different if it's missing vs. evicted. 🤔

It does sound like that might be the case (something going on with the Redis server itself) if multiple object cache mechanisms are doing the same thing. Are you able to restart Redis to see if things start working as expected immediately after a restart? If possible, check some of the settings...

Just as a test, if you disable the Redis object cache (you could probably just rename the wp-content/object-cache.php file since it "existing" is what normally has WordPress use an object cache), does everything work as expected? WordPress object caches cache all the WordPress options/settings...