In my first video of the new year, I want to talk about something that’s probably never going to happen. What if we made BackPress a framework that powers WordPress and other applications? Like I said, it’s probably never going to happen, but it’s fun to think about and technically not entirely unrealistic.
What is BackPress?
If you don’t know BackPress, it’s a PHP library that was born out of the successful WordPress project. It was intended to power other projects like bbPress and GlotPress. Both have now moved towards becoming WordPress plugins and the BackPress project is no longer maintained.
It did have a lot of the functionality on board that makes WordPress so easy to use as an application framework though:
- User roles and capabilities
- Database connections, queries and data sanitisation
- Taxonomy management
- HTTP libraries
- … and much, much more
When you look at it this way, it really feels like a framework. As I said before, it’s not being maintained anymore for at least a couple years now. WordPress, bbPress and GlotPress have evolved separately, each to great success.
Not in line with the core WordPress goals
The idea I’m discussing here today is not in line with what WordPress has always tried to do, to make online publishing easier. It grew from there though, more and more people now use it as an application framework. Abstracting the core functionality into a framework and maintaining WordPress as one of the possible implementations doesn’t feel like such a long shot though.
Big step forward for developers
When I look at it in from a developers perspective, it makes a lot of sense. Let’s have a closer look at the technical consequences, should this ever happen.
All WordPress features that we have now, become optional components. Think about posts, pages, media library, revisions and so on. If you don’t like how posts are implemented, use a different component. Or even better, write your own component for it.
You can also install plugins via Composer (which you can do now already via WordPress Packagist), but then in a way that’s embraced by core WordPress. The best part about that, is that it’s not just about ease of installing plugins via Composer, you also get dependency management – something a lot of developers have been wanting for years now.
Yes, this will require lots of work. That’s the main reason why I think this is never going to happen. It’s too far from what WordPress is today.
Nothing has to change for the non-technical user
For the non-technical user who is happy with WordPress as it is at the moment, nothing has to change. The WordPress package as we know today, can still exist. It will be just a zip file, containing a ready to use software package.
The way this zip file is put together, also known as the deployment process, has to change though. It will probably involve a clean install via Composer, bundling the vendor folder with the rest of the core WordPress files.
For plugins and themes, nothing has to change. The plugin API as it exists in WordPress right now can still continue to be used. Installing plugins and themes via Composer is just an extra way for developers to use WordPress as an application framework.
Look at how Drupal 8 does it
During my holiday break, I’ve been playing with the beta of Drupal 8. In addition to bumping their PHP version requirement (yay!), they also have embraced Composer and Symfony component. This is a really big step for Drupal towards becoming a true framework. It’s much easier to extend for developers and dependency management with Composer is as good as it gets.
This didn’t make me want to start working with Drupal right away, but it did make me think about the state of WordPress as an application framework. Lots of people push WordPress to extremes already, this could be its big next step.
Am I just daydreaming now, or do you think this can become a reality one day?