Dependency management has been a major trend for any programming language for over a decade, and that hasn’t been any different for PHP. Nonetheless, using Composer for developing WordPress plugins and applications is something that still divide the community.
While some talk about how Composer and using namespaces may organize the code and the plugin itself, others criticize their use, as opposing the WordPress core coding practices.
The truth? There are advantages and downsides of using Composer and also namespacing logic for developing WP plugins. Having that said, you should analyze what’s your intention and preferences, why not, before moving towards these tools.
Advantages of using Composer for plugins
One of the best features of Composer is the autoloading system. But pay attention: while coding with dozens or hundreds of includes and requires in PHP is somewhat old-fashioned, there is nothing “wrong” about that. However, using Composer might be giving more advantages than a “modern” or “organized” code:
- Access to any library or component in PHP
- Using plugins as packages, through WPackagist
- Autoload classes and functions
- Better control of versioning for dependencies
About autoloading, let’s use an example. Asgaros Forum is a well-coded plugin, although it doesn’t use Composer. The initial plugin file requires all classes, and then instantiate the plugin core classes.
// Include Asgaros Forum core files.
require('includes/forum.php');
require('includes/forum-database.php');
require('includes/forum-compatibility.php');
require('includes/forum-rewrite.php');
require('includes/forum-permissions.php');
require('includes/forum-content.php');
require('includes/forum-notifications.php');
require('includes/forum-appearance.php');
require('includes/forum-unread.php');
require('includes/forum-uploads.php');
require('includes/forum-search.php');
require('includes/forum-statistics.php');
require('includes/forum-breadcrumbs.php');
require('includes/forum-editor.php');
require('includes/forum-shortcodes.php');
require('includes/forum-pagination.php');
require('includes/forum-online.php');
require('includes/forum-usergroups.php');
require('includes/forum-profile.php');
require('includes/forum-memberslist.php');
require('includes/forum-reports.php');
require('includes/forum-reactions.php');
require('includes/forum-mentioning.php');
require('includes/forum-activity.php');
require('includes/forum-feed.php');
require('includes/forum-ads.php');
require('includes/forum-approval.php');
require('includes/forum-spoilers.php');
require('includes/forum-polls.php');
require('includes/forum-user-query.php');
// Include widget files.
require('includes/forum-widgets.php');
require('widgets/widget-recent-posts.php');
require('widgets/widget-recent-topics.php');
require('widgets/widget-search.php');
// Include integration files.
require('integrations/integration-mycred.php');
// Include admin files.
require('admin/admin.php');
require('admin/tables/admin-structure-table.php');
require('admin/tables/admin-usergroups-table.php');
require('admin/tables/admin-ads-table.php');
$asgarosforum = new AsgarosForum();
if (is_admin()) {
$asgarosforum_admin = new AsgarosForumAdmin($asgarosforum);
}Now, let’s say we took the same plugin and used Composer and namespaces to autoload those classes. It would result in something like this:
use Asgaros\AsgarosForum;
use Asgaros\AsgarosForumAdmin;
require __DIR__ . '/vendor/autoload.php';
$asgarosforum = new AsgarosForum();
if (is_admin()) {
$asgarosforum_admin = new AsgarosForumAdmin($asgarosforum);
}In terms of performance, to be honest, both ways are quite similar. However, when coding we would probably opt for this latter. But there more advantages of using Composer than simply autoload your classes. The main feature is definitely the possibility of requiring any PHP package with no hassle. That includes useful libraries, like Symfony components, thousands of API SDKs and even entire frameworks.
Finally, it brings the possibility of using WP plugins inside your very plugin, through WPackagist (we will be talking about it in a separate post in the future).
Possible disadvantages of using Composer in WP
Well, in spite of using Composer daily, we must admit there are a couple of downsides of using it for WordPress. First of all, WordPress doesn’t use Composer for its core, so everytime we deal with namespaces and Composer autoloading practices, we need to bear this in mind.
Some problems may occur also depending on the hosting services you are using. Needless to say that if are developing in a shared hosting, you can still have plugins working with Composer and ready to be installed, but any changes or updating in code will need to be done remotely. Anyway, coding under these conditions is already a problem itself.
Another downside of Composer – and most dependency managers – is the overuse. When we can require any library that easy, some of us tend to produce packages with tonnes of dependencies, sometimes for nothing.
But for those who criticize Composer as a tool for developing themes and plugins need to remember that most of top notch devs for WordPress nowadays are using Javascript dependencies through NPM or Yarn, JS bundlers like Webpack and more.
So, if we can rely on JS package and dependency managers, why not using a PHP tool for that? By the end of the day, WordPress is a PHP-based script, ain’t it?