[wp-trac] [WordPress Trac] #17113: Core should warn when comment spam and caching plugins are not active

[WordPress Trac]

#17113: Core should warn when comment spam and caching plugins are not active
-----------------------------+-----------------------------
 Reporter:  nacin            |      Owner:
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Performance      |    Version:
 Severity:  normal           |   Keywords:
-----------------------------+-----------------------------
 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17113>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software