WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#11861 closed feature request (fixed)

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

Reported by: archon810 Owned by:
Milestone: 3.0 Priority: normal
Severity: normal Version: 2.9.1
Component: Administration Keywords: has-patch
Focuses: Cc:

Description (last modified by dd32)

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.

Attachments (4)

11861.1.mu.diff (10.2 KB) - added by nacin 4 years ago.
Exposes mu-plugins in admin area
11861.mu.dropins.diff (17.3 KB) - added by nacin 4 years ago.
Exposes mu-plugins and drop-ins in admin area
11861.png (22.4 KB) - added by nacin 4 years ago.
screenshot of drop-ins panel.
11861.2.diff (922 bytes) - added by nacin 4 years ago.
Adds filter to allow suppression of pages.

Download all attachments as: .zip

Change History (27)

comment:1 nacin4 years ago

  • Summary changed from Add a flash-type warning if custom object-cache.php or db.php are present and in use to Show list of drop-ins and must-use plugins in admin area
  • Type changed from enhancement to feature request

+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.

comment:2 dd324 years ago

  • Milestone changed from Unassigned to Future Release

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

comment:3 dd324 years ago

  • Description modified (diff)

(for !multisite is_super_admin)

By that i meant:

(for !multisite || is_super_admin)

|| got eaten as a table?

comment:4 dd324 years ago

  • Description modified (diff)

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

comment:5 sirzooro4 years ago

  • Cc sirzooro added

comment:6 Denis-de-Bernardy4 years ago

  • Keywords health-check added

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

comment:7 follow-up: dd324 years ago

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.

comment:8 follow-up: sirzooro4 years ago

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.

comment:9 in reply to: ↑ 7 Denis-de-Bernardy4 years ago

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.

comment:10 nacin4 years ago

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.

comment:11 in reply to: ↑ 8 nacin4 years ago

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.

comment:12 archon8104 years ago

  • Cc archon810 removed

comment:13 sirzooro4 years ago

@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.

comment:14 sirzooro4 years ago

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.

comment:15 nacin4 years ago

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.

nacin4 years ago

Exposes mu-plugins in admin area

comment:16 nacin4 years ago

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.

nacin4 years ago

Exposes mu-plugins and drop-ins in admin area

comment:17 nacin4 years ago

  • Keywords has-patch added; health-check removed

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.

nacin4 years ago

screenshot of drop-ins panel.

comment:18 nacin4 years ago

(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

comment:19 nacin4 years ago

  • Milestone changed from Future Release to 3.0

comment:20 nacin4 years ago

  • Resolution set to fixed
  • Status changed from new to closed

comment:21 archon8104 years ago

  • Cc admin@… added

nacin4 years ago

Adds filter to allow suppression of pages.

comment:22 automattor4 years ago

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

comment:23 hakre4 years ago

Related / Followup: #13208

Note: See TracTickets for help on using tickets.