This year at WordCamp Miami I had the pleasure of meeting John James Jacoby, or JJJ. Many of you may know him as the man behind BuddyPress, but I got to know him for another, older project, that he used to be involved with, BackPress.

The more I learned about BackPress, the more I became intrigued. That’s when JJJ and I started talking about the revival of the BackPress project.

The BackPress Back Story

BackPress started its life as the foundational library of WordPress. It was more or less the wp-includes directory, which granted access to all of the php functions that everyone knows and loves in WordPress code, without the WordPress ecosystem.

No quick, five minute install. No easy-to-use CMS dashboard. Just a library of code. Unfortunately the project died out—and without anyone to maintain it and few pieces of code ever making its way back into WordPress, it was forgotten.

How I Got Interested and Involved

In early 2013, I started to learn AngularJS, and I immediately wanted to connect it to WordPress. I managed to get my first theme up and running using my own crude API.

That year, Ryan McCue introduced the WP-API project… and I was hooked.

About one year later I started to realize that WordPress could be made to be a completely headless solution: all I had to do was take everything that I knew and loved in WordPress, and build out a client side application—and then the WordPress dashboard could be deleted. Why? Because I would no longer need it. I could build out my own dashboard for my users, admins, etc. to match the content of my application better than the default dashboard.

The dashboard was just the beginning. From there, I started to think about all of the other things that the server was loading and processing, and how many of those things were unnecessary.

Decoupled and Modular

Decoupling means to disengage or to remove one thing from another. A modular framework would be similar to coding with Legos. You would be able to remove and add chunks of functionality easily and efficiently. This is similar to how WordPress plugins exist today—you can add or remove them to extend functionality.

On some level, the JSON REST API provides a similar function. It keeps WordPress separated out so that you can have an application running on an entirely different system that still pulls and saves WordPress content or data.

CodeCalvary.com operates using a similar workflow. It uses an AngularJS application running client side and only uses the JSON REST API to get and save data. This works great if your application is completely separated from WordPress. But what if you are still running a traditional PHP web application and want to use other parts of WordPress’s functionality, but not all of it?  You would still have WordPress running functions (and running through logic) that you may have no need for.

But if WordPress was modular, you could simply remove components to potentially have a smoother running, and faster, website.

Replacing WordPress Components

Modularity doesn’t just mean that you can remove components. It also means that you can replace them all together.

AngularJS’s ui-router handles routing and template management pretty well.  I don’t want WordPress to interfere with this function, so I’d love to just be able to turn off that aspect so WordPress never even thinks about which PHP template to load.

With modular code you could remove a component, and more importantly, replace it. Using the same example, if you prefer Laravel or Symfony handling for file loading, you would easily be able to use them.

Dependency Management

Right now there is no easy way to handle dependencies. If one plugin defines a function, you can’t force the server to load it first, so it is defined for another plugin. With dependency management you can. This is similar to how some WordPress hooks have priority levels that you can set from zero up, but handled in a much more efficient way.

Dependency management would also include how you manage the components I mentioned earlier. With one file you could either load every component possible, or pick and choose which ones you want to use for your application.

Better Code, Better Testing, Easier to Maintain

I won’t get into the specifics, but it’s important to note that WordPress is not built with Object Oriented Programming (OOP).

OOP makes developing in PHP easier and more secure. Carl Alexander continuously writes about OOP and explains the value in using it. In a nutshell, OOP code is easier to move around, easier to built out components with, easier to test, and easier to maintain.

So let’s start with testing.

Most developers in the WordPress ecosystem probably don’t care too much about PHP testing, but it is nonetheless a crucial part of development. PHP testing can help you understand your code better, make it easier to understand for anyone coming in, and, most importantly, help you when something is wrong.

I’m most fond of writing the tests before the actual functions. That way you have a fail ready to go, and you are building out the non-fail case only. Right now, there is some testing that can be done in WordPress, but because it is not decoupled as much as it should be, it is not as easy.

With decoupled components, testing could easily be done on an individual component, making it easier to code extensions and create revisions for it. Testing each component also makes it easier to re-integrate that particular component into a package because you can make sure no tests fail on one particular chunk of code or component.

This leads me to my last point, which makes life easier with a modular framework: maintenance. If WordPress was built out of components, you could contribute to one individual component, and it could only be tested against the code of that component. This leaves the entirety of the project in a much easier place to maintain, update, and even upgrade, as you can do each individually per component.

Why Not Learn Something New, or Use a Better Framework?

Why even bother? Why not learn something new? Why not use a framework that already has what you want?

These are the questions I get asked when I talk about what WordPress could be.

I don’t consider myself locked in a WordPress bubble. I am constantly coding and learning new technologies. This is why I learned AngularJS, ReactJS, and Node.

But, at the end of the day, WordPress has a great ecosystem, and I wouldn’t be the developer I am today without it. “Other frameworks already have a better foundation” isn’t a valid excuse to not want something to be better for WordPress.

Why not have our cake and eat it too? Why tell other people to learn something new, when we can make what they are already using even better?

Revival and Vision of a Framework, BackPress or Not

That brings us back to that poor, forgotten framework from years past.

At WordCamp Miami, John James Jacoby and I decided to have a public Google Hangout session to discuss the project. During that poorly managed Google Hangout, there were some mixed reviews on the revival of the project.

Many believe it is a dead project and should remain dead.

This is not something you want to hear when you’re preparing to take on such a challenge. However, there was also a lot of support from respected developers in the WordPress community.

I think it is time for something new: WordPress as we love it, but with a framework that we can fall in love with all over again.

It isn’t about what you can’t build with WordPress today, it’s about what you can build with WordPress tomorrow.

WordPress needs this project, and, while it may take some time away from possibly contributing to WordPress’s core code, it is one of the main ways that higher-level developers will stay interested in using WordPress beyond basic sites.

Two weeks into conversation, and, while we haven’t written a line of code, we have come together with a vision for what the project is and what it can be:

  • Clean, modular code—with components
  • Built in dependency management
  • Easier to test
  • Easier to upgrade or update with latest functionality brought into core
  • Easier to maintain
  • Close to 100% backwards compatibility with current WordPress

The developers on board with the project know that getting core to re-integrate our code is a long shot; however if we meet all our objectives (especially the 100% backwards compatibility) then there’s no real reason that this project should not be taken seriously.

If you want to help out with the code or just want to be part of the conversation, you can join our weekly Google Hangout at 2pm on Tuesdays.

You can also track the project on the GitHub Repo, which includes links to our Gitter Chat used during the Hangout. Alternatively, you can follow us on the Slack Channel #backpress, which has been graciously sponsored by Advanced WordPress—join and request an invite.

BackPress isn’t for everyone, you may not code with OOP or Components now, but wouldn’t you care that the code you are using now runs on a better foundation?

Roy was born and raised in San Francisco and grew fond of computers during the Silicon Valley boom of the late 90's. Starting with WordPress in middle school with beta version 0.7 he has been an avid user and developer of WordPress since. Roy now lives in Los Angeles and works at Disney, and loves coding with the latest code and technology.

The post Is Modular Code the Future of WordPress? appeared first on Torque.

Share This