#11861 closed feature request (fixed)
Show list of drop-ins and must-use plugins in admin area
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | 2.9.1 |
Component: | Administration | Keywords: | has-patch |
Focuses: | Cc: |
Description (last modified by )
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)
Change History (27)
#1
@
15 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
#2
@
15 years ago
- Milestone changed from Unassigned to Future Release
Just to repeat my +1
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
#3
@
15 years ago
- Description modified (diff)
(for !multisite is_super_admin)
By that i meant:
(for !multisite || is_super_admin)
||
got eaten as a table?
#4
@
15 years ago
- Description modified (diff)
oops, Hit the wrong button it seems. Reverted change to description.
#7
follow-up:
↓ 9
@
15 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.
#8
follow-up:
↓ 11
@
15 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.
#9
in reply to:
↑ 7
@
15 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.
#10
@
15 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.
#11
in reply to:
↑ 8
@
15 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.
#13
@
15 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.
#14
@
15 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.
#15
@
15 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.
#16
@
15 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.
#17
@
15 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.
+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.