Zipping The Way To WordPress World Domination

Composer seems to be something everyone is talking about in the WordPress community these days. It is a great tool for developer productivity and code reuse. However, if you are trying to use Composer to distribute your WordPress product to end users, you might be doing it wrong ™.


… are part of the reason for WordPress’ incredible world takeover, if you ask me. Zipballs are easy to distribute and do not have any dependencies except an unzip utility of some sort. Actually, together with hooks and actions, I consider it to be one of the most important reasons that WordPress has spread out so widely. Easy development and distribution of extensions never hurt any software project.

Which leads me to: Composer and WordPress. Because that is a tempting idea for WordPress developers. To be able to pull in thousands of packages from GitHub and Packagist, just by adding them to their composer.json file. Think about the productivity gains! Composer has meant a revival of the PHP world and have helped taken things to a new level. Projects like Laravel, I believe, owes a huge part of their success to Composer and how easy they can make use of Symfony components and other open source packages. It would be great if WordPress developers, too, could benefit from this shift in package distribution.

But there is a ‘but’. Projects like Laravel and their dependencies, such as Flysystem or Monolog, are not meant for end users to install on their own. They require server configuration and other things that most of the people who ends up unzipping and installing WordPress have no clue about. There is just no way, in the near future, that WordPress developers can expect Composer to be available everywhere their code is installed.

Zip it up

Just zip it up and ship it!

I honestly believe this is the only real solution at this moment. Zip it all up and send it out there. Let the WordPress auto updater handle the installation of your code. Feed it a zipball and it will take care of the rest.


[fa type=”cogs” size=”3x”]       [fa type=”long-arrow-right” size=”3x”]       [fa type=”file-archive-o” size=”3x”]


I believe that the solution right now is to let developers use Composer, but not bother end users with it. Which is why, completely against the spirit of Composer, I support the approach of zipping Composer dependencies together with your WordPress product. It is the option at hand at this moment.

It still kinda sucks, though

First of all, zipping Composer dependencies just sucks. It is not the way Composer is supposed to be used and completely against the spirit. However, if it makes all the great PHP libraries being produced these days available to WordPress, the largest website platform in the entire world, I think it serves a good purpose.

Another thing that sucks is the obvious fact that some dependencies will be distributed twice or even more to the same user. It is likely that multiple plugins will make use of the same packages, such as Parsedown, Flysystem or Swiftmailer. This is not easily solvable, but not a major deal breaker to me neither.

Finally, there is the question of PHP versions. Composer requires PHP 5.3 and many packages requires 5.4 or even 5.5. Therefore, it is important that WordPress developers specify their required PHP version in their composer.json file, to avoid pulling in packages that have a minimum requirement that are not compatible with what they want to support in their theme or plugin.

These were some of my thoughts on adding Composer dependencies to WordPress and zipping them afterwards. If you have an opinion about this, please send a shout out on Twitter.


Want to read more like this?

Add your email address below to stay in the loop when new content arrives. You'll never miss a post.

Peter Suhm

Peter is a web developer from the Land of the Danes. He is the creator of WP Pusher and a huge travel addict.


Leave a Reply

Your email address will not be published. Required fields are marked *