A developer, who I can only identify as CK (Got to love the old school anonymity), thinks WordPress needs to make a change in order to “save” its future.
CK starts by highlighting how filters and actions were introduced to b2 and became a cornerstone for all future WordPress development. But now the author is worried that WordPress is so big it’s in trouble.
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.
And CK has an interesting idea to fix it. In the same mind as the simplicity of WordPress actions and filters, CK wants to introduce “pre-threading” to WordPress plugins and core features.
For plugins, pre-threading would essentially be part of the plugin’s header, and an author could define the load location so that the plugin and its code are only loaded on demand, and not on every page load:
/* 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[sic] 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.
Personally, it seems like it could introduce a significant degree of confusion, as all of a sudden you open up opportunity for plugins to enter WordPress’s order of operations at any arbitrary point. Currently, authors know when they can interact with active plugins because they are all loaded before the plugins_loaded hook fires.
Though it would be nice to be able to completely avoid loading and parsing plugin code if you are certain the plugin isn’t needed on a particular pageload. But this again seems like a scenario where what the plugin author thinks is needed may not be how the site developer actually wants to use it.
This chart created by Nelio Software shows WordPress’s size by file type over time, and highlights how the codebase itself has grown steadily. But does that mean that the runtime has steadily gone up too? I’m having a hard time finding that kind of chart.
I’m sure the number of processes have gone up with file sizes, but I know work is also consistently done to make processes faster. Also, even if WordPress is more to process — as the author notes — the servers that process it and the browsers that render the final web pages are better now too.
So, I’m not sold, but I’m intrigued. While I don’t necessarily agree that WordPress is some big bloated ship that’s destined to fail without a change, I do think the idea is worth exploring. But it will take better minds than mine to determine if such an idea is feasible or generally a good one.
