frikafrax

The latest version of W3 Total Cache has a serious bug in it that affects the purging of caches. If the previous version of W3 Total Cache was working for you without any problems, it would probably be best to revert to the previous version (v0.9.5.4) of W3 Total Cache until the developers can fix things.

EDIT: I partially fixed this issue with the latest version of W3 Totale Cache by reverting all W3TC’s settings to default via the W3TC General Settings menu, disabling the Fragment Cache extension via the W3TC Extensions menu, and configuring all of my original W3 Total Cache settings manually.

But I still think it’d be better to revert to the previous version if it was running without problems for you.

Glad to hear! Thanks!

Just reporting back that I fixed the issue. The problem was in my .htaccess file and it was all due to a single question mark in a regular expression used with a RewriteCond line that broke the editor in my case.

I was using this rule in my root directory .htaccess file to deal with hack bots probing for locations of “wp-admin” in commonly used WordPress installation paths like “/wp/”, “/wordpress/” or “/blog/”.

RewriteCond %{REQUEST_URI} /(wp|wordpress|blog)/(wp-admin)? [NC,OR]

The problem is that the question mark made the “wp-admin” part of the expression an optional part of the match so the scope of the match was too broad. I.e. Any URI request with “/wp/” or “/wordpress/” or “/blog/”, regardless of whether it had “wp-admin” in it, would match that expression.

The browser calls /wp-includes/js/tinymce/plugins/wordpress/plugin.min.js when setting up the visual editor and the regular expression above would match that path.

It’s so damn obvious now, but what threw me off looking at .htaccess was that when looking at the browser debug console when switching to the visual editor, it showed that /wp-includes/js/tinymce/plugins/wordpress/plugin.min.js was called 19 times without error (returned 200 status) except for a single instance where it generates a 404 error.

Seeing 19 out of 20 successful requests for plugin.min.js each time I switched to the visual editor, and that the above RewriteCond oddly didn’t seem to break anything else besides the visual editor, put me into the mindset that .htaccess wasn’t the problem.

I realize this solution is something specific to my WordPress set-up. Sorry if this doesn’t help anyone else.

Issue resolved by re-installing the current version of AVHFDAS (at the time of this post), then de-activating the plugin again before deleting.

Looks like everything’s fine. I uninstalled then re-installed the plugin, reduced both step counts to 50 and re-indexed. No more error message.

I’ve just updated the plugin and I’m receiving a fatal error as well.

I’m posting my error message since it differs from what’s been reported above.

Notice:  Undefined index: sizes in /home/myacct/public_html/mysite/wp-content/plugins/image-cleanup/image-cleanup.plugin.php on line 747

Warning:  Invalid argument supplied for foreach() in /home/myacct/public_html/mysite/wp-content/plugins/image-cleanup/image-cleanup.plugin.php on line 747

Notice:  Undefined index: sizes in /home/myacct/public_html/mysite/wp-content/plugins/image-cleanup/image-cleanup.plugin.php on line 747

Warning:  Invalid argument supplied for foreach() in /home/myacct/public_html/mysite/wp-content/plugins/image-cleanup/image-cleanup.plugin.php on line 747

Notice:  Undefined index: sizes in /home/myacct/public_html/mysite/wp-content/plugins/image-cleanup/image-cleanup.plugin.php on line 747

Warning:  Invalid argument supplied for foreach() in /home/myacct/public_html/mysite/wp-content/plugins/image-cleanup/image-cleanup.plugin.php on line 747

I’m not a dev so I’ll take your word about there being better implementations. But I’m a bit surprised to hear that you don’t think it’s a particularly useful plugin as it is.

It was exactly what I needed for my small sites to easily clean up the thumbnail and resized image litter that had built up after making theme changes over time.

It’s a shame that so many useful plugins are abandoned.

Thank you for this update and taking the initiative.

Hi camu.

Just want to let you know I’m experiencing this same problem with the “Users By Capability” field not saving.

I’ve tried deleting the slimstat_options row then reactivating Slimstat with no luck.

I tried manually adding this to slimstat_options row:

"ignore_capabilities";s:16:"activate_plugins";

But Slimstat still shows a blank field for “Users by Capability.”

The “last” parameter tells ShortCodes Ultimate whether the current column is the last column in a group of columns and if it IS the last column, start the next column on a new line.

So if you want to have a two column lay-out, the first column’s “last” value would be “0” and the second column’s “last” value would be “1” since the second column would naturally be the last column in a two-column lay-out.

Another way to think about it is that every column whose “last” parameter is “0” will cause the next column to appear adjacent to it, provided there is enough space.

A column whose “last” parameter is “1” will cause the next column to start on a new line.

For a two column lay-out, set the first column’s “last” parameter to “0” and the second column’s “last” parameter to “1”.

e.g.

[column size="1-2" last="0" style="0"]First column[/column]
[column size="1-2" last="1" style="0"]Second column[/column]

For a 3-column lay-out, the code would be:

[column size="1-3" last="0" style="0"]First column[/column]
[column size="1-3" last="0" style="0"]Second column[/column]
[column size="1-3" last="1" style="0"]Third column[/column]

@govpatel

Thanks very much for your help. It’s greatly appreciated.

Deleting Super Cache and advanced-cache.php had no effect but the site’s back up and running properly again!

What I did was I re-installed WordPress completely from scratch into an empty directory, confirmed Dashboard was working, imported the original database and copied the plugins directory over.

Before doing anything in WordPress, I edited the database via phpmyadmin to manually de-activate all the plugins by setting wp_options -> active_plugins to “a:0:{}”. I also re-saved my permalinks settings.

I copied over the wp-content/uploads directory, then re-enabled plugins incrementally until the site seemed to be displaying and operating normally.

The odd thing was that when I first attempted a fresh re-installation of WordPress using an empty database and installation directory and no plugins copied over, I was surprised to see “headers already sent” error messages and a blank dashboard. But I met with success on the second re-installation attempt. Not sure what happened there…

I’m not sure what the cause of the Dashboard failure was since it wasn’t any of the “usual suspects.” I.e. theme, plugins, extra blank lines or white space or corrupt core files etc.

But at least things are working now.

@govpatel

Sorry, misunderstood what you were asking in your previous post.

Here’s the debug errors with all plugins disabled, TwentyEleven theme installed, and when I load the home page:

Warning: include_once(/home/myblog/public_html/neb/wp-content/plugins/wp-super-cache/wp-cache-phase1.php) [function.include-once]: failed to open stream: No such file or directory in /home/myblog/public_html/neb/wp-content/advanced-cache.php on line 8

Warning: include_once() [function.include]: Failed opening '/home/myblog/public_html/neb/wp-content/plugins/wp-super-cache/wp-cache-phase1.php' for inclusion (include_path='.:/usr/lib/php') in /home/myblog/public_html/neb/wp-content/advanced-cache.php on line 8

This is the debug errors I get when I try to load to go to /wp-admin/:

Warning: include_once(/home/myblog/public_html/neb/wp-content/plugins/wp-super-cache/wp-cache-phase1.php) [function.include-once]: failed to open stream: No such file or directory in /home/myblog/public_html/neb/wp-content/advanced-cache.php on line 8

Warning: include_once() [function.include]: Failed opening '/home/myblog/public_html/neb/wp-content/plugins/wp-super-cache/wp-cache-phase1.php' for inclusion (include_path='.:/usr/lib/php') in /home/myblog/public_html/neb/wp-content/advanced-cache.php on line 8

Warning: Cannot modify header information - headers already sent by (output started at /home/myblog/public_html/neb/wp-config.php:1) in /home/myblog/public_html/neb/wp-includes/pluggable.php on line 866

Yes, I’ve replaced all the WordPress core files, including the wp-content folder, so the TwentyEleven theme and the Akismet plugin on the server were overwritten with fresh versions from the installation archive.

The blog was recently upgraded from WordPress v3.3.1 to WordPress v3.3.2. After the upgrade, the blog was working fine until last night when it just stopped working. I hadn’t made any changes to the blog since it was last fully functional.

Currently, all the plugins are disabled (renamed plugins directory) and I’ve set the active_plugins field in the database to a:0:{} to be certain.

No luck. Dashboard is still a white screen.

@govpatel

I’ve checked for extra blank lines and trailing spaces in wp-config.php (functions.php too) and there are none.

Here’s the debug listing:

Notice: Undefined index: HTTPS in /home/myblog/public_html/neb/wp-content/plugins/wp-super-cache/wp-cache-phase1.php on line 526

Notice: Undefined index: HTTP_X_FORWARDED_PROTO in /home/myblog/public_html/neb/wp-content/plugins/wp-super-cache/wp-cache-phase1.php on line 526

Warning: Cannot modify header information - headers already sent by (output started at /home/myblog/public_html/neb/wp-config.php:1) in /home/myblog/public_html/neb/wp-content/plugins/bad-behavior/bad-behavior/screener.inc.php on line 9

Notice: get_settings is deprecated since version 2.1! Use get_option() instead. in /home/myblog/public_html/neb/wp-includes/functions.php on line 3467

Notice: wp_enqueue_script was called incorrectly. Scripts and styles should not be registered or enqueued until the wp_enqueue_scripts, admin_enqueue_scripts, or init hooks. Please see Debugging in WordPress for more information. (This message was added in version 3.3.) in /home/myblog/public_html/neb/wp-includes/functions.php on line 3587

Notice: Undefined property: s2_frontend::$s2_mu in /home/myblog/public_html/neb/wp-content/plugins/subscribe2/classes/class-s2-core.php on line 13

Notice: Undefined variable: post_title in /home/myblog/public_html/neb/wp-content/plugins/wordpress-ping-optimizer/cbnet-ping-optimizer.php on line 78

Notice: Undefined variable: post_type in /home/myblog/public_html/neb/wp-content/plugins/wordpress-ping-optimizer/cbnet-ping-optimizer.php on line 78

Warning: Cannot modify header information - headers already sent by (output started at /home/myblog/public_html/neb/wp-config.php:1) in /home/myblog/public_html/neb/wp-content/plugins/wp-mobile-detector/functions.php on line 690

Notice: Use of undefined constant wprp_init - assumed 'wprp_init' in /home/myblog/public_html/neb/wp-content/plugins/wp-reportpost/main.php on line 15

Warning: Cannot modify header information - headers already sent by (output started at /home/myblog/public_html/neb/wp-config.php:1) in /home/myblog/public_html/neb/wp-content/plugins/wp-super-cache/wp-cache-phase2.php on line 76

Notice: register_sidebar_widget is deprecated since version 2.8! Use wp_register_sidebar_widget() instead. in /home/myblog/public_html/neb/wp-includes/functions.php on line 3467

Notice: register_widget_control is deprecated since version 2.8! Use wp_register_widget_control() instead. in /home/myblog/public_html/neb/wp-includes/functions.php on line 3467

Notice: has_cap was called with an argument that is deprecated since version 2.0! Usage of user levels by plugins and themes is deprecated. Use roles and capabilities instead. in /home/myblog/public_html/neb/wp-includes/functions.php on line 3551

Notice: wp_register_style was called incorrectly. Scripts and styles should not be registered or enqueued until the wp_enqueue_scripts, admin_enqueue_scripts, or init hooks. Please see Debugging in WordPress for more information. (This message was added in version 3.3.) in /home/myblog/public_html/neb/wp-includes/functions.php on line 3587

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/myblog/public_html/neb/wp-config.php:1) in /home/myblog/public_html/neb/wp-content/plugins/si-contact-form/si-contact-form.php on line 2189

Notice: Use of undefined constant wprp_head - assumed 'wprp_head' in /home/myblog/public_html/neb/wp-content/plugins/wp-reportpost/main.php on line 63

I gone through the debug log and disabled every plugin that was reporting an error of some kind.

I also made sure that when disabling SuperCache, I removed its entries from .htaccess.

Unfortunately, still no Dashboard.

@govpatel

Yes, I’ve tried deactivating all my plugins using both the plugin directory renaming technique as well as editing the wp_options -> active_plugins field in the database but with no luck.

Usually disabling the plugins has worked for me in the past when I’ve gotten white screens but not this time.

@paul

I’ve already tried switching themes by manually editing the database with no result. The public end of the blog switches themes just fine but the Dashboard still won’t load regardless of which themes I switch to.

I don’t think it’s a hosting issue since I have three other WordPress installations on the same host. Their plugin compliment is even roughly the same as the problematic blog’s and yet they’re working properly.