Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 5 years ago

#28668 closed defect (bug) (invalid)

MU-plugins are loaded when doing a vanilla install

Reported by: jrf's profile jrf Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Bootstrap/Load Keywords:
Focuses: Cc:

Description

I just noticed that I get a bunch of database errors when I do a virgin install of WordPress. The errors are caused by must-use plugins trying to get options and such while the database tables don't exist yet.

I would suggest that for a virgin install - i.e. when WP detects an empty database and redirects to 'wp-admin/install.php' - the MU plugins (or any plugins for that matter) should not be loaded.

I realize plugins could check for the 'WP_INSTALLING' constant, but as that's also set when an upgrade is run, this is not unique enough.

To reproduce:

  • Set up an empty database
  • Unzip a copy of WP in a folder of your choice
  • Add a 'wp-content/mu-plugins' directory and put some plugins in it (for example the Yoast WPSEO plugin)
  • Add a filled in wp-config.php file and make sure 'WP_DEBUG' is set to 'true'
  • Go to your site to watch the database errors fill your screen.

Change History (8)

#1 @jeremyfelt
10 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

While it seems like a less likely scenario, there are several filters and actions available during the installation process that can still be useful to customize the installation.

Plugins that are not designed to be used as mu-plugins need a bit of extra work to avoid errors when installing. The best option may be to create a plugin loader that includes other plugins selectively depending on which part is being loaded.

#2 follow-up: @jrf
10 years ago

Hi jeremyfelt, thanks for your thoughts.

The plugin in question already implements a form of bootstrapping with sub-plugins, however whether it needs to load those is determined by settings saved to the options table.
So within the bootstrap which is run on plugins_loaded, you get calls to the database to retrieve the options which then cause the errors because the database doesn't exist yet.

#3 in reply to: ↑ 2 @rmccue
10 years ago

  • Keywords close added

Replying to jrf:

The plugin in question already implements a form of bootstrapping with sub-plugins, however whether it needs to load those is determined by settings saved to the options table.

That's something that the plugin should check for, by skipping load if defined( 'WP_INSTALLING' ) && WP_INSTALLING === true

Recommend close.

#4 @rmccue
10 years ago

  • Keywords close removed

Obviously, ticket is already closed, ignore me.

#5 follow-up: @jrf
10 years ago

While I agree with the premise that plugins should check (though there is way too much what plugins need to check IMHO which leads to many crappy plugins as most don't)...

... that doesn't take away anything from my earlier remark that the constant WP_INSTALLING is not unique enough as it's also used when an upgrade is run.

#6 in reply to: ↑ 5 @jeremyfelt
10 years ago

Replying to jrf:

... that doesn't take away anything from my earlier remark that the constant WP_INSTALLING is not unique enough as it's also used when an upgrade is run.

I haven't run into this scenario myself, but I think you can target an mu-plugin for load during an upgrade with WP_INSTALLING && is_blog_installed(). This would at least let you know if options were available.

#7 @DrewAPicture
10 years ago

  • Summary changed from MU-plugins are loaded when doing a virgin install to MU-plugins are loaded when doing a vanilla install

#8 @SergeyBiryukov
5 years ago

#47825 was marked as a duplicate.

Note: See TracTickets for help on using tickets.