I have recently had an issue where I have been unable to install the WP Smush Pro plugin because I don’t have the Manual Install or One-Click Installation options available.
I came across this post which suggested tweaking the settings in
wp-config.php. I added the settings suggested, however the one that seems to be the most important is:
What I would like to know is what real concerns should I have around setting
direct? Are there any other alternatives to installing the plugin?
This is what the official documentation has to say:
FS_METHOD forces the filesystem method. It should only be “direct”,
“ssh2”, “ftpext”, or “ftpsockets”. Generally, you should only change
this if you are experiencing update problems. If you change it and it
doesn’t help, change it back/remove it. Under most circumstances,
setting it to ‘ftpsockets’ will work if the automatically chosen
method does not.
(Primary Preference) “direct” forces it to use Direct File I/O requests from within PHP, this is fraught with opening up security
issues on poorly configured hosts, This is chosen automatically when
This is just, how I understood the idea of the WordPress File API. If it is wrong, please downvote 🙂
Okay. If you upload a file, this file has an owner. If you upload your file with FTP, you login and the file will be owned by the FTP user. Since you have the credentials, you can alter these files through FTP. The owner can usually execute, delete, alter etc. the file. Of course, you can change this by changing the file permissions.
If you upload a file using PHP, the linux user, which is executing PHP is owning the file. This user can now edit, delete, execute etc. the file. This is okay as long as only you are the user, who is executing PHP on your system.
Lets assume, you are on a “poorly” configured shared host. A lot of people run their PHP websites on this system. Lets say only one linux user is executing PHP for all these people. One of the webmasters on this shared host has bad intentions. He sees your page and he figures out the path to your WordPress installation. For example, WP_DEBUG is set to true and there is an error message like
[warning] /var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php on line 1
“Ha!” the bad boy says. Lets see, if this guy has set
direct and he writes a script like
unlink( '/var/www/vhosts/userxyz/wp-content/plugins/bad-plugin/doesnt-execute-correctly.php' );
Since only one user is running PHP and this user is also used by the bad boy he can alter/delete/execute the files on your system if you have uploaded them via PHP and by this attached the PHP user as the owner.
Your site is hacked.
Or, as it says in the Codex:
Many hosting systems have the webserver running as a different user
than the owner of the WordPress files. When this is the case, a
process writing files from the webserver user will have the resulting
files owned by the webserver’s user account instead of the actual
user’s account. This can lead to a security problem in shared hosting
situations, where multiple users are sharing the same webserver for