Opened 14 years ago
Closed 14 years ago
#17113 closed feature request (maybelater)
Core should warn when comment spam and caching plugins are not active
Reported by: | nacin | Owned by: | |
---|---|---|---|
Milestone: | Priority: | low | |
Severity: | minor | Version: | |
Component: | Plugins | Keywords: | |
Focuses: | Cc: |
Description
WordPress should implement a feature registration system for two types of plugins that every site should have: plugins that guard against comment spam, and plugins that implement caching.
When a plugin does not implement such a feature, administrators should be warned with a persistent admin notice.
The notice should then link to the plugin installation screen, to a tab that specifically shows plugins specifically in this category.
Plugins will need to implement this two-fold. One, it would be a function call, akin to add_theme_support(). Two, the plugin directory will keep a curated list of plugins for each category. Registering support is not enough to actually be returned in a search -- the plugin needs to be blessed.
Some Reasoning
What this does:
- It helps users, who often struggle with comment spam (often not even seeing Akismet is there) and often worse, with caching, when a site gets hammered. This shows them the way in clear, explicit terms.
- It helps with a perception issue that WordPress does't care about caching in core, or worse, that WordPress can't scale. Even though we've left it out of core for good reason, we still owe it to our users to solve the problem. (The same argument can be made for spam -- just because it shouldn't be core code doesn't mean it's not our responsibility.)
Implementation
How I see this API working:
add_plugin_support( 'comment-spam', __FILE__ );
add_plugin_support( 'caching', __FILE__ );
And potentially with special keywords, but I don't know what we'd necessarily leverage these for:
add_plugin_support( 'caching', __FILE__, array( 'disk-caching', 'memory-caching', 'object-caching' ) );
A plugin would not be allowed to specify a tag in the readme for the plugins directory. It would be a tag manually applied by the core team after petition and review.
There's one other consideration: An inactive but installed plugin should ideally be included in the notice, or be pushed to the top of the search results when you click through. Though this is part of a separate issue of better differentiating which plugins are already installed when searching for plugins.
Should the notice be dismissible? Probably, but maybe the comments one should be persistent anyway on edit-comments.php and possibly both under Right Now in the dashboard. Maybe it can even start in the Right Now area, and after the installation is older than X days, it becomes a more visible nag. (Prevents overwhelming a user upon installation, especially since spam and traffic would be low then.) These are UX decisions that would be made upon agreeing to implement the feature.
When and How
Implementing this consists of a decision to do it, deciding on basic user experience (particularly language and appearance), and adding add_plugin_support(). We'll also need to do some wp.org work, specifically to convert the tags to be special cases. (In the plugin installer, we can simply link to the tag, searched.)
I'll be proposing that this be added to the dev chat agenda for discussion. It needs to be done early in a dev cycle, in order to alert specific plugin authors to roll these into their plugins now, to prevent issues that would arise from failing to detect an active plugin.
Should this be done in 3.2? Well, this idea has been floated around quite a bit. It would lay some of the desired groundwork for eventually no longer shipping with bundled plugins. I've already made the case that the actual implementation is negligible work. And importantly, with regards to project scope, it squarely fits under our broad goal of "faster." Not only do we want to make the admin faster, but we want to make sure your site is fast too.
Change History (7)
#2
@
14 years ago
- Priority changed from normal to low
- Severity changed from normal to minor
I'm not sure how this helps.
Rather than nagging we should be encouraging.
Add a whole api like this just makes it look more like these things should be bundled in core.
80-90% of WP installs do not need caching.
Spam protection is a different beast but we still should be encouraging not nagging whatever we do.
#3
@
14 years ago
What about a site where you have to be registered, and people are only manually registered by Admin? (For a club where only members are registered for example).
No need for Spam plugin there, is there?
It goes without saying to turn off the nag if comments are turned off.... ;-)
#4
@
14 years ago
- Component changed from Performance to Plugins
Agree with what westi and strider72 said.
This seems more like a part of the "Setup meter" idea from GSoC.
And you can't really put it under the Performance component, since it would actually have a tiny little bit of overhead.
#5
@
14 years ago
Spam protection is a different beast but we still should be encouraging not nagging whatever we do.
That's a minor point about how it's worded. I think the core here is that we should tell people when they don't have an anti-spam solution enabled, and point them in the right direction. We can do it in a way that encourages them, and only appears when relevant.
Add a whole api like this just makes it look more like these things should be bundled in core.
Comprehensive anti-spam can't be. And comprehensive caching probably shouldn't be. But they're still real problems that a non-trivial number of people will face. Just because something isn't right for core doesn't mean we shouldn't do what we can to put them on the right path.
#6
@
14 years ago
I can see some additional value in making a system like this pluggable. Many themes offer integration with SEO systems, but rather than reinvent the wheel they just provide hooks for certain specific plugins (AIOSEOP, WordPress SEO, etc). From a theme developer standpoint, being able to detect if you have any kind of SEO plugin installed at all would be useful (as would be reminding the user to install one).
But for a first stage of implementation, being able to detect the presence (and activation status) of a comment spam plugin would be useful in core. Being able to somehow say "yes, I know, stop reminding me" would help alleviate the concerns of those who don't need or don't want anti-spam systems.
I'd also be willing to drop the caching plugins suggestion for now. I think spam is an easier problem to solve, and more people need help with spam than with caching.