Posted on dev blog re canonical plugins,…
Posted on dev blog re canonical plugins, and posted poll to weigh in on what to call them. http://wordpress.org/development/2009/12/canonical-plugins/ #wordpress
Posted on dev blog re canonical plugins, and posted poll to weigh in on what to call them. http://wordpress.org/development/2009/12/canonical-plugins/ #wordpress
Shane 5:31 am on December 8, 2009 Permalink
I still have my reservations about “canocial” plugins. Why there might be more than one developer and they be 100% complaint with WordPress when we go to debug code and then an author is having plugin trouble how can we be sure the plugins are not the ones causing it if we say ‘They work with wordpress 100%’ in which they don’t.
It would be opening more holes to finding problems and I am afraid that it’s going to staunch growth once we create official plugins that already exist.
Maybe a certification process instead, that we can say “This meets the security requirements of x.x.x version.” I know we do that with the new “Compatibility” box, but that is no way of saying that a plugin is secured.
Plus these types of plugins should not be full feature items. Some things are better in core, but that would be decided once the plugins that are going to be developed are known.
Alex M. 5:49 am on December 8, 2009 Permalink
I found your comment highly confusing, but the purpose of canonical plugins is so that rather than having 10 plugins that all do the same thing (say announce new posts on Twitter), the authors of those plugins combined their forces and develop one common, officially supported and promoted plugin. This is much like WordPress itself — we could all develop our own blogging softwares, or we can combine forces to create a single great project. Nothing is stopping anyone from continuing to make their own version of a plugin, but by making a canonical version, it ensures it’s up to date, keeps working, receives bug fixes, etc.
A really good example of why this is needed is podPress. It has over a quarter million downloads, but the author is no longer able to maintain it and a lot of people didn’t upgrade their WordPress because podPress didn’t work with the new version. This is bad. Forking it or having someone else take over also aren’t ideal solutions as what’s stopping it from happening again?
Instead we could make podPress (or something like it) a canonical plugin where it’s officially maintained and contributed to by multiple authors. It’s a plugin that’s really needed by a lot of people (podcasters) but isn’t really something that should probably be in core (lotta users, but they make up a low % of overall users).
TobiasBg 10:05 am on December 8, 2009 Permalink
I’m not really sure what to think of this concept of “Canonical Plugins”.
With the concept you presented, I have the fear that we are moving towards a “two-tier plugin society”, where non-canonical plugins will be valued less than they are now. This somehow sounds like an “App Store” for plugins, though not with all of [large computer company]‘s restrictions. Questions that I see: What are the minimum technical requirements to be “canonical”? What are functionality requirements (i.e. a small plugin that filter “the_title” is most probably secure, but what’s its value)? Who decides which plugin is considered “canonical” and when? Are there any candidates right now?
I would like to view “canonical plugins” more as core functions that are not in core but in a plugin. (This, for me, would lead to the name “Core Plugins”.) That way, people could be using/activating only what they need, with the purpose of running a WP that only loads what it needs. Examples for this could be the new image editing functions. They could be in a plugin and people who absolutely want to use [fance desktop graphics program] can disable the plugin. Those plugins would/could still be maintained by core developers (or/and strongly connected developers). Another example is Akismet, which I see as a Core Plugin, as it shows the way how those plugins could be added to core. (Yet there could be an additional screen on the Plugins page with “Core Plugins”, to more emphasize that they are activily maintained.)
Jane Wells 2:43 pm on December 8, 2009 Permalink
What you’re suggesting is pretty much exactly what we envision.
TobiasBg 7:42 pm on December 8, 2009 Permalink
Now that I read your post again, I don’t really know anymore what triggered me to write the above entry.
So, I guess, that’s a good thing 
Let’s see how it turns out.
Matt 5:16 pm on December 8, 2009 Permalink
Yes, one of my suggestions was to make a new “anti-spam” plugin that’s included with core download instead of Akismet, and have Akismet be one of the services it supports as well as Typepad, etc.
Daniel Nautré 6:13 pm on December 8, 2009 Permalink
It would be a good thing that some “heavy” features of WordPress would be present as “canonical” plugins to allow WordPress to be “lighter”.
Another thing that I would like to see, is the ability for plugins to have switches to turn on/off their features. This would allow users to have only the features they need turned on, and WordPress would only load these features while being executed.
How about porting some features of WordPress to these plugins to make the core engine lighter ?
Matt 5:37 pm on December 9, 2009 Permalink
Light is a function of user interface and speed. We can and have made WordPress lighter without removing functionality before.
Aaron Brazell 6:37 pm on December 8, 2009 Permalink
@jane I prefer “Plugin Frameworks” over canonical, but I know many in the WP community shy away from the word framework because themers have turned it into a dirty word.
Eric Marden 8:31 pm on December 10, 2009 Permalink
Framework is not a dirty word… A framework is what you used to build something useful. A plugin framework would be used to build other plugins, not to be used as a plugin directly.
Either way, framework only says ‘developer tool’ to most folks
Proposal for Core Compnents (Plugins) - Page 4 - WordPress Tavern Forum 5:32 pm on January 12, 2010 Permalink
[...] Also: http://groups.google.com/group/wp-ha…lugins&lnk=nl& Wp-devel: http://wpdevel.wordpress.com/2009/12/08/450/ There seems to be no consensus that it should done the way that its done now. IRC Log Wp dev 28 [...]