This problem comes up now and again:
- you want to use the Wordpress web admin interface to install plugins/themes etc
- your webserver user correctly has write access to the wp-content directory as documented (you probably set it group writeable)
- Wordpress fails to perform the install (and instead asks you for your FTP details instead as a fallback)
Why does this happen?
The problem is a well known bug in the Wordpress code in function get_filesystem_method(). This function contains a call to getmyuid() and compares the result to the owner of a temp file it creates.
To fix this Wordpress problem, one simple fix is:
- edit the file wp-admin/includes/file.php (make a backup of this file just in case)
- search for the text “getmyuid” and replace all occurrences with “posix_getuid“
Your upgrade or install should then work fine by simply setting the correct write permissions on the content folder and subfolders (e.g. “chmod -R g+w wp-content”). This is just a hack but is a simple way to get things working.
More details below for anyone who’s interested
The WP code tries to test if the webserver user is equal to the owner of the Wordpress core code files. This fails as the owner of the core Wordpress code files in many setups will often not be the same as the owner of dynamically web-server created files (for security in fact it should not be. If it was, any bug or malicious feature in any plugin, or within Wordpress itself, would be able to completely overwrite any or all of the Wordpress core software).
This is probably (a) because they share this function to see if the whole installation can be upgraded and/or (b) because they assume all the WP code tree will be owned by the same user/group.
It would be more intuitive if the WP plugin & themse install/upgrade code actually called a different function to simply see if the relevant folder can be written to rather than the main core code.
Leave a Comment