robertstaddon
Forum Replies Created
-
ururk, thank you so much for pointing this out! I upgraded from version 3.3.0 of this plugin to 3.3.6 and suddenly my multisite admin pages slowed to a crawl. It rendered this plugin practically unusable. Simply commenting out those lines solved the problem!
Why does this plugin need to scan all of the URLs of all the other networked sites in the admin bar on every single page load and switch them to HTTPS? If this feature is required, can we make it an option that can be disabled in the settings?
Why does the “wp-admin/includes/upgrade.php” file need to be required on every page load?
This seems rather inefficient to me and prone to cause problems like the one created with Types and Views.
OK! The problem appears to be that the
require_once(ABSPATH . ‘wp-admin/includes/upgrade.php’)
command on line 481 of vimeography.php causes the
if(!function_exists(‘wp_terms_checklist’))
command in Types and Views to return false instead of true.
Digging a little deeper, the problem appears to be related to the “$this->_move_folder” function calls on lines 135 and 136 of vimeography.php in the vimeography_move_folders() function.
The problem appears to be related to the
add_action( ‘init’, array(&$this, ‘vimeography_move_folders’) );
line in vimeography.php. When this line is commented out, “if(!function_exists(‘wp_terms_checklist’))” suddenly starts returning “true”.
Somehow the “if(!function_exists(‘wp_terms_checklist’))” test that Types and Views uses fails once Vimeography is enabled. How is this possible, seeing that Vimeography doesn’t seem to define it’s own ‘wp_terms_checklist’ function?
Hello joadard,
I am having the exact same problem with a DVS on Plesk. Let me know if you find out anything.
I just submitted a bug report. Thanks for taking a look!
Update: If “Page Cache Debug Mode” is turned on under Performance > General Settings, the posts page cache successfully flushes even if a static home page has been set!
It is interesting to note that GZIP files are not generated when Debug Mode is turned on. This may be related to the issue.
Hello Snackmaster!
I’m having the same problem. Under Settings > Reading Settings I have my front page displaying as a static page and my posts displayed on a blog page.
However, whenever I post a new post, W3 Total Cache doesn’t automatically purge the blog page out of the cache. So non-admins see the old cached posts page without the new post. I have to manually clear the W3 Cache.
It works fine if I turn off the static home page. But I need that option.
Did you ever find a solution?
Specs:
WP 3.3.1
W3 Total Cache 0.9.2.4I have the exact same question. I don’t remember it being set up this way before either. I think it’s new in 0.9.2.4. I’m concerned because this seems to be breaking a measure of compatibility with WordPress multisite. I have dozens of sites set up and I don’t want think I need all this multiple sets of code in my .htaccess file.
Forum: Plugins
In reply to: [W3 Total Cache] [Plugin: W3 Total Cache] Plugin triggers a fatal errorProblem 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.
Forum: Plugins
In reply to: [W3 Total Cache] [Plugin: W3 Total Cache] Plugin triggers a fatal errorI 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-contentBut 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.
Forum: Plugins
In reply to: [W3 Total Cache] [Plugin: W3 Total Cache] Plugin triggers a fatal error@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.
Forum: Plugins
In reply to: [W3 Total Cache] [Plugin: W3 Total Cache] Plugin triggers a fatal errorHmmm. 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/pgcacheThe 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].comI’m a bit bewildered. Would you like an FTP login to my site?