"Missing a Temporary Folder" in WordPress — What PHP Is Actually Complaining About
PHP has nowhere to put your file while it's being received. The setting is upload_tmp_dir, it lives in PHP's configuration rather than in WordPress, and either it's unset, points at a directory that doesn't exist, or isn't writable by the web server user.
Note what this isn't: it isn't wp-content/uploads, and it isn't a permissions problem you can fix from the WordPress admin.
Almost every article about this message opens by telling you to add WP_TEMP_DIR to wp-config.php. That advice is right about half the time, and the half it's wrong about is the media library — which is where most people are standing when they read it. Worth five minutes to get the distinction straight.
Why PHP needs a temporary folder at all
When a browser posts a file, PHP doesn't hand your code a stream. It receives the whole thing, writes it to a scratch directory under a random name, and only then passes control on — with a pointer to that scratch file. WordPress copies it into wp-content/uploads and PHP deletes the original when the request ends.
The scratch directory is upload_tmp_dir. If it's blank, PHP falls back to the system temp directory, which is normally fine — /tmp on a standard Linux box. Trouble starts when a host sets it explicitly to a per-account path and that path is missing, or when hardening confines PHP with open_basedir so that /tmp is off-limits and no fallback remains.
With nowhere to write, PHP sets error code 6 on the upload and stops. WordPress translates that code into the sentence you're reading. The failure happened before a single line of WordPress ran.
Two messages, one sentence
WordPress uses the same wording in two different situations, and they have different fixes:
| Where you saw it | Who needs the temp folder | What fixes it |
|---|---|---|
| Media Library, uploading an image | PHP, staging the incoming file | upload_tmp_dir in PHP config |
| Installing or updating a plugin or theme | WordPress, unpacking a downloaded archive | WP_TEMP_DIR in wp-config.php |
That's why the popular advice appears to work for some people and not others. If you're here because a plugin install failed, add this above the "stop editing" line in wp-config.php:
define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/');
…and create wp-content/temp, owned by the web server user. If you're here because an image upload failed, that constant will not help, and the next section is the one you want.
The fix, by how much access you have
If you can edit php.ini
Find the active file — Tools → Site Health → Info → Server names it, or php --ini on the command line. Set:
upload_tmp_dir = /tmp
Then restart PHP-FPM or Apache. Confirm the directory exists, is writable by the web server user, and is outside the web root — a temp directory that visitors can browse is a genuine security problem, not a stylistic preference.
If you're on shared hosting with .user.ini support
Many hosts running PHP-FPM honour a .user.ini file in the site root:
upload_tmp_dir = /home/username/tmp
Create that directory first. Changes take up to five minutes to be picked up — user_ini.cache_ttl decides exactly how long, so don't conclude it failed after thirty seconds.
If neither works
Some hosts ignore both, and no amount of editing files in your account will change PHP's configuration. That's not a wall you can climb; it's a support ticket, and the next section writes it for you.
One thing worth ruling out before any of this: a full disk. If the partition holding /tmp has no space left, the directory exists and is writable and PHP still can't stage anything. df -h takes seconds and occasionally saves an hour.
What to send your host
Support handles this constantly, and a specific ticket gets a same-day answer where a vague one gets a link to a knowledge base article:
Uploads to the WordPress media library fail with "Missing a temporary folder", which is PHP error code 6 (UPLOAD_ERR_NO_TMP_DIR). Could you check that upload_tmp_dir is set to a directory that exists and is writable by the PHP user for this account, and confirm it isn't blocked by open_basedir? Happy to test as soon as it's changed.
Naming the error code is what moves it past first-line support. It converts "my uploads are broken" into a specific configuration check with a specific answer.
Which upload error you actually have
| Message | Failed at |
|---|---|
| Missing a temporary folder. | Staging the file in PHP's scratch directory — before WordPress ran. |
| The uploaded file could not be moved to… | Staging worked; the copy into wp-content/uploads didn't. |
| Unable to create directory wp-content/uploads/… | The month folder couldn't be created at all. |
| HTTP error. | The file arrived; processing it crashed. |
| Exceeds the maximum upload size for this site | Rejected on size before any of the above. |
FAQ
What causes "Missing a temporary folder"?
PHP's upload_tmp_dir is unset, points at a directory that doesn't exist, or isn't writable by the web server user — so PHP has nowhere to stage the incoming file and aborts.
Does WP_TEMP_DIR fix it?
Only for plugin and theme installs, where WordPress does the unpacking. A media library upload is staged by PHP before WordPress is involved, and that needs upload_tmp_dir.
Where should upload_tmp_dir point?
A directory the web server user can write to, outside the web root. /tmp on most servers; something like /home/username/tmp on shared hosting.
Why did this start after moving hosts?
The setting points at a path that existed on the old server and doesn't here, or the new account was provisioned without its temp directory. Nothing in your site changed.
Can I fix it without server access?
Sometimes, via .user.ini if your host honours it. Otherwise it's a support ticket — a short and routine one.
Is this the same as wp-content/uploads?
No. The temp folder holds the file for a few seconds during transfer; wp-content/uploads is permanent storage. Failures there produce different messages.
A route that skips PHP's temp folder
Fig2WP doesn't post a browser form. The Figma plugin sends your images to a REST endpoint, and the WordPress side writes them itself — so upload_tmp_dir, the setting behind this message, is never part of the path. Handy on hosting where the fix is somebody else's ticket queue.