JW555

Might be an idea to set this as default for plugin install.

Can you explain what we lose from the extended option?

What do you mean by the “normal” Bulk Optimize option

I changed the settings clicked save, not seen any other things, so I went to the media library where I had set the screen option to 500, selected all and tried to bulk optimize, that is when I hit the error above.

Is there some other hidden “normal” option I am missing?

Some hosting companies kill processes when they use too many CPU cycles, I know that https://bit.ly/DreamH1 allow you upload a modified PHP.INI or phprc to changes settings such as

log_errors = 1
error_log = ../phpError.log
upload_max_filesize = 512M
post_max_size = 512M
max_execution_time = 7200
max_input_time = 7200
memory_limit = 512M

You just create a folder called .php

Then under that create a folder called 5.3 or 5.4 depending on what version of PHP you are using (create both if you want)

Then in those 5.3 & 5.4 folders you add the php.ini or phprc txt file you create with the settings you want to change.

Thanks for the heads up, saved me a load of time wasted in downloading and testing this.

If you have a new version coming out can you please fix th emajor fail of WP Super cache using absolute addresses rather than relative that makes it fail a server migration

So how much time would it have taken for the plugin author to investigate this as I did today.

The solution is to exclude the the URL in WP Super Cache.

Click on the Advanced Tab, scroll down to box under the text below this:

“Add here strings (not a filename) that forces a page not to be cached. For example, if your URLs include year and you dont want to cache last year posts, it’s enough to specify the year, i.e. ’/2004/’. WP-Cache will search if that string is part of the URI and if so, it will not cache that page.”

Enter part of the URL that has the form

Click Save

Problem solved!

I had this error and I am hardly likely to buy the pro version if you can’t even sort out the bugs in the free version.

I would have been interested in the pro version or at least to see what it can do, but losing enquiries so will just install Contact7 and be done with

Hi Becky

OK there are two solutions to this.

One is to install a brand new WordPress blog (of the same version), then create folder called $dump, then drop the new WPContent folder to that $dump folder. Once completed, drop the WPContent folder from your current blog into this new blog. Then tidy it up and back it up and restore to your usual block (make a copy of the files first just in case)

Now the best thing to do is avoid the problem in the first place, in my experience the problem has NOTHING to do with prefix tables, it seems that it is that the newer version of W3 Total Cache is not backwardly compatible with some versions of WordPress. So BEFORE you upgrade W3 Total Cache, you need to update your WordPress, but before you do that decativate W3 Total Cache (do not delete it as it leaves road kill on your blog).

Now before you start make a backup of the WordPress DB and files, I always test these by installing a sub-domain (sub.mydomain.com) and restoring the blog there so I know it works.

As I write this V3.3 is available and a good speed improvement, when you click on the upgrade link it will try to upgrade the plug-ins, only upgrade those you know work with 3.3, (remember not to upgrade W3 Total Cache until AFTER 3.3 is installed and working).

So once the other plug-ins have been updated, click on the link to update to V3.3, then once it works, finally, you can install the update to W3 Total Cache.

I thought it might be helpful if we were to examine what got screwed up by upgrading the Plug-in, well this is the code at 337

337 $prefix = $wpdb->set_prefix( $table_prefix );
338
339 if ( is_wp_error( $prefix ) )
340 wp_die( /*WP_I18N_BAD_PREFIX*/’ERROR: $table_prefix in wp-config.php can only contain numbers, letters, and underscores.’/*/WP_I18N_BAD_PREFIX*/ );
340 }

So is WordPress (PHP) bad at reporting the line numbers that caused the error or what?

Let’s remind ourself of the error

Fatal error: Call to undefined method stdClass::set_prefix() in /home/username/public_html/domain.org/wp-includes/load.php on line 337

So this is the error “Call to undefined method”

and this is what is wrong with it “stdClass::set_prefix()”

So it is basically saying that something is wrong with whatever got put into “set_prefix” and what was put into “set_prefix” came from “$table_prefix”

So either “$table_prefix” has a bad value or is NULL or has a bad value

The question is WHAT SCREWED THIS UP, what is it in a W3Cache Plugin Upgrade that trashed the site?

I have had this happen at least 5 times and each time it has TRASHED my wordpress site.

The CULPRIT was the W3Cache Plugin, It had this HUGE invasive features of new upgrade listing in my dashboard and I foolishly allowed it to upgrade.

It is ridiculous that the only solution seems to be to re-install the whole of wordpress and then create some hybrid of old and new which is bound to create issues.

WordPress is very good at keeping copies of half edited versions of posts, isn’t it about time it created a backup before it allowed any Plug-in or even itself to update.

Sure we can go and make backups but is the WordPress platform so untrustworthy that before you dare touch a button you have to think “will this trash my site?”

I have see these suggestions for repairing this before and they have never worked, I have always had to roll back my site to a backup.