ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

Overrides/Improvements, OOP, Scalability

November 25, 2018 · 22:59 · Paolo Falomo
Description

PROLOGUE:

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!

Voters
+2 more
Discussion
Elisabetta Carrara (Emc2)

I learned the basic of PHP, so what you are saying about WP core being written in old PHP and extending it makes sense to me.
I think it's a LOT of work to implement, however we need to do something to "update" how WP core behaves.
Using outdated code may result in a ton more work to develop ClassicPress in the future.

James Nylen

> Using outdated code may result in a ton more work to develop ClassicPress in the future.

Unfortunately part of the problem with suggestions like this one is that we cannot remove the old code, so adding a new layer as proposed in this petition also means more work to develop ClassicPress, because we have to maintain and update both the old and the new layers.

Still, I think there are some nice benefits that could be had here, mostly API consistency. Which fields on the WP_Post object are prefixed with post_ and which ones are not? What is the difference between is_single and is_singular? Better naming and organization can help with these issues and make ClassicPress easier to reason about for plugin and theme developers.

I think it would be good to start this effort as a standalone plugin, and we can recommend it for testing. In order to be considered for merge into ClassicPress core, the plugin should have excellent automated test coverage and consistent code style.

If you'd like to put something up on GitHub under the ClassicPress name, let me know and I'll create a repository for it. ClassicPress/facades-api is one idea for the name.

James Nylen

N.B. We've created https://github.com/ClassicPress-research for this purpose, so this repository would live there instead.

Mike Schinkel

What you describe sounds an awful lot like WPLib that we built and have been using for clients for 3-4 years.

In many wants it is just objectifying WordPress (but in a good way.) The other thing it does is provide "modules," which was also discussed as a CP goal here on petitions. It really is just a thin layer of code on top of WP to try to make WP easier to work with and less fragile with respect to modifying WordPress' global variables such as in the loop.

We never documented it well enough for 3rd party use (I wish we had) but learned a lots from the process so there are many parts of it that we could use as a starting point for discussion for CP. And it is very much due for a version 2.0 with a rearchitecture based on all the lessons we've learned.

I'd love to see the benefits provided by WPLib also available in CP so we could remove those parts from our library, and get better compatibility for it (ideally there are a few hooks we need that WP just won't add).

OTOH I'd hate to have CP go down a different path where the lessons we learned from building and using it are not considered and we end up with something incompatible with what use for our client projects. #fwiw

Paolo Falomo

Thank you all for the answers. Much appreciated that i'm not the only one thinking that is a good direction.

Ashley Goodman

I understand the concerns about maintaining old code with new code.

But, I think committing to keeping the old code, and generally trying to maintain WP compatibility long term, is going to limit us severely. Eventually for CP to express the communities vision it will have to branch far enough away from WP, even WP pre 5.0 that the 2 platforms won't be interchangeable anymore.

My vote is that by the time we get to version 3 we leave concerns of WP compatibility behind us.

Along the way could interim solutions like creating wrapper API's be used to allow plugin authors to migrate and adapt at their own pace as we iteratively move CP away from WP?

James Nylen

> My vote is that by the time we get to version 3 we leave concerns of WP compatibility behind us.

> Along the way could interim solutions like creating wrapper API's be used to allow plugin authors to migrate and adapt at their own pace as we iteratively move CP away from WP?

This is a theoretical possibility, but I think version 3 would be much too soon. First, we'd have to establish a proven track record of encouraging and helping people to upgrade across breaking changes.