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

The cpanel currently accepts configuration values for SMTP that get carried through to postfix (or whatever), but do not allow us to set a custom From: header. As a result, nearly every SMTP relay will reject the message.

Workarounds include generating email from PHP (usually via PHPMailer) or on the command line using mail -r "from@example.com". However by default, without any workaround, email generated by the system (such as using the MAILTO= in a crontab) will simply fail.

I've not encountered a server stack before that takes in SMTP configuration for the server but fails to take in all values needed to actually deliver system-generated outbound mail without a workaround. It seems like it would be a useful baseline for the stack that outbound mail works "out of the box" at the OS level.

Currently, new sites cannot be created with the development user/pass UI for adding a username and password to access the site. When you are developing a new site it is important to keep it from being crawled by search engines, so it needs to be behind password protection. right now the only way to accomplish this is to either edit the htaccess file or else install a maintenance plugin.

Specifically, I wanted to create a Staging site from a site that is currently hosted on a server that has an older database. My development server has the latest versions of PHP and of the DB software, but the landing page was created on a site that isn't upgraded. One of the sites on that source server is old and I don't want to deal with upgrading it right now. So I am having to clone the other sites to one of my non-upgraded servers, upgrade that one, then clone it again to my dev server in order to get the user/password option. Because not all the users in my company will be well versed in such things as htaccess files, I feel it's a bad practice to use htaccess for this purpose.

You could add the option to create a new site as a staging site, or else just add a UI to put a user/pass on the site as you are developing it. That would be a great new feature.

We're experiencing very long wait times for staging site creation and would love to know how to speed it up. Some other ideas here, like selective updating of the staging site, could also help, but I thought this idea would also be good for us.

The idea is to log when each part of the process starts — either in something that Cloudways employees can see or that the users can see. Perhaps they could even be added to the Deployment Logs.

Often with processes that take a long time, an app will show progress or at least tell you what it is doing now. Knowing that it's not hanging could help decrease the pull on your live chat, which we've messaged twice now to see what is going on. :)

If the Deployment logs could show start and end times of the entire process, that would also help.