Same problem here:
Plugin could not be activated because it triggered a fatal error.
The previous version worked fine (at least I think so… Not really sure if my page really does load faster with it active tbh).
Grid service uses NFS, unfortunately there is some delay in the effect of some changes to files. You can manually copy the files in wp-content/plugins/w3-total-cache/wp-content/ to your wp-content directory. I have a demo site at mediatemple http://mt.w3-edge.com/ that every release is checked against and I’ve seen anomalies before and attributed them to the network file system. I wish no files had to be written for caching to work, but that is not up to me.
Well, I set all the folders it needed to 777, including wp-config.php, and now it seems to be working. Had some trial and error, but now it’s fine.
Can I change those files back to 755 (or whatever is safer?)
I just don’t feel very happy with all those 777 files/folders on my server.
You shouldn’t have had to do that, if you wait or issue the command a couple times eventually the NFS will acknowledge the change. Anyway, yes you need to restore the normal permissions after all of the new files exist.
So you’re saying that normally, if the W3 cache plugin shows me a fatal error, I just need to keep trying to activate it until it works?
No, not normally but sometimes (even if you followed the directions). It depends on a number of factors because writing files to the disk can sometimes be a shared resource, which means that behaviors are unpredictable. Shared hosting has these anomalies and when software writes files in those cases sometimes things don’t work on the first try even though they clearly work elsewhere. Someone with a less busy shared server or dedicated server wouldn’t have the issue for example.
Hmmm. I’m still getting the fatal error.
I completely uninstalled the 0.9.0 plugin and deleted all associated config files. Then I did a clean automatic install of the 0.9.1 plugin. I had to manually copy over the files in wp-content/plugins/w3-total-cache/wp-content/ to my wp-content directory.
When I tried to activate, I got this error
Plugin could not be activated because it triggered a fatal error.
/[path]/domains/[mydomain].com/html/wp-content/w3tc-[mydomain].com/pgcache could not be created, please run following command:
chmod 777 /[path]/domains/[mydomain].com/html/wp-content/w3tc-[mydomain].com/pgcache
The wp-content is still set to 777 and has been for a full day now. I even set the wp-config.php to 777 based on @Sjengs’s suggestion. Are there other files/folders I need to set to 777?
Weirdly enough, the files I had manually copied over to the wp-content directory (advanced-cache.php, db.php, and object-cache.php) mysteriously disappeared. Activating this plugin eats files?
I manually re-copied the files to wp-content and then tried activating the plugin again. Once again it “ate” those files and I got the following error message:
Plugin could not be activated because it triggered a fatal error.
/[path]/domains/[mydomain].com/html/wp-content/w3tc-[mydomain].com could not be created, please run following command:
chmod 777 /[path]/domains/[mydomain].com/html/wp-content/w3tc-[mydomain].com
I’m a bit bewildered. Would you like an FTP login to my site?
Either /wp-content/ needs to be made 777 (which I don’t think should be necessary), or the /w3tc-[mydomain].com/ folder cannot be created because I think it should be just /w3tc/. I’m kinda surprised why the plugin wants to create a folder called /w3tc-[mydomain].com/
In my case it’s just wp-content/w3tc/
Don’t know what’s going on there… Did you manually rename the folder?
@sjeng, I have made the /wp-content/ folder 777, so I would think that any plugin should have the permission to create subdirectories without a problem.
I do have a /wp-content/w3tc/ folder. However, I’m running WordPress MU 2.9.2. The plugin should be creating /wp-content/w3tc-[mydomain].com folders for every separate domain that the plugin gets activated on. These store the cache files for that particular domain.
Unfortunately, it appears that on MediaTemple GS running MU 2.9.2 a bug in the latest releases of 0.9.0 and 0.9.1 have lost the ability to create these folders when the plugin is activated on a new domain, generating fatal input errors.
I just tried an experiment that failed miserably.
- I made sure that the latest versions of advanced-cache.php, db.php, and object-cache.php were properly placed in the /wp-content/ folder.
- I manually created a /wp-content/w3tc-[mydomain].com/ directory with sub-directories named dbcache, log, min, objectcache, pgcache, and tmp.
With this all set up, I tried to activate the plugin. It generated the fatal error again, but this time it looked like this:
Plugin could not be activated because it triggered a fatal error.
/[path]/domains/[mydomain].com/html/wp-content/db.php could not be created, please run following command:
chmod 777 /[path]/domains/[mydomain].com/html/wp-content
But the db.php didn’t need to be created! I had already copied it into the wp-content folder a day earlier!
I accessed the site with FTP and found that the plugin activation attempt had deleted the advanced-cache.php, db.php, and object-cache.php files in /wp-content/ and the entire directory structure that I had created above. They were gone! Activating this plugin causes it to eat its own files.
There appears to be a serious bug in the activation code.
I checked again and for whatever reason, the wp-content directory in plugins/w3-total-cache/ was missing. For whatever reason the distribution was incomplete. Re-downloading the plugin from WP Admin resolved the issue.
Problem solved!
While troubleshooting the “500 Internal Error” from the last release, I had mistakenly gotten the idea that I needed to manually put the /wp-content/plugins/w3-total-cache/wp-content/ files into the /wp-content/ directory.
So now it makes sense. The plugin was trying to automatically copy the files into the /wp-content/ directory and failed because they weren’t there to copy. But it assumed that the reason it couldn’t copy was because /wp-content/ wasn’t 777, even though it really was.
Works perfectly now! Thank you, Frederick. You have a great plugin and you provide great support. I think every blog out there ought to be using it.
Thanks for the clarification!
I’ve wasted half a day trying to activate this plug-in. Yes, /wp-content/ is 777, and so is /wp-content/uploads/.
Are there any instructions for manually activating the plug-in?
Thanks
@mr. Shiv, can you try to update the WP uploads path in your options setting to some other value, save the setting then restore the default and save the settings again. Then proceed to activate the plugin?
