Title: [Plugin: WP Super Cache] Debugging Errors – Supercache Could Not Write to .tmp
Last modified: August 19, 2016

---

# [Plugin: WP Super Cache] Debugging Errors – Supercache Could Not Write to .tmp

 *  [Tranny](https://wordpress.org/support/users/tranny/)
 * (@tranny)
 * [16 years, 3 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/)
 * I turned the debugging on and keep getting emails with different variations of
   the same message:
 * **Supercache could not write to 7312151304b7425afaafb58.09631868.tmp**
 * What exactly does it mean? I get one every 4-5 minutes so I’m gonna turn it off
   soon cause it’s flooding my inbox too much, but is there anything I can do to
   make the plug in work?
 * [http://wordpress.org/extend/plugins/wp-super-cache/](http://wordpress.org/extend/plugins/wp-super-cache/)

Viewing 14 replies - 1 through 14 (of 14 total)

 *  [Donncha O Caoimh (a11n)](https://wordpress.org/support/users/donncha/)
 * (@donncha)
 * [16 years, 3 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382260)
 * The plugin couldn’t write to a temporary file. Chances are it can’t cache either.
   You should check the permissions of your cache folder, the user php runs as and
   the user your webserver runs as.
 *  Thread Starter [Tranny](https://wordpress.org/support/users/tranny/)
 * (@tranny)
 * [16 years, 3 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382394)
 * Could you please clarify that a little – perhaps with language someone’s who’s
   not a server tech could understand? The permissions for wp-content/cache/ folder
   are set to 775 which normally enables scripts to write in the folder. Is there
   any other folder I need to change permissions of?
 * What about the other two things you are mentioning? I have no idea what any of
   them means…
 *  [Alvaro Degives-Mas](https://wordpress.org/support/users/nv1962/)
 * (@nv1962)
 * [16 years, 3 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382395)
 * Short version: get in touch with your hosting provider and tell them you have
   a PHP script that needs to create (not just “edit”) and later at some point delete
   the temporary files it created; then tell them you need them to set the PHP /
   Apache user so that it can do what it needs to do in a directory with 755 permissions.
 * You don’t want the long version.
 * Reason being, that merely setting a directory to 755 doesn’t by itself necessarily
   solve your problem. In your case, it apparently doesn’t. And because it’s very
   unwise to set a world-accessible directory to 777, see the short version above.
 * Added later: if your hosting provider says anything fundamentally different from“
   yes Sir, right away Sir!” find a [good hosting provider](http://wordpress.org/hosting/).
 *  Thread Starter [Tranny](https://wordpress.org/support/users/tranny/)
 * (@tranny)
 * [16 years, 2 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382406)
 * I appreciate your response. To be honest though, I would never host with any 
   of the shady, unstable hosts listed on that page. I have a dedicated server with
   real webhost and as such there is never a problem adding or removing anything
   from it. It’s fully managed as I am a webmaster, not a server tech. But that’s
   not the point.
 * I must say I still don’t understand what you are saying and if what you are saying
   makes no sense, how am I to explain to my server techs what I want form them?
   The /wp-content/cache/ directory is set to 775, not 755. Directories with 755
   permissions can not be written to by scripts – that much I know as I have tested
   it. In case of directories such as /wp-content/cache/ after I have set the permissions
   to 775, the script created additional subdirectories inside the ownership over
   which is owned by the script so it can write inside them.
 * I truly don’t know what I’m supposed to do here to make it work.
 *  [Alvaro Degives-Mas](https://wordpress.org/support/users/nv1962/)
 * (@nv1962)
 * [16 years, 2 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382407)
 * If your scripts cannot write to (“edit”) _existing_ files with 755, you have 
   a server that needs spanked. Again, you don’t have to know what goes on at the
   server level just to maintain your WP install.
 * Bottom line still is, your hosting provider needs to set the server users (PHP/
   Apache) so that it _can_ create new files and later delete them, too – with canonical,
   standard 755 perms, not with 775 and most certainly not 777 either. Those latter
   two are wide open invitations to malfeasants who sooner or later _will_ wreak
   havoc and discredit your site.
 * Else, it likely won’t be “just” WP-Super Cache that has trouble running properly.
 * PS: none of the hosting providers listed on the WP hosting suggestions page are“
   shady” at all – they’re all solid, very successful and offer a very reasonably
   priced offering in shared hosting environments, which is probably 99% of the 
   market out there for self-hosted WP installs. They each have their pros and cons,
   all have their quirks, and some fit better for a particular case than others;
   none are amateurish or less so untrustworthy. Finally: having a dedicated server
   with managed hosting is great – but it also puts a greater onus on the administrator
   to get the configuration exactly right. Everything has its pluses and minuses.
 *  [survivorbility](https://wordpress.org/support/users/survivorbility/)
 * (@survivorbility)
 * [16 years, 2 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382408)
 * downloaded and activated the debug plgin and have now lost the dashboard and 
   my site is written as: PHP ERROR (2048) = String: [ is_a(): Deprecated. Please
   use the instanceof operator ]
    backtrace: /home/survivor/public_html/wp-content/
   plugins/dbug/dbug.php line 51 etc ……. does anyone know how I undo all this (I
   am not a very web savy user of WP!) Thanks Martyn
 *  [Alvaro Degives-Mas](https://wordpress.org/support/users/nv1962/)
 * (@nv1962)
 * [16 years, 2 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382409)
 * Sorry about your troubles Martyn, but I think you’re looking for support with
   the [dbug plugin](http://wordpress.org/extend/plugins/dbug/) – this topic here
   is about [WP Super Cache](http://wordpress.org/extend/plugins/wp-super-cache/),
   a different plugin…
 * One simple way to deactivate the dbug plugin (assuming it’s the one giving you
   trouble, and not something else brought to the light by dbug) is to log into 
   your server using FTP and delete the entire dbug plugin folder, i.e. this one:
 * `/home/survivor/public_html/wp-content/plugins/dbug`
 * Once your site is back up, however, you have to look at whether your problem 
   is caused by dbug or something else. Ask for support for the dbug plugin, in 
   that case, in a separate topic. Good luck!
 *  [Donncha O Caoimh (a11n)](https://wordpress.org/support/users/donncha/)
 * (@donncha)
 * [16 years, 2 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382414)
 * Survivorbility – there’s a debug function built into WP Super Cache. It’s all
   on the admin page.
 *  Thread Starter [Tranny](https://wordpress.org/support/users/tranny/)
 * (@tranny)
 * [16 years, 2 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382419)
 * Is there a way to see where this plugin is trying to write temporary files? I
   changed permissions of the /cache/ folder to 777 yet error messages from the 
   debugger continue coming. It’s definitely not a permission issue. The issue is
   with where the plugin is trying to write these temp files.
 *  [Donncha O Caoimh (a11n)](https://wordpress.org/support/users/donncha/)
 * (@donncha)
 * [16 years, 2 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382421)
 * Tranny – read the troubleshooting and FAQ sections of the readme.txt. It could
   be a security setting on your server that doesn’t allow writing because the directory
   is owned by a different user to PHP.
 * Use the debug functions …
 *  Thread Starter [Tranny](https://wordpress.org/support/users/tranny/)
 * (@tranny)
 * [16 years, 2 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382436)
 * Hey guys,
 * I wanted to thank you for taking time to try to help me. Since everything was
   failing and no straightforward resolution seemed to exist, I have decided to 
   remove WP Super Cache form the blog entirely, including complete deletion of 
   the /cache? folder and all of its content, including subfolders, removal of cache
   related lines form .htaccess file and wp-config.php file and went to reinstall
   the plug in from scratch, on a clean blog with no traces of preciously used WP
   Super Cache.
 * I think this may have done the trick. I have turned the debugging back on and
   provided my email address where to send the emails, but after 20 seconds I had
   more than 2500 emails sent to me so I had to quickly turn it off. But as I am
   going through the emails, they all seem to be just notifications of the plugin
   doing its job, rather than telling me that it couldn’t write to a temp file. 
   The notes in emails vary, but form a couple dozen that I have checked so far,
   they contained the following (one email per line in random order):
 *     ```
       Cookie detected: wordpress_eda2c6a9acc9107d0ab762889c70c7e8
       exit request
       Serving wp-cache static file
       No wp-cache file exists. Must generate a new one.
       supercache dir:
       /www/###.com/public_html/wp-content/cache/supercache/www.###.com/wp-content/plugins/anarchy_media/anarchy_media_player.php/
       Cookie detected: wordpress_test_cookie
       In WP Cache Phase 2
       wp-cache file exists
       Renamed temp wp-cache file to
       /www/###.com/public_html/wp-content/cache/wp-cache-438c9a7c7e0adacfeccace4267828e15.html
       Supercache caching disabled. Non empty GET request.
       Setting up WordPress actions
       ```
   
 * …there are all normal and signify that the plugin is working and does what it
   should do, right? As a side note, I have also checked the source file and it 
   DOES have the note at the end telling me that a cached file was served. Did I
   just solve my problem there 😉
 * Now I must go and delete 2500+ emails I got within seconds. Overwhelming, but
   glad it seems to work 🙂
 *  [Donncha O Caoimh (a11n)](https://wordpress.org/support/users/donncha/)
 * (@donncha)
 * [16 years, 2 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382437)
 * Ouch, 2500 emails is a lot! I usually send it to a file 🙂
 * I noticed the log says “Non empty GET request.” Caching is disabled because of
   that. Do you have the default ?p= permalinks? You’ll need to use custom permalinks.
 * If not, there must be some GET parameters on the url or the $_GET super array
   is being defined somehow.
 *  Thread Starter [Tranny](https://wordpress.org/support/users/tranny/)
 * (@tranny)
 * [16 years, 2 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382475)
 * I use custom permalinks, even though not the best choice (too late to change 
   it now):
 * /%category%/%postname%/
 * I’m not familiar with the GET parameters. I’m not a programmer so it doesn’t 
   tell me much. Could you be more specific? What exactly should I do get rid of
   the empty GET request?
 *  [Donncha O Caoimh (a11n)](https://wordpress.org/support/users/donncha/)
 * (@donncha)
 * [16 years, 1 month ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382477)
 * GET parameters are the ?x=y bits of a url, but they shouldn’t normally be used.
 * Best thing to do is look at your error logs for those queries and possibly dump
   $_GET using error_log( print_r( $_GET, 1 ) ); somewhere.

Viewing 14 replies - 1 through 14 (of 14 total)

The topic ‘[Plugin: WP Super Cache] Debugging Errors – Supercache Could Not Write
to .tmp’ is closed to new replies.

 * 14 replies
 * 4 participants
 * Last reply from: [Donncha O Caoimh (a11n)](https://wordpress.org/support/users/donncha/)
 * Last activity: [16 years, 1 month ago](https://wordpress.org/support/topic/plugin-wp-super-cache-debugging-errors-supercache-could-not-write-to-tmp/#post-1382477)
 * Status: not resolved

## Topics

### Topics with no replies

### Non-support topics

### Resolved topics

### Unresolved topics

### All topics