Hanssens

After an upgrading to WordPress 4.4.x, I was suddenly getting the following error when trying to upload an image through the Media Gallery:

Missing a temporary folder.

Pretty self explanatory, as I would image the update would have something to do with a missing file path or permissions. It’s always a permissions problem, isn’t it? So, first off starting point with anything related to this is to reference the Codex where I found the get_temp_dir() function, stating:

Determine a writable directory for temporary files. Function’s preference is the return value of sys_get_temp_dir(), followed by your PHP temporary upload directory, followed by WP_CONTENT_DIR, before finally defaulting to /tmp/ In the event that this function does not find a writable location, It may be overridden by the WP_TEMP_DIR constant in your wp-config.php file.

Decent enough. It checks the system’s temp dir first, then the PHP override and if neither are available you may override this using the ‘WP_TEMP_DIR’ constant. Overriding sounds good, so let’s start with the latter to see if that would provide the quick fix. Let’s add the mentioned constant to the wp.config.php file:

define( 'WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp');
/* That's all, stop editing! Happy blogging. */

Now normally if the system’s temp directory wasn’t writable, explicitly defining a temp directory for WordPress like this should have fixed it. It didn’t, though. Because of the continuing error, I thought adding a check to see what the file paths are, if they even exist and if they’re writable would be the best course of action. Simply adding the following to a content page would surely give me the appropriate info:

    <li>
        sys_get_temp_dir: <?php echo sys_get_temp_dir() . 
            ', exists: ' . file_exists(sys_get_temp_dir()) . 
            ', writable: ' . is_writable(sys_get_temp_dir()); ?>
    </li>
    <li>
        get_temp_dir: <?php echo get_temp_dir() . 
            ', exists: ' . file_exists(get_temp_dir()) . 
            ', writable: ' . is_writable(get_temp_dir()); ?>
    </li> 

Which spat out:

• sys_get_temp_dir: /tmp, exists: 1, writable: 1
• get_temp_dir: /var/…longpath…/wp-content/temp/, exists: 1, writable: 1

Strange. Both the system temp path as well the WordPress override exist AND are writable. What gives? Summarizing a long story further on, with lots of chmod’s and vague permissions checks, the answer was provided in this post, by Gilles:

The normal settings for /tmp are 1777, which ls shows as drwxrwxrwt. That is: wide open, except that only the owner of a file can remove it (that’s what this extra t bit means for a directory).

The problem with a /tmp with mode 777 is that another user could remove a file that you’ve created and substitute the content of their choice.

If your /tmp is a tmpfs filesystem, a reboot will restore everything. Otherwise, run chmod 1777 /tmp.

Thinking to myself “Surely you can’t be serious that a reboot would fix this?”, or even be required to fix it? But yes, rebooting the server DID fix it. And again, problems with permissions on *NIX systems were the cause of another hour or two of me having some serious frustration.