Last weekend, Matt Mullenweg spoke at length about what the future holds for WordPress development. I took some time to share a brief proposal for one change that could be made farther down the road. Today I’d like to share another – more in line with Matt’s proposal that future WordPress development be focused around plugins.
Make WordPress modular.
Aren’t Plugins Already Modular?
WordPress already implements a robust plugin framework. Just about anyone can write code to extend the functionality of WordPress core by building a plugin that either hooks in to a WordPress action or modifies the return of a WordPress filter.
It’s immensely powerful, but still has limits.
For one, plugins have an inherent dependency on the underlying WordPress plugin API. This means the API has to be loaded before the plugins are loaded. It also means that plugins can merely extend the default functionality of WordPress rather than replace it.
A Modular Framework
The idea behind a modular framework requires a couple of concepts that aren’t implemented in WordPress just yet:
- Libraries as pluggable modules
- A dynamic module loader
WordPress today uses blocks of require() and include() statements to load functionality, power up the API, and make the server ready for action. This works, but it’s not very flexible.
A modular framework would first register a module loader, then register available modules, and finally load the modules as needed.
A modular framework would permit developers to replace parts of the core WordPress API with newer implementations wholesale.
What We Gain
If the future of core WordPress development lies in plugins, then we would optimally need a way to not just extend the core API with these plugins but to replace parts of it with new functionality. API refinements could then be tested by installing and activating a module rather than installing a new copy of WordPress.
Developers could also build out core API implementations specific to differing versions of PHP, without needing to force these rewrites back to the core API. Running PHP 5.5-optimized code then becomes a matter of installing a plugin rather than forking WordPress.
The Challenge
Right now, plugins are only loaded after the majority of the WordPress API. To build out a modular system, we’d need to first add a module loader, then somehow load third-party modules alongside the core modules.
One potential loading order would become:
- Load module platform
- Register core modules
- Detect and register pluggable modules
- Begin the WordPress API loading process
This means we’d need to build a module loader that is added before WordPress core. Then, rather than require()ing core modules, we would register them with the loader. Next we would detect any plugin modules (perhaps drop-ins in a /wp-content/modules directory). Finally we would process the rest of the API loading like normal.
If we decide that a core API or a set of core PHP files need to be updated in a future version, we register the new version as a pluggable module and WordPress would automatically load them in place of the core files.
Will it Work
Rather than just spout off about an idea, I plan to actually implement a prototype of the module loader over the coming weeks. As I do so though, I’m interested in what you think.
Will this potentially help further WordPress core development? If you could build a plugin that replaces a core API, which one would you work on? Is this an idea we should pursue, or just an interesting talking point?
Feel free to continue the conversation below.
