WordPress is fundamentally old because the “core” has been written years ago and everything inheriting the core must maintain the same “specs”: No real use of Namespaces, no autoloading, tiny optimization and tons of “static” functions that you cannot override without action and filters (this is quite stressful for PHP).
OVERRIDES:
As James Nylen said, we have few options when talking about general core-level improvements:
Replace the old APIs with new ones. This will break existing sites and plugins.
Add new APIs on top of the old ones. This creates more ways to do the same thing, more complexity and bugs, and can be confusing. “
Personally i think this is correct but obviously limited. An option that i want to try is this:
Create new APIs that only wrap currently declared APIs but with the benefit to be extendable. So you can still do the same things with the same functions (that keeps compatibility) or you can use the new APIs that should allow you to do “more” or at least in a more semantic way.
This is something i’ve been thinking about since last year. I created a library called “wordpressify” (not even alpha - just an idea) where I’m scaffolding/experimenting this idea.
A tiny example on this:
Take the get_the_title() function.
Ideally we might have a WP\Posts\Post::title($post = 0) that returns exactly the same as get_the_title traditional function passing the same parameters. But (and that’s what i’m doing in my library) it might be used even instanced as (new WP\Post(1))->title() where 1 is the post id.
In my library the Post class extends the abstract class PostObject that implements Meta interface and so on…
As Facades principles suggest it shouldn’t be done this hard way. There should be some sort of function/parameters mapping in here.
Overrides will come in action once a proper implementation of the autoloading technology is done. PrestaShop Dispatcher class is an example here (not the best one in my opinion) but it might not be what it suits for WordPress.
OOP
Posts, Terms, Metas and any entity in WordPress should be objectified or at least recognized as Object and may eventually be part of an MVC model.
More Objectification in WordPress will be part of the previous section (refer to Improvements).
I don’t want to go deeper into this because it might be too theoretical. Just take a look at https://laravel.com/ as example of how things (in my opinion) should be done.
SCALABILITY
Code, Push, Test, Deploy.
On a business routine you might want environments where you can test features before a production deploy. You may want an easy team process when working locally (eg. the db syncs: we still need to make search replaces on the entire db). This is just a tiny part when talking about DevOps because the scalability part of this is mainly managed by cache. Cache, cache and more cache!
CONCLUSIONS
So what is the solution to all this?
I truly think that the key is on creating a framework that “only” extends what WordPress does. Exactly like Laravel does with PHP.
Laravel does not invent anything on php - it “just” allows you to make it easier, faster and (in general terms) better.
TL;DR; A Laravel-like framework but it is still WordPress… with steroids!