[wp-trac] [WordPress Trac] #16838: Excluding Akismet from Future WordPress Releases

WordPress Trac noreply at wordpress.org
Wed Dec 4 18:35:13 UTC 2013


#16838: Excluding Akismet from Future WordPress Releases
-------------------------+------------------------------
 Reporter:  sc0ttkclark  |       Owner:
     Type:  enhancement  |      Status:  reopened
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:  3.1
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------------------

Comment (by MikeSchinkel):

 Replying to [comment:29 bpetty]:
 > There literally isn't a single other free spam plugin that we could
 bundle that would actually be effective unless it also follows the same
 model as Akismet with using a 3rd party service to analyze and rank spam
 comments.

 Well, once [https://github.com/WP-API/WP-API WP-API] gets incorporated
 into core a continuously effective peer-to-peer plugin ''could'' be
 implemented that would not require such a service. The peer-to-peer
 service could have a set of 10+ volunteer central servers like how the 10
 root DNS servers work. And such a plugin would also potentially enable
 trackbacks to be usable again by allowing site owners to validate
 legitimate trackbacks using oAuth and block spammy ones.

 Such a plugin could even allow similar site to optimize for spam is
 outright blocks. For example, I have a blog about WordPress plugin
 development and posters who use the author name ''"Hollister Outlet"''  or
 ''"Abercrombie"'' should be outright blocked vs. tagged as spam. However
 having 'WordPress"'' in the name should not be a concern per se on my
 blog. But for a fashion blogger, the reverse is probably true.

 A peer-to-peer plugin could even possibly orchestrate a denial-of-service
 attack on the spammer!
 ''(Or not. I can wish. :)''

 Maybe this could be a potential [http://make.wordpress.org/core/2013/11/27
 /features-as-plugins-register-your-interest/ Feature-as-Plugin]?  Having a
 viable alternative certainly would remove reason to ignore this ticket.


 > Anything else would be defeated terribly within months of releasing it,
 and we'd be back at square one anyway. … I don't believe we have any
 requirement to provide another bundled replacement.

 I respectfully disagree with that. See above.

 > I believe history has proven that there needs to be some diversity here,
 and with that, WP needs to have a requirement that it doesn't unfairly
 favor any single solution (by bundling it by default).

 Agree with that. Unless the solution is a core ''(and extensible)''
 feature.  Then I think a single solution is preferable; remember pre 3.0
 vs. custom post types?

 -Mike
 P.S. BTW, I recently wrote [https://github.com/hardcorewp/spam-blacklist a
 Spam Blacklist plugin] because I was getting over ~500 Akismet spam-tagged
 comments a day on a very low traffic blog.  The plugin mined the 100,000+
 spam I had received to create a **block** list by author, IP, email and
 URL, and if blocked it throws up a screen offering to whitelist the person
 if they contact me.

 **It was a blunt force approach to solve ''my'' problem** and has many
 issues so it's not a general solution but the core concept was to
 **block** ''(vs. just spam-tag)'' what is easily identifiable as spam
 ''**on my unique blog**'' given the history of spam on my blog and the
 topics I write about, and then giving letting the commenter know their
 comment was blocked so they can contact me to allow them to be
 whitelisted.

 So I think having a peer-to-peer spam plugin architected and built for
 core that takes into consideration each site's content could go a long way
 to finally resolving the ongoing spam problem in addition to satisfying
 the concerns raised by this ticket.  FWIW.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/16838#comment:30>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list