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?
Posted 2 years ago #
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.
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...
Posted 2 years ago #
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.
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.
Posted 2 years ago #
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.
Posted 2 years ago #
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
Posted 2 years ago #
Sorry about your troubles Martyn, but I think you're looking for support with the dbug plugin - this topic here is about 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!
Posted 2 years ago #
Survivorbility - there's a debug function built into WP Super Cache. It's all on the admin page.
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.
Posted 2 years ago #
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 ...
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 :)
Posted 2 years ago #
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.
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?
Posted 2 years ago #
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.
This topic has been closed to new replies.
