Indeed, we could consider WordPress as being relatively archaic in its design; whether it is at the level of its database architecture (all standard posts in the same table, no migration system or ORM ...) or its internal architecture (-almost- no routing system, no separation of responsibilities at the code level, no template engine, ...).
To put it simply, WordPress offers a rather nice administration, a flexibility in the creation of contents and their retrieval from the database, but leaves you to do something clean with all this as soon as you want to touch the code and do something a bit complex.
So when you install a new WordPress, you're left with a few simple PHP files that mix HTML and PHP - much like we did in the 2000s - that will be increasingly difficult to work with and add new features to as more code is added. This can quickly become a challenge to maintain if you are not careful, and you can lose a lot of time, or even break some features by modifying another one.
Here is an example of what an HTML page that would be used in a classic Wordpress could look like:
We can see, if we are a trained eye, that this is an aberration and must absolutely be avoided, because here we have a very simple code but we can already feel that it is a bit confusing and that it will become complicated to maintain if we have to add more complexity to the application.
So a question came to our mind: How to improve the quality and maintainability of our WordPress applications?
From then on, we were inspired by the best practices in the field and managed to apply them, namely: respect the SOLID principles.
This acronym designates all the good practices that should be implemented in modern development projects, to gain in cleanliness, clarity, flexibility and speed.
In order to respect this, our reflection was done in several steps:
First, exit the prefabricated themes, we only make custom themes. Then, we should do without plugins as much as possible, in order to have the hand on a maximum of business logic; each customer having obviously its own needs, we must be able to adapt anything easily, without having to fight with the legacy code of the plugin or the theme.
Some plugins are still essential, such as WPML for internationalization or ACF for the use of custom fields in the different types of content. However, everything that needs to be configured in the backoffice should be avoided if possible, such as the configuration and creation of ACF fields, or the creation and management of forms, for which no plugin will be used.
Then, we had to rationalize the way pages are rendered. Indeed, by default WordPress simply loads a .php file related to the page you want to view, encouraging you to code all your logic in that same file.
To help us with this, we have opted for a well-known design pattern: MVC, thanks to which we will be able to cleanly separate our application into several small reusable modules.
An MVC project architecture is modeled as follows:
To put it simply, this is how the page rendering process should work when a user queries the server:
The client requests a page ⇒ the controller associated with it takes care of aggregating the data that will be needed to display it by calling other classes that will take care of a particular job ⇒ a template renderer compiles a file that will contain only HTML tags and the display of variables that come from the controller.
Here is a brief example of what our page might look like if we follow these SOLID principles.
Thus we obtain a clean separation of the business logic and the final file that is rendered is purified of all tags other than HTML, greatly facilitating the flexibility of our application, as each class can be easily reused by another, thus avoiding code duplication.
Of course, there are also other possibilities and good practices to adopt, which will be the subject of future articles.