To Save the Future of WordPress, Steal This Idea…
A Little History…
Nearly 13 years ago, Michel Valdrighi quietly added some code to his
program which unknowingly was to become one of WordPress’s greatest abilities:
That code commit back in October 2002 contans a single note: “now with b2_filter support !” – perhaps the exclamation point exposing a little thrill that this was something new and exciting, but I have to wonder if he could actually imagine what it really meant for the future.
In fact with the addition of those functions “add_filter/apply_filters” one can begin to easily recognize some of the oldest source code as WordPress itself, compared to earlier versions.
For the first time, coders could affect the code output in a standardized way,
without directly modifying the core of the program. It gave b2 tremendous potential.
b2/cafeblog version 0.6 would shortly afterwords be taken over by Matt Mullenweg, simply renamed and re-released as WordPress 0.7 with few other modifications. But even more filters and later a related ability called an “action” were widely adopted.
All the work by by Michel Valdrighi (and later the wholesale adaptation of Justin Vincent’s EZSQL) which breathed life into WordPress are virtually unknown to the millions of users today. Their names are only mentioned once without any weight, buried in the source code.
The Present Day…
When I say WordPress needs “saving” people might understandably think I am crazy. Matt regularly boasts how many millions of people are using it, both standalone and on his hosted service WordPress.com – one could never imagine it fading away at this point.
But here’s the ugly truth – WordPress is the Titanic and its going to rip apart based on it’s own sheer weight. The iceberg is dead ahead and its name is massive bloat. Each year it grows bigger and more troublesome and more dangerous with every new release.
WordPress’s dirty little secret is that it has only one way to run – virtually ALL it’s code, megabytes of it, must be loaded, every single time, to create any single page. It never gets smaller and always grows with every release as mandatory “features” are folded in.
Numerous caching plugins have been invented to desperately offset this problem but on busy sites where there are constant cache misses and constant clearing of caches with new posts and new comments there is no way to avoid the growing problem.
Fortunately servers grow more and more powerful and less expensive to operate each year which compensate for some of this performance problem – and PHP keeps getting faster – PHP7 will double the performance of all previous versions. But even today, get several editors mucking about in the admin area and you will certainly see the strain of resources across the entire system.
And just try to find a WordPress installation that runs without plugins today. The average website uses at least a dozen as the desire for uniqueness, customization and functionality grows. Plugins are the very life of WordPress, there is no way it would be so popular without the thousands of free extensions and mods that are available to anyone who wants all their abilities.
However all these plugins also load virtually all their code, every single time, on every single page. Hundreds of files, megabytes of code, regardless of the output. Iceberg dead ahead!
While working on a bbPress replacement of my own, I wanted to have the best of both worlds, custom plugins which could richly enhance the core program, but not suffer from the massive bloat that WordPress has experienced over the years. It seemed to be a dichotomy.
Why should plugin authors have huge amounts of code load on every single page for every single user like WordPress does? Previously on my bbPress plugins I created a way to have a “stub”, a little piece of code that would detect when to load the admin functions. But even that was wasteful, it was just another file that still had to be loaded and parsed every time.
So now I give you my simple evolved solution that is inspired by Michel Valdrighi filters from nearly 13 years ago. It’s 100% backwards compatible and is incredibly easy for plugin authors (as well as core developers) to apply to their work, and forever save WordPress from the threat of it’s own sheer bulk.
What if a plugin could load “on demand”. Even parts of it, only if and when it was finally needed, instead of every page load?
What if this was as simple as taking advantage of those very helpful filters and actions scattered throughout WordPress?
What if it was as simple as plugin authors declaring where and when their plugins should load, with just one line in their plugin?
Starting to get the idea? Here’s how simple this is and the mystery is why no-one else has done it for nine years.
Every plugin has a header, it’s mandatory, at least the Plugin Name:
/* Plugin Name: Your Plugin Author: Your Name Version: 1.2.3 */
Now imagine one tiny addition:
/* Plugin Name: Your Plugin Author: Your Name Version: 1.2.3 Load on Action: admin_init, 9 */
What does this mean? Well during the installation/activation of the plugin,
WordPress could now can see and parse that special header “Load on Action”
It adds this to it’s database, just like it currently stores all the plugin names and locations, when to load the plugin!
Before any plugins are loaded, WordPress loads it’s database.
It can easily and extremely quickly parse this kind of threading declaration
then simply add the actions (filters) from each plugin to load the file,
only if and when it hits that filter/action later in the page loading process.
The “9” is an optional priority – it simply means it would load before other plugins or actions that might have the unlisted default priority of 10. Only use it if you need it.
Why is this all so beautifully simple, yet important?
Well you no longer need any kind of master code or “stub” to load any part of your plugin. Large parts can simply be left standalone and WordPress will know when and where to load them.
Admin functions can be completely on their own. Registration functions can be on their own. Feed functions can be completely on their own. If they are megabytes in size it doesn’t matter, they do not affect all the other page loads.
Now think bigger – even CORE functionality can work with this.
Instead of guessing what it needs to include for unknown later processes,
load the functions only if and when it reaches that point.
Pre-thread the core and let it determine what it needs later.
Have different situations where one action might not happen but another? Simply list more action lines. The pre-threading would track if the plugin was loaded and do it only once, like “require_once” (but faster as PHP has a performance penalty for “require_once”).
What about all the huge legacy of existing plugins? Well they will still work exactly as they are and load at the regular plugin loading time because they will not have the extra header. Meanwhile newer plugins with threading can load before, after or not at all anywhere in the page loading process.
I hope to see this functionality in WordPress 4.4
But I have bug reports from half a decade ago that were only recently fixed in 4.x
So I guess I will wait and hope for sometime by the end of the decade…