baptiste

I encountered the same problem. During the 3.7.1 upgrade of the database, all my sites got set to ‘archived’. In the wp_blogs table, I changed all the archived fields from 1 to 0 and voila! Sites working again.

Same here. Completely broken on 3.3.2. This is a display bug it seems.

On my blog, my widgets stopped working when it got to the ‘Recent News’ widget. When I loaded up the blog view, I got a 500 Server Error. The backend stuff is working as it had fetched and posted new stories, which I was able to see when I deactivated the plugin.

Bizarre. I re-enabled the plugin to test this out, but before I commented out those two lines, and now editing seems to work fine.

However, my tubepress entries in old posts are returning ‘Invalid request URI’….

I’m seeing the same thing. I clicked upgrade too fast despite the warning that 1/2 people reported it broken. With 2.4.0 active, TinyMCE will not load. I cannot edit anything. It spins and spins and you get the eidt screen, but teh content box is empty and you can’t select HTML.

Disable the plugin and everything works. Previous version worked fine. Have used this for a long time.

Interesting. I disabled the plugin entirely – ensured htaccess was clean. Re-enabled the plugin and ensured Minify was disabled – now things are working again. Disabling minify before didn’t work. I had to cycle the plugin. Now it seems OK without Minify (and gzip compression is enabled along with General, Browser, DB, and Object caches enabled)

Fingers crossed – went a number of hours with no CSS – whoops!

Same here – CSS completely broken after the upgrade to 0.9.2. Disabling minify wouldn’t get it back (source showed the minify link still being inserted) Finally had to disable the plugin after having used it for quite some time. Will try disabling gzip compression as noted in another thread to see if I can at least get the plugin half working again…

Sorry I guess I Wasn’t clear. The entry I had each filenaem listed like this:

/home/11111/users/.home/domains/mydomain.org/html/wp-content/plugins/cforms/pluginfilesblahblah.php

Now a wordpress installation won’t (or certainly should not) have files located outside of it’s root path, so basically the ‘/home/11111/users/.home/domains/mydomain.org/html/’ is repeated for every single file in the hash. When you have thousands of files on a large site, that adds up. Just seems like it would be more efficient to store the filenames relative to the WP root directory (stored in another key) It’ll also reduce the memory footprint of the plugin when it’s functioning and has to load the entire file hash in.

Agreed about the multiple entries – as I found other plugins with the same problem. Just got finished cleaning up that mess. However the sheer size of the file listing records caused the DB corruption and (thankfully I guess) brought the issues to my attention.

That said – the wpfm_listing record is still excessively big. Now that I’ve cleaned up wp_options, the table is around 1.8MB with 600 or so entries. The wpfm_listing entry by itself was almost 800KB. I’d still suggest looking into removing the ‘root path’ from every single file entry to trim the hash WAY down.

I’ll second the applause – has been a great plugin to use. Just upgraded to 2.7 which has QuickEdit and was prompted to disable the plugin (dunno if that was from your plugin or WordPress itself), which I did since it is sort of redundant. But seems like using the QuickEdit feature will take more clicks and I’ll really miss the page reordering.

The plugin worked fairly well in 2.7 (tags were broken slightly), so honestly if I find myself having to reorder pages, I’ll probably re-enable Admin extended and use it for that then disable it again to get rid of the nag message.

Great job!

Regarding the table recreate on a DB error, I wonder if something like this might be better. Here’s a change I’m testing in store.php function check_tables:

if( $retry and !$ok) {
   if ($wpdb->last_error == '') {
      $this->core->setStatus( 'database tables', false,
         'Tables not created properly. Trying to create..' );
      $this->create_tables();
      $ok = $this->check_tables( false );
   } else {
      $ok = false;
      $message .= "Database Error: " . $wpdb->last_error;
   }
} else {
   $this->core->setStatus( 'database tables', $ok?'info':false, $message );
}
return $ok;

Not a huge deal, but avoids un-necessary ALTERS. Still not sure why that ALTER has 235 in it. I mean store.php has it setup as server_url(235), but it’s still being created as 255.

Following up – I’ve been really concerned that WP-OpenID has added a ton of queries to my DB on every page load. It made no sense during a DB problem that I’d see so many SHOW and ALTER commands if the plugin was properly setup.

I’ve been combing through code to try and confirm this and if I traced it properly, it seems like this plugin is adding SHOW queries for little benefit. But I may be wrong.

startup is the bootstrap routine that adds the hooks, etc as needed. I’m assuming this gets called on every page access when the plugin is initialized. It seems that way. OK. now in startup, there is a call to late_bind before the delete_user add_action.

Looking at late_bind, there is a check to see if it’s enabled, which it would be, and then there is a check of the database tables ($store->check_tables). Looking at check_tables, it adds three SHOW commands (one for each table). I know that SHOW checks aren’t that intensive, but I’ve never seen plugins check tables on every load – they usually check a DB version variable or something. Plus, if there is any type of DB error in the SHOW, no error code check is done – it seems like the SQL return code should be checked to make sure the SHOW query succeeded before you try to recreate/alter the tables.

Why go through all this for normal page accesses? There is a TON of code included, excessive table checking, and such for every page load if I read this right. Why not try to exclude as much as you can based on the state of the user? If a valid user hash cookie exists (is one created once an OpenID auth is successful?), is there a need to keep loading everything? Can that has just be trusted until it expires? I know an unknown user who arrives has to load most of the plugin so an OpenID check can be done.

I just wonder given the size of this plugin if there might be ways to trim down what is loaded and initialized depending on various state checks that can be done already. This would significantly reduce the load of loading this plugin. I’ve noticed a slowdown for sure.

Another option might be to create an option that allows a site owner to not load WP-OpenID on every access (I would assume for auto login) and instead still requires a user to ‘login’ – ie you would only load the plugin when they were in admin, or when wp-login is loaded. This way you still get the benefit of OpenID (albeit without the ‘auto login’ potential when your WP cookie expires), but with a much lower load impact.

I’m not a mod_rewrite guru, but I’d think there would be some way to check for wordpress_ hash cookies that aren’t called wordpress_test_cookie. Would solve the problem for plugins and users hitting the login page. If I have some time I’ll try to play with some different rules.

Some plugins also set this cookie. It took me a while to finally realize my super cache was never being used. After the first hit on my site, users never use the super cache again.

sidebarLogin widget is one such plugin.

I worked around it by changing the test cookie in wp-config:
define(‘TEST_COOKIE’, ‘wp_test_cookie’);

and it fixed the problem (only in v2.3 or higher!!!), but it’s still sort of a hack. The new rewrite rules seem to be too broad. What was wrong with checking for the more specific cookies matches like

RewriteCond %{HTTP_COOKIE} !^.*comment_author_.*$
RewriteCond %{HTTP_COOKIE} !^.*wordpressuser.*$
RewriteCond %{HTTP_COOKIE} !^.*wp-postpass_.*$

I figured it out – I had a function in my include file I forgot was there and since the WP environment isn’t fully loaded in caching – it choked. Still trying to get it working properly now – just need to find the right combination of stuff to load to get the info I need (user identity) Once I figure that out, I should be all set.

I hacked it into my login page by updated the login_form function in the openid plugin. Works, though the popup covers the URL field instead of popping up below the field. I dunno – it’s a neat trick, but I figure most OpenID users will know their OpenID URL already. Guess it’s a nice option, but the fact that it loads off a server means you really can’t customize it much – like fixing where it pops up or changing the margin around the button (which seems large) Hopefully it’ll be refined some. I may leave it in, I may not. Still debating.