Show list of drop-ins and must-use plugins in admin area

[archon810]

Stemming from #10952, this ticket is a suggestion to add a warning somewhere in admin when a custom object-cache.php and/or db.php are present.

Malfunctions related to having those files can be very tricky to trace and debug, as evident from #10952.

Specifically, see ​http://core.trac.wordpress.org/ticket/10952#comment:19 for dd32's support for adding this warning.

[nacin]

+1, and also must use plugins as well.

I'm thinking these should be two page filters on the Manage Plugins page, "Must-Use Plugins" and "Drop-ins" (could possibly be one page) that would only appear if you have any mu plugins or drop-ins.

Drop-ins also include maintenance.php and advanced-cache.php, bringing the total to four.

Many of these files won't have headers. But for a drop-in, existence is a big start. And including a way for super admins to see mu plugins will only serve to encourage them to use headers on those.

I'm going to try to do a patch for this later this week. Possibly try it out as a plugin as well.

[dd32]

Just to repeat my +1

I'd be +1 for either a section on the plugin page Or a Menu item under Tools which lists (for !multisite

is_super_admin) MU-style plugins, and any override files which were present..

In the event that the file doesnt have headers, I'd list it simply as a table row with the filename.. and the description of what that file achieves.

Future release pending patch and/or core developer feedback

[dd32]

(for !multisite is_super_admin)

By that i meant:

(for !multisite || is_super_admin)

|| got eaten as a table?

[dd32]

oops, Hit the wrong button it seems. Reverted change to description.

[Denis-de-Bernardy]

I'll add the needed tests in the health check plugin.

[dd32]

I'll add the needed tests in the health check plugin.

IMO, reporting the fact that certain override files are in use there is good, I still think this should be in core.

[sirzooro]

I think it will be good to implement some mechanism for checking which plugin is the owner of custom object-cache.php and/or db.php - this information may be helpful for user too. I think of new filter, or special tag added at beginning of custom file.

[Denis-de-Bernardy]

​http://plugins.trac.wordpress.org/changeset/192650/health-check

Replying to dd32:

I'll add the needed tests in the health check plugin.

IMO, reporting the fact that certain override files are in use there is good, I still think this should be in core.

I'd take the opposite view, personally. If Health Check is bundled with core as planned, the chances are good that an end-user would run a health check when experiencing very odd issues such as this.

[nacin]

To prevent #10952 from happening, checking for existing drop-ins in the health check plugin makes sense and I suggest you add the needed tests.

The idea here isn't just to prevent #10952 from happening, though -- it is to expose the mu plugins and drop-ins in use in the admin area, because there isn't a valid reason not to provide for that.

[nacin]

Replying to sirzooro:

I think it will be good to implement some mechanism for checking which plugin is the owner of custom object-cache.php and/or db.php - this information may be helpful for user too. I think of new filter, or special tag added at beginning of custom file.

Drop-ins are often not tied to an active plugin -- take ryan's memcached object cache for example, which is simply an object-cache.php file with instructions to copy it to wp-content. I imagine db drop-ins are similar.

Some drop-ins like these do have headers, though, and we'll be able to use get_plugin_data() to read them. If they don't have them, then at the very least, we'll know that the files exist. (Same applies to mu plugins.) We could compare any headers with those from wp-content/plugins as well, I suppose, and x-ref as necessary.

[sirzooro]

@nacin: yes, but there are also ones which are ties, e.g. ​DB Cache Reloaded provides db.php drop-in. This plugin

I wonder which headers should be added for such drop-ins; Plugin Name: is not a good choice - there will be two files with this header in one dir (main plugin file and drop-in file, which is later copied to wp-content). I think that Parent Plugin (or something like this) will be better.

[sirzooro]

I have not finished one sentence above: This plugin copies this file to wp-content when cache is activated via plugin configuration page, and deletes when it is deactivated.

[nacin]

Yea, I see what you're saying. I would like to see core showing the existence and filenames of drop-ins and mu plugins -- everything else is extra.

To pair up plugins and drop-ins, I imagine core should look for identical headers. And to prevent a drop-in file sitting in wp-content/plugins from being read as a plugin, we could allow "Plugin Name" to also be "Drop-in Name". (Adding a header instead of replacing it would not prevent it from being read as a plugin, unless we modify other code which would then make the drop-in back incompat.)

Thus, Memcached could continue to use typical plugin headers, while DB Cache Reloaded could include the plugin headers (with "Drop-in Name" instead of "Plugin Name") on the file that becomes object-cache.php without it being loaded as a plugin.

[nacin]

Exposes mu-plugins in admin area

[nacin]

Initial pass on this, which exposes mu-plugins in the admin area by adding an "Advanced Plugins" subpage in plugins.php.

There's a heading on the Advanced Plugins page that says "Must-Use Plugins," with the initial intention that drop-ins can also be added under its own heading on this page. Separate subpages might be more ideal though. Any feedback on the patch is appreciated.

[nacin]

Exposes mu-plugins and drop-ins in admin area

[nacin]

Ok, new patch exposes mu-plugins and drop-ins in the plugins administration panel.

I've tracked down 10 drop-ins currently used in core:

advanced-cache.php
db.php
db-error.php
install.php
maintenance.php
object-cache.php

And in Multisite:

sunrise.php
blog-deleted.php
blog-inactive.php
blog-suspended.php

Feedback appreciated. Screenshot coming.

[nacin]

screenshot of drop-ins panel.

[nacin]

(In [13233]) Show must-use plugins and drop-ins in the plugins admin panel. First pass. See #11861

(In [13235]) Full Multisite support for dropins/mu-plugins in admin area. Ensure that network, drop-ins and mu-plugins are only shown and counted to super admins. See #11644, #11861

[nacin]

Adds filter to allow suppression of pages.

[automattor]

(In [13305]) Add a boolean filter to allow suppression of the new mu-plugins and drop-ins tabs. See #11861

[hakre]

Related / Followup: #13208