Paraphrasing an idea put forward for Magento sites...
The staging area is useless for us at the moment as our users constantly post and sell products, so by the time we have finished work on the staging site updating pages there have been new products added, products sold and so on...this means we cannot merge the staging site with live as it overwrites the orders and products in the database.

An option to exclude data specific to users, products, sales, etc, would be most welcome, so that we could push page layout and interface developments without affecting other content of the website.

Looking forward to a future implementation of this feature.
Keep up the good work!

When using a WordPress plugin like WebP Express (https://wordpress.org/plugins/webp-express/) or ewww.io, they are using an htaccess rule to redirect browsers that support webp images to the corresponding webp image files. This however does not work out of the box on Cloudways due to Cloudways' Nginx vhost.

Currently, I need to contact Cloudways for each application I want to add support for webp images to exclude images from the Nginx vhost. After that, the htaccess rules work correctly. This is also described by ewww: https://docs.ewww.io/article/16-ewww-io-and-webp-images

Can you please give us control of excluding images from the Nginx vhost ourselves? This would save your support and us much time.

Thank you for considering.

This is about the "Breeze" cache plugin for Wordpress, which is by the way amazing!

There is just one thing that is really annoying, that most of other cache plugin do. There is no option to purge the cache only for a specific page. With other cache plugin, it's possible to do it from the Wordpress bar at the top of the page and that's great to force refreshing a page for users, without having to delete the whole cache, thus slowing down the whole website for users during some time.

Thank you for the great work and best regards, David

From Wordfence:
We tested this issue using the Breeze plugin and found two problems.

This affects Wordfence’s two-factor authentication, if one or more users has set up two-factor authentication, and the reCAPTCHA feature, so using either or both of those features would be broken by Breeze modifying our script tags.

In Breeze’s “Advanced Options”, under “Delay JS inline scripts”, you can remove the line that says “nonce” to avoid having our script deferred.

You will also need to turn off the “JS” option under “Minifcation” in Breeze’s settings. We don’t know why they are modifying our script tag when minification is off but not on, but they have removed parameters that are necessary when loading Google’s api.js file.

Enabling JS minification may work on your site, but that has the potential to break other scripts. You can try it if you like, but be sure to test your site’s functionality if you do. Otherwise, we recommend disabling Breeze temporarily, until their next release that may fix these new issues.

Me: I tried the above suggestion which did not work. Cloudways have downgraded Breeze to an earlier version for me.

Can you please fix the compatibility issue.

Thank you

You can unlock your Yahoo email account password by following the mentioned simple steps;
At first, you have to open the browser page on your PC & go to the Yahoo account sign-in page
There in you will click on the trouble signing in option.
Now you will have to enter the Yahoo sign-in linked phone number in the field.
Now you will receive the verification code & you have to enter the code into the verification field & click on continue.
At last, you will get the Yahoo password page wherein you will need to enter the new password & get into your account with new credentials.

visit: https://www.instanttfn.com/blog/how-to-unlock-yahoo-email-account

There is an issue on servers configured by Cloudways, in which the PHP-FPM log buffer (error msg length) is set to 1028 bytes. This is too short for many errors messages generated by Wordpress.

It results in many entries of:
"Message":"AH01071: Got error 'the log buffer is full (1024). The access log request has been truncated.'"

In the PHP error logs views in Application Manager. So rather than seeing the actual error, you end up just seeing this message. Which is, obviously, very unhelpful.

Apparently it's due to the setting of log_limit setting in PHP-FPM, complied with Nginx.
You can read about this here: https://serverfault.com/questions/256459/nginx-php-fpm-long-log-lines-get-truncated

PHP-FPM will need to re recompiled with a patch. See here https://forums.freebsd.org/threads/howto-stop-nginx-php-fpm-from-truncating-your-stack-trace-error-message.56543/

Anyway... I found a workaround solution is to add the following to the PHP Advanced Settings on the Application:

phpadminvalue[logerrorsmax_len] = 2048

Once that is added, property (and useful) error messages are now accessible in the error logs.

I suggest Cloudways either compile PHP-FPM with a higher log_limit, or implement the PHP change I've mentioned, by default on all applications. This would save the customer from having to deal with this issue.

Regards,

Jonathan