[wp-hackers] Less than Core, More than Plugins/Themes:
Proposing Optional Modules.
mikeschinkel at newclarity.net
Tue Feb 3 02:46:49 GMT 2009
I agree with everything you wrote, but you completely missed the most important point and the impetus for my proposal. But what I'm really looking for is a set of standard APIs that are outside the scope of core. (Having plugins with end-user functionality recognized special has some benefits but I can easily part with that potential and not feel a great loss.)
What we have by analogy is a power company (i.e. WordPress core) who says "Build things that use our power", so many do but nobody standardizes the plug so everyone has to reinvent the wheel. I'm asking for a "standard plug" in areas that are outside of core.
A plugin developer can build functionality but really can't define a standardize API, standardized data repositories, nor dependency management for other plugin developers to use.
For example, I recently reviewed numerous Twitter plugins for displaying tweets on a website. Most of them were functional but none of them are even close to ideal nor even robust. I could see an Optional Module being one that provided Twitter tweet download services that downloaded them into a standardized repository, once who design has been vetting by many people on a mailing list dedicated to that optional module. Then plugin developers could easily build on top of it and create lots of great Twitter display add-ins.
Another example is NextGen Gallery. It's a nice plugin but has serious architectural flaws; it doesn't integrate with WordPress' media library and where's the album-gallery linking table? But no other plugin is even close in functionality. It we had a Image Management Optional Module it could benefit from a community process and then others who want to build functionality on top of core image management functionality could do so.
And I could go on but those two are my most recently identified examples. The past three days, at least. '-)
So, again, while I agree 100% with what you said none of what you said addresses dependency management nor the need for standardized APIs and standardized data repositories in areas that are deemed by the team to be outside the purview of core. Call it whatever you want but those are the issues I'm trying to address with the proposal.
----- Original Message -----
From: "DD32" <wordpress at dd32.id.au>
To: wp-hackers at lists.automattic.com
Sent: Monday, February 2, 2009 9:15:39 PM GMT -05:00 US/Canada Eastern
Subject: Re: [wp-hackers] Less than Core, More than Plugins/Themes: Proposing Optional Modules.
I'm going to put my one, and only comment on this thread now.
The way i see it, Is that Your (mike) looking at it in the wrong way.
"Modules" would mearly be plugins, Why call them something else?
We have Akismet, Thats a Plugin, It adds functionality which the core
does not have.
The Plugin installer lets people choose what they want, The popular
plugins section lists what most people use.
Plugins are created by people who care. Core features are created by
people who care, Aside from the small number of people who are payed
to do code whatever, The majority of Core submitters and plugin
developers make their patches/plugins based on what they care about.
I do not give a .. about spam plugins, So i do not touch that code. I
do not care about Email posting, So i do not touch that code. I do not
care about this, or that, so i dont touch it. However, Person ABC
might really care about something, so they write a plugin, THEY keep
it up to date.
The idea of having a optional plugin(Or module as you're calling it,
Obviously coming from a non-WordPress background) is pointless, IF
someone cares about a idea enough, they'll write it. Automattic
employee's have created a selection of plugins, and they generally
keep them up to date if they're useful, But the list is very limited.
(Infact,It looks like its had a trim too..
Having a plugin in core makes no difference to having a Plugin created
by someone else, Hosted on wordpress.org & marked as a Featured
plugin. If its wanted in core, Add it to core & keep it updated, Else,
Leave it to plugins to people who are going to be willing to take care
of it, and nurture it.
Yes. Having people who were loving of their plugin work & kept it up
to date in years to come, updating it every time WordPress made a
release would be wonderful, But it simply takes up time, Core
developers have a life, They'll work on one function at a time,
They'll get the job done, But I dont see the point in them working on
a plugin which they dont care about, They care about the WordPress
core, and allowing others to build it to where they want, They dont
want to be rewriting functionality in a plugin they dont care about..
(And that goes for submitters of patches, not just core devs, And yes,
I realise i've repeated myself a few times in this post)
wp-hackers mailing list
wp-hackers at lists.automattic.com
More information about the wp-hackers