[wp-hackers] Some Left-Field names for Canonical Plugins
zamoose at gmail.com
Tue Dec 8 12:36:06 UTC 2009
On Tue, Dec 8, 2009 at 1:45 AM, Mike Schinkel
<mikeschinkel at newclarity.net>wrote:
> Thanks Matt for clarifying some of the details.
> So for more clarity can I assume that these plugins may be smaller general
> purpose plugins and not exclusively larger specialty purpose functionality?
> (If yes, I will then wonder why they shouldn't just because part of the
> >> And could some of these canonical plugins offer functionality that is
> only of use to other plugin authors (i.e. a library of routines) instead of
> all of them being only with end-user functionality?
> > A library useful to many plugins should probably be in core, since that's
> what core is for.
> From my experience unless core actually uses said functions people don't
> seem to want to include them. Thus there becomes a sad grey area for shared
> infrastructure functionality that isn't needed by core (let's say a library
> for interfacing Twitter, for example); plugins that need that shared
> functionality all end up reinventing the wheel. FWIW.
I'm working from memory here, but when Canonical plugins were discussed at
WordCamp NYC, your specific two points were addressed. The three most
commonly-mentioned use cases for a CP were: podcasting, event calendaring
and interfacing with Twitter. In the case of the last two, there are
literally tens, if not hundreds of plugins currently in the .org repository
that take on Twitter and events in largely similar fashions which wastes
effort on the part of developers (why recode what has already been solved to
a 95% level for your use case? Why not simply contribute your tweaks or
enhancements to the officially-supported Twitter plugin?) AND on the part of
end users ("Okay, which of these Twitter plugins is worth installing? There
are so many of them!"). (Less frequently-mentioned was lifestreaming
In the case of podcasting, there has been a single, titanic plugin that has
strode the landscape, crushing all others in its path: podPress. However,
its developer went AWOL a while back and recent upgrades to the core of WP
substantively broke it, which means that any sites using podPress to manage
a podcast could either 1) be safe, secure and upgrade WP OR 2) continue on
an older version of WP and simply HOPE that no one exploited the various and
sundry security issues. Not a good place to be in for anyone, as each
cracked blog contributes to the impression that WordPress is inherently
In each of these cases, the use profile for the plugins is ever-so-slightly
tangential to main line blogging and thus would merely contribute code bloat
and interface cluttering were they to be added to core, at least for users
that don't Twitter, plan events or publish a podcast.
More information about the wp-hackers