So I ran into an issue with one of my sites not being able to upgrade WordPress except for via manual ssh. And that’s extremely annoying. It was the only one that was on a VPS, so I was curious why the VPS was set up so differently than most of the other shared accounts on the same host.
Here’s the reasoning. The difference is whether or not your Apache is running DSO, or SuPHP.
The Apache HTTP Server is a modular program where the administrator can choose the functionality to include in the server by selecting a set of modules. The modules can be statically compiled into the httpd binary when the server is built. Alternatively, modules can be compiled as Dynamic Shared Objects (DSOs) that exist separately from the main httpd binary file. DSO modules may be compiled at the time the server is built, or they may be compiled and added at a later time using the Apache Extension Tool (apxs).
suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter.
So how do you fix it? Are you getting the WordPress error that refuses to create directories in plugins and upgrade? Having issues where the whole chmod 777 solution (which btw, is a completely stupid solution since it opens you up to all sorts of bad things) isn’t working?
I finally ran across this fix, where for SuPHP configurations, all you have to do is edit your wp-config.php and add:
putenv('TMPDIR=' . ini_get('upload_tmp_dir'));
define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));
This will fix the entire issue because it basically defines your environment and forces the masking to be correct. Ahhh.. phew. Another fix.