Just today WordPress asked me to enter FTP Credetials to proceed after I adjusted an image using the Jupiter interface for header images. This had never happened before on any Trellis setup of mine.
FTP Credentials Needed
The full error message was on a very basic page with the fields to enter the ftp user and password:
Connection Information To perform the requested action, WordPress needs to access your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host. Hostname example: www.wordpress.org FTP Username members_publiqly FTP Password ••••••••••••••••••••••••• This password will not be stored on the server.
And the error came when I tried to update the post or save it. Normally data is just stored in the database so I failed to understand why the FTP credentials were requested in the first place. But apparently the file being run also suffers from this. And so there must be a permission issue.
WordPress Admin Rights
We do allow admins to install plugins on the server and as Ben mentioned at Roots discourse once again that is not recommended. But hey, we needed this working with multiple team members not familiar with tools such as Git, Composer, WP-CLI and the likes. So although I would have preferred to manage the plugins with composer it was simply not possible with this projects.
Error Logs
So decided to check the logs for clues on the need for FTP. The error log showed
PHP message: PHP Warning: Cannot modify header information - headers already sent by (output started at /srv/www/sub.domain.com/releases/20171017052436/web/wp/wp-admin/includes/file.php:1678) in /srv/www/sub.domain.com/releases/20171017052436/web/wp/wp-admin/post.php on line 198 PHP message: PHP Warning: Cannot modify header information - headers already sent by (output started at /srv/www/sub.domain.com/releases/20171017052436/web/wp/wp-admin/includes/file.php:1678) in /srv/www/sub.domain.com/releases/20171017052436/web/wp/wp-includes/pluggable.php on line 1216" while reading upstream, client: 77.69.163.237, server:sub.domain.com, request: "POST /wp/wp-admin/post.php HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm-wordpress.sock:", host: "sub.domain.com", referrer: "https://sub.domain.com/wp/wp-admin/post.php?post=483&action=edit"
Based in this I checked this WordPress core files for anomalies. I found:
// Session cookie flag that the post was saved
if ( isset( $_COOKIE['wp-saving-post'] ) && $_COOKIE['wp-saving-post'] === $post_id . '-check' ) {
setcookie( 'wp-saving-post', $post_id . '-saved', time() + DAY_IN_SECONDS, ADMIN_COOKIE_PATH, COOKIE_DOMAIN, is_ssl() );
}
in post.php. In Pluggable line 1216 showed:
if ( !$is_IIS && PHP_SAPI != 'cgi-fcgi' )
status_header($status); // This causes problems on IIS and some FastCGI setups
header("Location: $location", true, $status);
return true;
Session Issue
And so that seemed to be related to a session issue on saving of the post. Which is correct. Not a whitespace issue that should not be there as is sometimes the case. So I started to wonder. I did do a server update while working so perhaps the session got messy. I logged of and on, tried saving the same post again and things were fine. I also checked rights and permissions for the /srv/www/sub.domain.com/current/web/app/ and did not see something odd really. So perhaps it was just a session issue due to the server update I did doing a
unattended-upgrades -d
Should have probably not have done these two things at the same time!
Reinstallation Latest WordPress Version
Issue continued however. Once I made a header change the second time and saved the issue returned. So then I decided to reinstall WordPress as it seemed the issue was pointing to WordPress Core files and I could still not find issues with the files it got stuck at. Did not work either
Image Replacement
The image used in the header was an image loaded from the main domain on the same server so thought that may be the issue and uploaded on on the subdomain media manager itself. Did did not seem to be the issue though as the issue remained.
FS METHOD Direct
So I decided to upload the theme once again as it was updated recently and that may be the issue. After I overwrote all theme files things seem to be working. But only when I added a line to application.php for direct FS method*.
/**
* Custom Settings
*/
define('AUTOMATIC_UPDATER_DISABLED', true);
define('DISABLE_WP_CRON', env('DISABLE_WP_CRON') ?: false);
define('DISALLOW_FILE_EDIT', true);
define('FS_METHOD', 'direct');
*(Primary Preference) “direct” forces it to use Direct File I/O requests from within PHP. It is the option chosen by default.
The extra define(‘FS_METHOD’, ‘direct’); in application.php seemed to do the trick.
This makes us think there has been a Jupiter change that requires file manipulation that somehow does not work properly with other methods besides direct file I/O requests. But we have not figured it out yet. Seems unlikely now that this is a file or directory permission issue. Otherwise we would have had other issues and error messages.
