Security?

If has to be writable to be able to use the WordPress Dashboard. Otherwise, you would have to upload your pictures and videos through your FTP or Cpanel.

—
For more security, their are plenty of security plugins in the WordPress plugin directory.

(Personally, I would recommend WordFence)

Unless you have permissions set incorrectly, you should have no issues with vulnerability in regards to security of your directories. Your /wp-content/uploads/ folde needs to be 755 or otherwise you won’t be able to upload any images since you won’t have the right permissions.

For more information, please read Changing File Permissions. For security tips, read Hardening WordPress.

I agreed on you @micheal Tieso. You just need to set correct permissions to and every directory to avoids such issues otherwise you’ll be in total missed.

WordPress is confused:

“Typically, all files should be owned by your user (ftp) account on your web server, and should be writable by that account. On shared hosts, files should never be owned by the webserver process itself (sometimes this is?www, or?apache, or?nobody?user). “

[https://codex.www.ads-software.com/Changing_File_Permissions]

file ownership: all of your WordPress files must be owned by the user under which your web server executes.

[https://codex.www.ads-software.com/Updating_WordPress]

It seems to me (as a non WordPress developer) that WordPress is in the process of moving from a system based on using FTP for upgrades which means everything can be owned by an FTP account (except the uploads directory perhaps) to allowing direct writes – for which everything has to owned by apache|www (or whoever the web server runs as).

I can’t get the FTP method to work as it seems to create a folder owned by the web server user which it then can’t write into.

It seems to me (as a non WordPress developer) that WordPress is in the process of moving from a system based on using FTP for upgrades which means everything can be owned by an FTP account (except the uploads directory perhaps) to allowing direct writes

I’m afraid that’s not the case. It boils down to the way in which your server is configured rather than anything that WordPress tries to impose.

I’m not sure what you mean? I am citing two WordPress documents – both from the Codex. They appear to give 100% opposite advice. As you can see. (Links above).

One says make all files owned by an FTP account and writable by that account. That’s the first document I linked to above.

The other says all files must be owned by the web server user. That’s the second document linked to above.

It is there for all to see. Clearly these are two different approaches to permissions.

Though I agree that in the end one has to make one’s own decision. (As I said the FTP method – method 1 – did not work for me).

The Codex is a community driven resource. As such, it’s possible for mistakes to appear over time. As it stands, I don’t personally see those two statements are mutually exclusive. Just badly worded. ??

Lol

make all files owned by an FTP user
make all files owned by apache|www

not the same thing

two completely different approaches

On some servers, the ftp user is also the same user as the web server. As I said, it depends upon the way in which the server is configured.

most unlikely

“it depends upon the way in which the server is configured.” could really mean anything couldn’t it? (-:

Are you running your own server?

Ok. My understanding is as follows. There are 2 (principally) ways of upgrading WordPress or a plugin.

1. Uses Curl to get the zip file by http. Streams it directly to the file system. This requires that the web server user has write permissions pretty much everywhere. The second of the two links I posted above applies. This method is used by the “one-click” updates feature.

2. Uses FTP. I believe this is the older way. This obtains the zip file by anonymous FTP or HTTP (not sure / doesn’t matter) and then uses the PHP FTP client class to put the files into place. The first of the two links I posted above applies.

The benefit of 2. is that it means, for example wp-content/ can be owned by a system FTP user with 755 permissions. (Only writeable by the system user). Thus it is not writable by the web server. This is more secure if we accept the principal that files/directories should have the minimum permissions necessary for the system to achieve its purpose. In case 1 as per the Codex notes all files have to be writeable by the web server. This is not just (imho) undesirable on shared hosting setups but on any setup. If only the /uploads directory is writeable by the web server it means less places to look for all that malware which some plugins sometimes let in by mistake.

In my case I can’t get the FTP method to work. The plugin upgrade process tries to use it because I have set my permissions for case 2 (everything is owned by an FTP user with 755 except the uploads folder which is owned by by web user). (It also tries to use it when I direct it to using FS_METHOD in the wp-config.php file). But in /wp-includes/class-http.php it calls into /includes/functions.php wp_is_writable() to see if it can create a directory (or file) /wp-content/mypluginname.tmp . This fails because the web server does not have write permissions on /wp-content.

Either a) my expectations for the FTP method are incorrect. It is not intended to work as I expect or b) this method is broken in in WordPress 3.9.1 or c) my plugin should not be trying to create a file/directory /wp-content/mypluginname.tmp – it should perhaps be trying to do this in /wp-content/upgrade/mypluginname.tmp

It would be fantastic if someone who knows how the FTP plugin upgrade method is supposed to work could tell me which is the case.

Are you running your own server?

Could I draw the reader’s attention to the post preceding the one just above this one!

Thanks!

How does that answer my question?