#28668 closed defect (bug) (invalid)
MU-plugins are loaded when doing a vanilla install
Reported by: |
|
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
@
9 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
#2
follow-up:
↓ 3
@
9 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
@
9 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.
#5
follow-up:
↓ 6
@
9 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
@
9 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.
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.