id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
17113,Core should warn when comment spam and caching plugins are not active,nacin,,"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.",feature request,closed,low,,Plugins,,minor,maybelater,,