[wp-hackers] Less than Core, More than Plugins/Themes: Proposing Optional Modules.

Mike Schinkel mikeschinkel at newclarity.net
Tue Feb 3 01:56:18 GMT 2009

"Lynne Pope" <lynne.pope at gmail.com> wrote:
> Because FOSS projects are fluid and people come and go, 
> there is no guarantee that the number of people around 
> in the future will be able to sustain a core + modules
> + plugins + themes.

I'll give you that, but using that logic shouldn't we freeze the core at 2.7 and dissuade people from creating plugs and themes?  When all you have is a hammer everything looks like a nail, and currently all we have are plugins.  I need a screwdriver and pliers and I think many others do too?

> The problem with "lots of people" is that this is unquantified. 

Also, and respectfully, several of your comments against are also unquantifiable: 

   "most people must be pretty happy with what WP does now"
   "there are not too many new features being requested there."
   "This holds true only when meeting the needs of the module does not have a negative impact on extensibility. Unfortunately, it often does."

So maybe we should (both) stick to quantifiable anecdotes to support our assertions?  

> The rest of us are looking at what we do with WP, but 
> this does not necessarily project out to what the masses 
> want or need.

Developers and themers power end users and thus their comparing end-user requests on par with developer requests would be foolish for the platform.

> I understand where you are coming from and may even be inclined to agree sometime. At the moment though it kinda seems a bit like putting the cart
before the horse, so to speak. 

It's a chicken-and-egg problem.  With just core and plugins, we either have to reach the hurdle to get into core or doing in a one-of-thousands of plugins which doesn't result in something being standard enough that others can build on them. Optional modules would give us a one-of-ten solution.

> *If* we had some standardisation across plugins and 
> documented methods to avoid collisions, optional modules 
> would probably not be needed.

The problem with that as the "solution" is it is a holy grail. Everyone always talks about voluntary standards in every FOSS and even commercial project, and it rarely ever coalesces. Most developers (myself included) aren't fully aware on best practices for WordPress (and I'm trying hard to get get) and given then many plugin developers became programmers simply to develop their plugin means that most plugins will never be developed to standards, ever.

Optional Modules would give plugin developers something to strive for; optional modules would become the gold standard of plugin best practices. 

> Dependencies are a real problem 

Dependancies are always a problem so I'm not sure how it relates to optional modules specifically.  Can you give specific examples of how?

> and coding standards are  a real problem. 

I disagree that coding standards are a panacea; they are at best nice to have. But people who don't actively seek out to follow them won't.

I think what's far more effective is a framework that enforces it's standard; i.e. if standards aren't followed it won't work; you code access to an API wrong and you get nothing, or worse.  That's why people follow the hook system in WordPress and hence why it works so well.

> I'm not sure modules are the best way to address these
> kinds of issues.

Maybe not but status quo is causing pain too (for me, and for others on the list recently) and I've not heard other proposals. Suggestions?

Maybe instead of "Optional Modules" we instead need "Pluggable APIs" that have the same distribution and versions mechanism I've already described?

For example people have said "Don't include (certain) shortcodes in the core because it bloats." But some of those would be very valuable if standardized on. Make that a optional pluggable module.

-Mike Schinkel

P.S. Optional Modules could also be used to elevate the status of the plugins that most people believe in, i.e. All-in-one-SEO, Google Sitemap, Viper's Video Tags, etc.  Doing this would to WordPress users they can at least depend on those, and it would also make it so that plugin developers could use them as a base for their own plugins and make the assumption that they will be installed-on-demand if needed.

P.P.S. Maybe another option would be to build install-on-demand for plugins where other plugins and themes could specify that they are needed and they will be automatically downloaded and installed?  Then these best "Optional Modules" would be still be named plugins and just bubble up to the top by virtual of having others require them? 

More information about the wp-hackers mailing list