Reduce DB queries during install by limiting use of wp_load_alloptions()

[donncha]

This is ​http://trac.mu.wordpress.org/ticket/1192 on the original MU Trac.

Creating a new blog through the signup form uses about 700 queries. This patch reduces this by about half by not populating the option cache all the time.

This patch applies to the MU 2.9 branch.

[nacin]

Closing #11997 as a duplicate of this.

[wpmuguru]

(In [12973]) Reduce DB queries by half during MU signup, props donncha, see #12140

[donncha]

Applied the patch above in ​http://trac.mu.wordpress.org/changeset/2072 and works for me and wpmuguru. Leaving this open for more feedback.

[nacin]

This applied not only to MU signup but to regular WP installs as well. This does cut down the number of queries, though I'm curious what other effects it may have and it deserves a second look.

Cross referencing #12144 -- it doesn't look like this was tested with WP_DEBUG, and some notices snuck in.

[nacin]

(Fixing spelling mistake in summary -- I'll get it right eventually.)

[dd32]

Has anyone noticed any side effects that might be related yet?

[wpmuguru]

(In [13445]) cleanup warnings - add site, See #12140

[wpmuguru]

That was the notices when adding a site/blog in a network scenario. I've created 20+ sites since applying donncha's patch with no issues. I did not test doing a new install with WP_DEBUG.

[nacin]

I was curious whether we did any damage to the non-multisite install process... Doesn't appear to have any side effects, but my head hurts when I start going through the install step by step.

[wpmuguru]

On that MU ticket there was a log of the queries - kind of whoa.

dd32: if you do a fresh install with DEBUG and get no warnings, I'd suggest closing the ticket.

[wpmuguru]

By this time we must have had lots of installs & have had no reported issues. Closing pending a reported issue.

[westi]

Found an issue with this :-)

wordpress-tests does everything with WP_INSTALLING defined (unfortunately)

And this has broken cron in that environment.

Basically get_option is caching on fetch from db but update_option isn't overwriting it.

[westi]

(In [14502]) Don't cache option values while installing. See #12140.

[westi]

That papers over the cracks so the API is consistent.

Needs more review to ensure that this is correctly implemented

[wpmuguru]

(In [14515]) consistency & simplicity in get_option(), see #12140

[ryan]

Fixed?

[nacin]

A hunch, this may be breaking plugin inclusion on wp-activate.

[nacin]

This did indeed break plugin inclusion on wp-activate.php.

[nacin]

Cross referencing ​http://trac.mu.wordpress.org/ticket/1151

[nacin]

And #12022, which is the MU 1151 ticket copied over.

[eddiemoya]

#12022 started in the forums, and more conversation took place there.
​http://mu.wordpress.org/forums/topic/15324?replies=11

[jpotkanski]

Watching.

[westi]

Replying to nacin:

A hunch, this may be breaking plugin inclusion on wp-activate.

Plugins aren't included in wp-activate because it has define( "WP_INSTALLING", true ); at the top and we don't include plugins while installing.

[eddiemoya]

Replying to westi:

Plugins aren't included in wp-activate because it has define( "WP_INSTALLING", true ); at the top and we don't include plugins while installing.

That is correct, and we figured out that removing that WP_INSTALLING allows the inclusion of plugin function. They are necessary because some themes depend on plugin functions to generate parts of the header/footer, which wp-activate pulls in.

The only thing I am not certain of is what the negative effects of removing that constant are. It was put there for a reason, and taking it out must have some effect. I will do some testing but perhaps someone else already knows the answer. Some discussions elsewhere lead my to presume that its removal will negatively effect the activation process itself somehow.

[ryan]

WP_INTALLING prevents certain cache operations that can lead to bad values being inserted into blogs during install_blog(). The answer here is probably to have separate constants that control loading plugins and shorting cache operations. Activation, I believe, can get away with allowing plugins to load.

Ideally, plugins that mess with activation would be mu-plugins and avoid the whole mess. Such plugins seem perfect candidates for being in mu-plugins.

This issue predates 3.0 and is not a result of this ticket. Several releases ago plugins stopped being loaded when WP_INSTALLING to accommodate auto upgrades.

Since this is not a 3.0 regression and requires a good amount change and re-testing to remedy, this is not going to be fixed for 3.0. I re-opened #12022 against the 3.1 milestone. There we can fracture WP_INSTALLING into separate constants for controlling cache shorting, plugin loading, installation, and activation.