Try:
– switching to the Twenty Eleven theme by renaming your current theme’s folder in wp-content/themes and adding “-old” to the end of the folder name using FTP or whatever file management application your host provides.
– resetting the plugins folder by FTP or phpMyAdmin.
– re-uploading all files & folders – except the wp-content folder – from a fresh download of WordPress.
– re-running the upgrade via wp-admin/upgrade.php
Arrrrghhh. I am getting this same error. I am running multisite and all this redo would be an extreme hassle for each of the domains. Has anybody else come up with other solutions?
Oh, and to make it more fun, not all sites are returning the error. Just some. The only thing unique is the themes. though I do get the error on the dashboard of the network admin.
@trypgirl: It is considered impolite to interrupt another poster’s thread. Please post a new topic.
@esmi
It wasn’t my intention to interrupt. I am having the same issue and wanted to add detail in order to facilitate problem solving. I will start my own thread and if I find a solution post it back here as a link in a comment.
changing line 699 of that file from
if ( 0 !== strpos( $key, $wpdb->base_prefix ) )
continue;
to
if ( strlen($wp->base_prefix) && 0 !== strpos( $key, $wpdb->base_prefix ) )
continue;
makes the error go away, but I’m not sure if it changes the behavior of this section, since I’m not familiar enough with what this bit of code is doing. (I’m not sure if an empty prefix should trigger that continue or not.)
Edit: It seems like this portion of code is also causing this problem, if that helps in troubleshooting.
Ditto, I am also on a mulstisite install, and just regained my site listing in the admin panel after manually changing the code snippet.
However, that is a hack, not a fix; it will be gone by the next update unless WordPress acknowledges that this is a bug and that it has nothing to do with plugins or themes.
Here is the change that introduced the problem. Before, they were effectively doing what I suggested above, checking the strlen of the prefix before trying that match.
I’ve left a comment on the ticket that seems to have introduced the problem.
An empty database prefix is not supported.
An empty database prefix is not supported.
If you’d like, a new ticket could be opened to suggest support for it, but we use prefixes in interesting ways, and I doubt compatibility could be uniform.
yikes. That should be in the wp-config-sample.php file. It says “You can have multiple installations in one database if you give each a unique
prefix.” I assumed that since I didn’t intend to run multiple installations in the same database I could safely use an empty prefix.
It looks like a couple years ago some work was done to support empty prefixes, why was that dropped?
Edit: Also, I’ve been using the empty prefix for quite some time, and until now have never experienced a problem (that I’ve noticed).
Well, if it works, why not break it? After all, you get fly-out menus instead of speed and stability…
since wordpress “uses prefixes in interesting ways” is it safe to simply rename all my tables with a prefix and set that in wp-config.php, or will those interesting ways cause problems with my new prefix?
No, that will kill your site immediately. You need to add a prefix (other than wp_, something more secure) to a) all tables, b) fields in the options table, c) fields in the usermeta table.
a) is straightforward, but in b) and c) fields don’t necessarily have any prefixes attached to them. How are you supposed to know which ones to change?
When I installed Wördpress (without frakking camelcase) years ago, there was NO information saying that an empty prefix was ”not supported”, and if it indeed were not supported it shouldn’t even be allowed to proceed with an empty field; that’s BAD programming.
If this later changes, Wördpress needs to accomodate for this by adding a prefix automatically when upgrading. You can’t just leave your users in the dark because you can’t program properly. This is pure evil.
You can’t just leave your users in the dark because you can’t program properly. This is pure evil.
We’re not evil, no. We restored “support” for empty database prefixes in 3.3.1. And we’ll begin to prevent installations from occurring when an empty prefix is defined in 3.4.
