Using the legacy wp-config.php file

[ozfiddler]

As part of my investigations into my failing update problem I have been looking at the wp-config.php file. This file remains intact after using the migration plugin, and it is also recommended to keep it in place when doing a manual upgrade. But it can contain some extra settings that create some unusual effects.

For example, my failed upgrades would often leave large undeleted folders of installation files in the uploads folder. I have now found that I have this line in many of my sites and this explains why…

define('WP_TEMP_DIR',dirname(__FILE__).'/wp-content/uploads');

Some sites weren’t auto-updating and I found I had directives in there (I don’t know where they came from) that disabled them.

I also have these settings and I have no idea what they do:

define('FS_METHOD','direct');define('FS_CHMOD_DIR',0755);define('FS_CHMOD_FILE',0644);

I’m not sure if this is related to my particular issue, but it does make me wonder whether it might be good practice to make a point of using the clean sample config that comes with CP… just adding in the database name, username, password and db prefix.

[anon71687268]

@ozfiddler

define(‘FS_METHOD’,‘direct’);define(‘FS_CHMOD_DIR’,0755);define(‘FS_CHMOD_FILE’,0644);

These are interesting clues and, because they’re written to a single line like this, my guess is that they were added programmatically (ie, a security plugin)

The FS_CHMOD_DIR and FS_CHMOD_FILE define statements allow override of default file permissions. These two variables were developed in response to the problem of the core update function failing with hosts running under suexec. If a host uses restrictive file permissions (e.g. 400) for all user files, and refuses to access files which have group or world permissions set, these definitions could solve the problem.

…and for FS_METHOD…

The most common causes of needing to define these are:

Host running with a special installation setup involving symlinks. You may need to define the path-related constants (FTP_BASE, FTP_CONTENT_DIR, and FTP_PLUGIN_DIR). Often defining simply the base will be enough.

Certain PHP installations shipped with a PHP FTP extension which is incompatible with certain FTP servers. Under these rare situations, you may need to define FS_METHOD to “ftpsockets”.

I think you’re on the right track.

Sources:
Override of default file permissions
WordPress Upgrade Constants

[Pross]

@ozfiddler

define(‘FS_METHOD’,‘direct’);define(‘FS_CHMOD_DIR’,0755);define(‘FS_CHMOD_FILE’,0644);

I’d say this was more likely added by a cheap host as a cheap fix for wrong file permissions when the php and webserver are different unix users, typically www-data/nobody and mod_php … luckily that setup is getting rare now.

[james]

@ozfiddler

it does make me wonder whether it might be good practice to make a point of using the clean sample config that comes with CP

If I understood this suggestion correctly: replacing the config with a more minimal/default version during a migration is a bad idea, because any custom settings would be lost and in some cases this would break sites.

A better way to address this general issue is to document when a setting is added and why with comments next to the setting. If a plugin or host adds a setting, ideally they should be adding comments with explanation too. This won’t always be the case, so it’s a good idea to watch for changes to the wp-config.php file and document why they occurred.

---

@ozfiddler

For example, my failed upgrades would often leave large undeleted folders of installation files in the uploads folder. I have now found that I have this line in many of my sites and this explains why…

define('WP_TEMP_DIR',dirname(__FILE__).'/wp-content/uploads');

Yep, that explains that… I suppose it is possible that this setting is related to the upgrade/migration issues.

@ozfiddler

define(‘FS_METHOD’,‘direct’);define(‘FS_CHMOD_DIR’,0755);define(‘FS_CHMOD_FILE’,0644);

I am not sure what problem this is intended to solve but it doesn’t look like it would do anything on a reasonable server configuration. direct is the default filesystem method, and 0755 and 0644 are the default file permissions in most cases. I doubt these settings would be related to the issues you’re having with upgrades, but removing them is also worth a try.

@Pross

I’d say this was more likely added by a cheap host as a cheap fix for wrong file permissions when the php and webserver are different unix users, typically www-data/nobody and mod_php … luckily that setup is getting rare now.

The file permissions 0755 and 0644 would not do anything in this case because they don’t assign write permissions to any other users, you’d probably see 0777 instead, which would be a really bad idea and thankfully not something I’ve ever seen in the wild.

Intentionally separating the system users like this is actually a good way to add some extra security to a site, but you have to be prepared to deal with core and plugin updates some other way because the site won’t be able to do them itself.

[ozfiddler]

Thanks for all the replies. I can see that it may not always be a good idea to wipe the current file and use a clean, minimal version. But I was surprised by the stuff that had “appeared” in there. I have cleaned them all out and all sites are still working normally (and the remaining sites auto-updated successfully).

@Pross

I’d say this was more likely added by a cheap host as a cheap fix

That could also be the case. I often work on a budget hosting service initially as I develop a site (I have a small reseller account for that), then move it to my usual hosting service when it goes live.

I also typically install WP4.9 with Softaculous then do the migration to CP. It seems the easiest way to do the initial setup.

In future I will just install CP myself directly. And keep a closer eye on wp-config.