Skip to content
This repository has been archived by the owner on Jan 25, 2022. It is now read-only.


Repository files navigation

Composer Dependencies for WordPress

Table of Contents


WPLib's Composer Dependencies for WordPress is:

  1. A working Composer repository containing plugins we like including GPL-licensed commercial plugins.
  2. An example of how to create your own private/personal Composer repository using Git.
  3. Specifically for developers who build WordPress sites, plugins and themes.

When you use WPLib's Composer Dependencies for WordPress as mentioned in #2 above you can store both of the following all in one Git repository:

  1. Your complete Composer repository including all your zipped dependencies, and
  2. The CircleCI source code for rebuilding your static Composer repository.

Or you can just use this exact repository as mentioned in #1 above and just let us take care of the work for you.


You can search for available plugins or themes or other WordPress-related dependencies that we are hosting in this repository here:


Composer Dependencies for WordPress is for you if any of the following are true:

  1. You are a WordPress site developer and you:
    1. Maintain a large number of WordPress projects and each of them uses composer.json.
    2. Frequently create new WordPress projects, each with their own composer.json.
    3. Periodically cannot rebuild your sites when you need to because is down.
  2. You oversee WordPress development for an agency or other organization and you:
    1. Need to limit your organization's developers from using any unapproved plugins.
    2. Want to cut the time duplication by each of your developers managing the same dependencies.
  3. You create plugins or themes for WordPress and you:
    1. Want to make life easier for many of your customers.
    2. Would like to be an early contributor to gain exposure for your plugins or themes.
  4. You run a WordPress managed webhost and you:
    1. Would like to provide a plugin and theme repository service for your customers.


Composer Dependencies for WordPress provides some compelling benefits to Composer users.

But for you to understand those benefits you might want to first read the pros and cons of using Composer for WordPress.

Example without Composer Dependencies for WordPress

Envision you are setting up a composer.json file for a complex WordPress project that uses numerous plugins from many different sources. Those dependencies might be listed where the composer.json segment could look like this:

"require": {
    "yoast/wordpress-seo-premium": ">=3.2.4",
    "facetwp/facetwp": ">=2.5",
    "johnpbloch/wordpress-core": ">=4.6",
    "wpackagist-plugin/query-monitor": "*",
    "wpackagist-plugin/helpful-information": "*",
    "wpackagist-theme/twentyseventeen": "*",
    "wpackagist-plugin/facebook-comments-plugin": ">=2.3.6",
    "wpackagist-plugin/google-sitemap-generator": ">=4.0.8",
    "wpackagist-plugin/post-types-order": ">=",
    "wpackagist-plugin/sumome": ">=1.22",
    "wpackagist-plugin/woosidebars": ">=1.4.3",
    "wpackagist-plugin/json-rest-api": "1.2.5",
    "wpackagist-plugin/wp-cfm": ">=1.4.5",
    "wpackagist-plugin/pantheon-hud": ">=0.1.0",
    "wpackagist-plugin/carbon-fields": ">=1.6",
    "wpackagist-plugin/jetpack": ">=5.2.1",
    "wpackagist-plugin/disable-comments": ">=1.7",
    "wpackagist-plugin/duplicate-post": ">=3.2",
    "nprds/nprapi-wordpress": "dev-master",
    "algolia/algoliasearch-wordpress": ">=2.6.0",
    "wplib/wplib": ">=0.14.0",
    "wplib/wp-composer-installers": ">=1.0",
    "wplib/wp-devops": "dev-master"

Now a major annoyance of Composer is that it requires you to specify every single repository separately from where you specified the dependencies themselves. (Why Composer cannot assume it should just try looking at for a dependencies, or that is should allow developers to specify the repository inline with the dependency is beyond me?!? But I digress...)

So here is an example segment in a composer.json file for the repositories that might need to be included to support the above dependencies:

"repositories": [
        "type": "composer",
        "url": ""
        "type": "git",
        "url": ""
        "type": "git",
        "url": ""
        "type": "git",
        "url": ""
        "type": "git",
        "url": ""
        "type": "git",
        "url": ""
        "type": "git",
        "url": ""
        "type": "git",
        "url": ""

Example WITH Composer Dependencies for WordPress

If you manage a lot of WordPress projects and thus a lot of composer.json files the above repositories list can become really tedious and error prone. But with your own private/personal Composer repository you can typically reduce your repositories down to just one, two, or just a few (if you are actively developing a plugin in parallel with the site development, for example):

"repositories": [
        "type": "git",
        "url": ""

Then whenever you need to add a new plugin or theme to any of your WordPress projects you add their repository, name and version required to your private/personal Composer repository (by adding to a satis.json file – more on that in the Instructions section below) and then you only need list the specified dependencies you for each project in each project's respective composer.json file but not all the individual repositories too.


To use OUR Composer repository in your WordPress-related projects just add the following to the .repositories section of your project's composer.json file:

    "type": "git",
    "url": ""

To create your own private/personal Composer repository just clone this repo on Git and then...

[Instructions to come]


We use Satis to generate the repository and CircleCI to rebuild the repository whenever we have a update.


There are two well-known alternatives: and, both of which are useful in conjunction with Composer Dependencies for WordPress. In fact we reference in the satis.json file we use to build our static repositories.

  1. Currently Composer Dependencies for WordPress contains a much smaller list of plugins and themes than WPackagist, but we intend to grow it given interest from you and others.

  2. Unlike WPackagist Composer Dependencies for WordPress contains select commercial plugins (that are open-source) as well as forks of GitHub-hosted plugins whose source repository did not include a composer.json file.

  1. Packagist is primarily for PHP libraries whereas Composer Dependencies for WordPress is for WordPress plugins and themes.


  1. If you develop a line of plugins or themes and would like to contribute yours to this repository please tweet us at @wplib to start a dialog, or you can create an issue for discussion.

  2. If you have any GPL-licensed 3rd party plugins or themes that are not available to be downloaded by Composer and would like to change that, please fork this repo, add your contribution, and then submit a pull-request. We will give serious consideration to adding every submission.

    [Instructions to come]


Why did we build this? (And why did we build Composer Installers for WordPress too?)

Simply because we got damn tired of maintaining all those repository references in our composer.json files.

We really do have a love/hate relationship with Composer.


Today we have a starter project you can clone, modify to include your own plugins and themes, connect to CircleCI, and then start using in less than an hour.

We also have a working repository that The WPLib Team (a.k.a NewClarity Consulting) uses for development of our own client's projects. At the time of launching this repo it contains a few different GPL-licensed commercial plugins that we have purchased and like to use. But Git is not a great solution for hosting a large number of .ZIP files, so we also need to extend this project.

For the future we would like to do the following:

  1. Support hosting the repository elsewhere in addition to GitHub, critical for larger repositories. Minimally we would like to implement Amazon S3 and any (S)FTP server for deployment. We would also be interested in supporting any other file host who would be interested in sponsoring our efforts. Tweet us at @wplib if you are interested.

  2. Host all well-known plugins and themes for WordPress, including all open-source licensed commercial 3rd party plugins and themes to simplify the life of the professional WordPress site builder. Of course this will be expensive so if you are interested in sponsoring us in this effort, tweet us at @wplib for us to explore the fit.

    And if you have purchased an open-source plugin or theme that is not publicly accessible to Composer and want to see us add it to our repository you can either tweet us at @wplib or fork this repository and submit a pull request with your new plugin included. Pull request instructions below.

  3. Implement license checking for commercial plugins and themes so that vendors will even be happy for us to host their plugins and themes that they do not normally distribute publicly. Again, to simplify the life of the WordPress site builder. If you are a vendor and find this intriguing please tweet us at @wplib to get the ball rolling.

  4. Provide support for a WordPress-specific alternative to Composer so WordPress developers don't have to always deal with tools that are as complex to use as Composer when they could be must simpler.

  5. Provide a Paid Service for Agencies and Enterprises that helps WordPress professionals manage the constant barrage of plugin updates when working with highly customized sites. We are unclear what agencies and enterprises would find valuable enough to pay for a service but we ourselves can envision what we would like:

    a. Security Reviews - Access to reports detailing which plugins have been submitted to both automated and expert security review, which one passed, and which ones issues and what they were.

    b. Quality Scoring - Access to reports detailing automated and objective-criteria manual quality scoring of plugins and themes.

    c. Classifications for core, plugin and theme updates that might include:

    Classification Urgency
    New Feature(s) Nice to have, but you can postpone deployment until you are ready to test and train.
    Bug Fix(es) Useful if you are experienced problems. Test and deploy when you are ready.
    Security Fix(es) A security concern. Test and deploy when you your risk manager says so.
    Critical Fix(es) Stop everything. Test and deploy NOW.

    Of course these services would be expensive to operate so we will only be able to do so if there is demand and willingness to pay at a level that would allow such services to be profitable.

    If you like these ideas, or have other ideas about similar services your organization could benefit from please tweet us at @wplib so we can discuss your challenges and how we might be able to help you overcome them.


Interested in sponsoring this project to leverage it to promote your web infrastructure or WordPress-related business? Want us to leverage this technology to build a solution that meets your custom needs?

Tweet us at @wplib and we can discuss your needs.


Composer Dependencies for WordPress is licensed via GPLv3.
Copyright (c) 2017 NewClarity Consulting LLC. .