Make WordPress Core

Opened 11 years ago

Last modified 5 years ago

#26822 new defect (bug)

During upgrade, no errors thrown when file permissions are wrong

Reported by: mystica555's profile mystica555 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Upgrade/Install Keywords: needs-patch
Focuses: Cc:


I am, for the first time, attempting a Wordpress auto-upgrade.

I was quite shocked to immediately see an FTP credentials dialog, as these credentials I treat as secret and do not wish to randomly spew them into the system that theoretically should simply be able to modify itself -- if filesystem permissions were proper.

I wish to see an error message "tried X, failed, exact failure error message, now trying FTP"

A number of current chatters in #wordpress on FreeNode state that this is actually not an error -- a position I vehemently disagree with.

If _any_ operation fails, in the due-course of a program, SOMETHING should elaborate this within the normal course of execution for the task, especially the app itself that cannot write its own files.

I would much rather like to see this from within the app updating itself, and not have to deduce it via any number of other, less-obvious methods, such as error logs on the server, filesystem access denial audits, etc.

Change History (5)

#1 @dd32
11 years ago

WordPress is designed to work across many thousands of different server configurations, many of which have not been altered in years, which the end user has no control over, and WordPress is expected to just work.
In order for WordPress to do that, it makes a judgement call based on the permissions it see's, it doesn't tell the user they've done something wrong (because, chances are, the user hasn't and it's just their host) and just does it's best to work with what it's given.

This does mean that WordPress has prioritized user experience over user education (on something that they're probably not interested in) and showing obscure error messages.
This is very much similar to the rest of the WordPress UX, if you don't have GD/Imagemagik installed you don't get flashing alerts about image resize not working, if the filesystem doesn't allow uploads to be written it doesn't give intense instructions on fixing it, if one method of external HTTP access is bad, we use a different one, etc.

For those who are a host, or who is configuring their own server, I believe we have documentation in the codex for it (but I'm not sure) - the basic rule is: If PHP is executing as the owner of the files (Which generally means php-fpm or suexec) and the files are writable by that user, then FTP credentials (of which, the password is NEVER stored) won't be needed.
Group-writable is not enough for WordPress for a variety of reasons (primarily, created files may not be writable by the owner, something we can't detect) and is covered in other tickets.

I'm not sure of how it'd be best to describe in words that would be both helpful to a sysadmin AND be a good UX for a user who anything beyond point-and-click text modification is all too much for them. For that reason having a installable plugin such as our Background Update Tester is probably the best solution for everyone.

#2 @MikeHansenMe
11 years ago

Perhaps on the screen when asked for FTP info we could just add something to the effect "Don't want to provide your FTP credentials? Read this article on the codex to learn more." Then send them to an article about file permissions. I think if a user is seeing this screen and does not understand what it is, they may just never upgrade.

#3 @chriscct7
9 years ago

  • Keywords needs-patch added

I agree with @MikeHansenMe. That seems like a fine compromise

#4 @chriscct7
9 years ago

  • Severity changed from major to normal

#5 @maratbn
8 years ago

Indeed there should be some kind of indication to the user that:

(1) Filesystem permissions / server configuration are not allowing WP to write to the filesystem directly.

(2) That the FTP method is not the only method for upgrading WP, and that it is simply being offered as a work-around because server configuration is preventing WP from writing to the filesystem directly.

(3) If the user can alter their filesystem permissions / server configuration to allow WP write access, then they will not need to use the FTP method.

There should be a way to convey this information to the user without confusing them.

Last edited 8 years ago by maratbn (previous) (diff)
Note: See TracTickets for help on using tickets.