Even though WordPress has been around for 22+ years (released on May 27, 2003), it is by no means an aged CMS framework.
Two recent improvements in its core showed us that the community behind WordPress is looking to modernize the most popular CMS. Those are the inclusion of JavaScript-based Gutenberg editor as part of the core and the upgrade of minimum PHP version to 7.4 or greater.
The Editor
Gutenberg as part of the core has added modern capabilities for building sites on the frontend. Blocks, a high-level component resembling React’s, are the basic unit to build a webpage’s frontend nowadays. In my opinion, shortcodes, custom fields and metaboxes will soon be a thing of the past, while Gutenberg will probably take over as a full development platform.
Updated PHP min version
By raising the required minimum version of PHP, the WordPress backend has access to the whole collection of PHP’s Object-Oriented Programming features (such as classes and objects, interfaces, traits and namespaces). All these modern PHP features make up of a component coding approach. No more sub-optimal code because of a backwards compatible PHP version.
Components
A component is not always just an implementation, like in React, but more of a programming approach. A coding concept that applies to frontend (CSS like Bootsrap, Bulma or JS like React, Vue) as well as to the backend. The ability to package a specific functionality, decoupling it from the main the application, allows it to be tested and bug-fixed very easily, thus making the application more maintainable in the long term. Improving our productivity by not having to reinvent the wheel each single time is something well known already, so I will not get into more details about packaging, modularization and componetizing a website.
Composer & Packagist
Composer and Packagist have become key tools for establishing the foundations of PHP-based applications. Packagist is essentially a directory containing PHP code out of which Composer, a PHP-dependency manager, retrieves packages. Their ease of use and exceptional features simplify the process of importing and managing own and third-party components into our PHP projects.
Composer allows to declare the libraries the project depends on and it will manage (install/update) them recursively. Similar to NPM, package.json file and node_modules directory, Composer only needs a composer.json file and the vendor/ directory to be ignored in our git to have the project dependencies under version control. This keeps our project’s code thoroughly decoupled from external libraries.
Composer offers plenty of additional features, which are properly described in the documentation, and even in its most basic use, offers developers unlimited power for managing the project’s dependencies.
Enter WPackagist
Similar to Packagist, WPackagist is a PHP package repository. It contains all the themes and plugins hosted on the WordPress plugin and theme directories, making them available to be managed through Composer.
Packages available in WPackagist have been given the type “wordpress-plugin” or “wordpress-theme”. As a consequence, after running composer update, instead of installing the corresponding themes and plugins under the default folder vendor/, these will be installed where WordPress expects them: under folders wp-content/themes/ and wp-content/plugins/ respectively.
Limitations
Composer makes it a breeze to manage a PHP project’s dependencies. However, WordPress’ core hasn’t adopted it as its dependency management tool of choice yet, so it is outperformed by newer frameworks like Laravel that incorporate Composer (since 2013) as part of their architecture.
How deep we can integrate WordPress and Composer together depends on the freedom we have as developers on the project. If the developer can have absolute control of how the software will be updated, e.g. by managing the site for the client, or providing training on how to do it, then we can incorporate Composer in WordPress with no problems.
However, WordPress focuses primarily on the needs of the end users first, and only then on the needs of the developers. For example, a developer can create and launch the website using Composer, and then hand the site over to the end user who might use the standard procedures for installing themes and plugins, bypassing Composer. Since we can’t ask end users to execute a command such as composer install for this, we need to release plugins with all of their dependencies bundled in. That defeats the whole components approach and Composer itself.
In our own websites though, where we have full control on the deployment of updates, Composer can be used for managing the site completely.
As opposed to traditional WordPress setups, Composer treats WP core as a site’s dependency and not as the site itself, that’s why it installs it in a sub-directory. To make it easier to completely manage WordPress with Composer, several projects have taken the stance of installing WordPress in a subfolder. Roots provides a WordPress boilerplate called Bedrock, that I can personally vouch for since we’ve used it on a large multisite WP network for the past 3 years.
WordPress through Bedrock or manually
Bedrock is a WordPress boilerplate with an improved folder structure, which looks like this:
├── composer.json
├── config
│ ├── application.php
│ └── environments
│ ├── development.php
│ ├── staging.php
│ └── production.php
├── vendor
└── web
├── app
│ ├── mu-plugins
│ ├── plugins
│ ├── themes
│ └── uploads
├── wp-config.php
├── index.php
└── wp
There are many improvements introduced here that are out of the scope of this page. The people behind Roots chose this folder structure in order to make WordPress embrace the Twelve Factor App, and they elaborate how this is accomplished through a series of blog posts.
Managing WP with Composer can also be done manually by setting our composer.json file, following this awesome recipe based on core contributor John P. Bloch’s mirror of WordPress’ core.
Either way, and with the freedom to shape the project’s folder structure, we can achieve our requirement of completely managing a WordPress site, including the installation of the core, themes, and plugins.
Conclusion
Composer, first released in 2012, is not what we would call “new” software, however, it has not been incorporated to WordPress’ core due to a few incompatibilities between WordPress’ architecture and Composer’s requirements. And of course, due to the fact that WordPress allows end users to install/update dependencies (plugins), even edit code files directly in wp-admin. That freedom is what made WP so popular but that freedom comes with a cost.
With the launch of Gutenberg and the bumping up of PHP’s minimum required version, WordPress has entered an era of modernization which provides a great opportunity to rethink how we build WordPress sites to make the most out of newer tools and technologies. Composer, Packagist, and WPackagist are such tools which can help us produce better WordPress code, with an emphasis on reusable components to produce modular applications which are easy to test and bugfix.
But that means taking back some of our clients freedom.
Top comments (0)