Giters

unFocus / Scripts-n-Styles

Allows WordPress admin users the ability to add custom CSS and JavaScript directly to individual Post, Pages or custom post types.

Home Page:http://www.unFocus.com/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

upgrade() query preventing activation on large sites

ericpedia opened this issue · comments

commented

I have used and loved Scripts n Styles on my personal site, but am unable to activate it on larger sites without it timing out or running into a memory (or CPU?) error.

Depending on the server/setup, attempting to activate the plugin results in a long delay, followed by either

  • a 500 server error requiring restart of MySQL,
  • a 404 error (caused by a server error),
  • or it loads indefinitely (about 10 minutes on my localhost setup before I stopped it).

I can only activate the plugin if I remove this query from the SnS_Admin->upgrade() method:
@@@
$posts = get_posts(
array(
'numberposts' => -1,
'post_type' => 'any',
'post_status' => 'any',
'meta_query' => array(
'relation' => 'OR',
array( 'key' => '_SnS_scripts' ),
array( 'key' => '_SnS_styles' ),
array( 'key' => 'uFp_scripts' ),
array( 'key' => 'uFp_styles' )
)
)
);
@@@

Here's info on the sites:

Site A

  • 24,000 rows in wp_posts table
  • InnoDB

Site B:

  • 4,300 rows in wp_posts table
  • MyISAM
commented

Thanks for the data. I haven't been able to figure out why that query would crash anything. As far as I can figure, only a small number of posts should match the query.

Do you have any insight on why that query would cause issues? Its got me stumped.

commented

I'm not sure. Here are two ideas:

  1. It's because my posts table is large.
  2. It's because the postmeta table is large.
    Or maybe a combination of the two.

Or maybe it's something with PHP/MySQL tuning that I don't understand. The two sites mentioned above, though they have completely different configurations, are on the same VPS.

commented

I have found a site of my own that I can't activate. It's also got a huge posts table. The thing that's got me stumped is, to me, the query looks pretty straight forward, so I'm tempted to blame this on a core bug of some kind. I've got a senior dev here at work that I might be able to get to debug this after work...

commented

possibly related: http://core.trac.wordpress.org/ticket/19729 Where according to the ticket, the multiple joins on a large site would take 43 seconds in his test.

If either of the sites you have are staging, you may be able to upgrade it to trunk and see if it's fixed with that patch. The commit was done 7 days ago.

commented

One of them is a testing site, but I'm not sure what is involved in upgrading to trunk; to test this particular change, would it be enough to just paste in this edit?: http://core.trac.wordpress.org/changeset/22103

commented

There's a plugin maintained by a lead developer of WordPress (westi) called "WordPress Beta Tester". After activating that and changing a setting, you can upgrade WordPress onto the beta/nightly channel and auto-update via the admin as usual. I usually feel safer doing it that way, but this change-set seems small enough that you should be able to just apply that and roll it back out if you want.

commented

I'd test it on the site that I found that has this issue, but it's a very active live client site... clients tend to frown on that ;-)

commented

3.5 fixed the issue as far as I can tell.