Why WordPress Asks for FTP Credentials

The prompt is a diagnosis, and this constant is a way to stop reading it. When WordPress asks for FTP credentials before installing a plugin, it has already tested whether it can write to the directory and decided it cannot. Setting FS_METHOD to direct tells it to write anyway. On a correctly configured server that is right, because the test can produce a false negative. On a misconfigured one it converts a clear prompt into a silent failure later.

The values

define( 'FS_METHOD', 'direct' );

Only the first needs no additional configuration. The other three require matching constants for host, username and credentials, and a site that sets one of them without those will fail differently rather than better.

How WordPress decides on its own

Left undefined, WordPress creates a temporary file in the target directory and checks who owns it. If the owner matches the user PHP is running as, it uses direct. If not, it falls back to asking.

The test is reasonable and it produces false negatives. Container setups, shared hosting with unusual user mapping, and sites where some files were restored from a backup under a different owner can all fail the check while writes would genuinely succeed. That is the case where forcing direct is correct and harmless.

The case where forcing it is wrong

If the web server user really cannot write to the directory, setting the constant does not grant permission. It changes the failure from an explicit credential prompt to an update that starts, gets partway, and stops. Half-copied plugin directories and a site in maintenance mode are the usual result, and the connection to a change made in wp-config.php weeks earlier is not obvious.

Tell the two cases apart before deciding. Create a file in wp-content as the web server user and see whether it works. If it does, the check was a false negative and direct is appropriate. If it does not, ownership is the problem, and the repair is on the filesystem:

• Directories owned by the user PHP runs as, or a group it belongs to.
• Directories typically 755 and files 644, with no world-writable entries.
• wp-content/uploads writable, because media uploads need it whatever this constant says.

The security argument, honestly

Making every WordPress file writable by the web server user means any code that executes as that user can rewrite the site. That is a real consideration and it is the reason some hosts deliberately keep ownership split.

It is also not an argument for leaving updates broken. A site that cannot update is a site accumulating unpatched code, which is a larger and more certain risk than the one being avoided. If the split ownership is deliberate, the resolution is a deployment process that updates files out of band, not a dashboard that half-works.

Related constants that change the same behaviour

FS_CHMOD_DIR and FS_CHMOD_FILE set the permissions applied to files WordPress creates. They matter on hosts whose default umask produces files the server cannot read afterwards — a rarer problem, and one that looks like an internal server error rather than a permissions message.

All of these go in wp-config.php above the stop-editing comment. Below it they are defined too late to be consulted.

Verify with a real update

Install a small plugin from the directory, activate it, and delete it again. All three operations write to the filesystem, and all three should complete without a prompt.

Then check wp-content/upgrade and wp-content/upgrade-temp-backup for leftover directories. Debris there means an update did not finish cleanly even if the screen reported success, and that is the quiet failure mode this constant produces when ownership is wrong. If the site went down during the attempt, the route back is the white screen and then debug mode to see what the failed write actually reported.