Archive for 20150623-Tue

Custom Repositories for GitHub Forked Composer packages

So today we had to make a custom repository so that our composer installs could look for custom changes to a particular package that was causing a problem with one of our client’s production applications.

The only current change in this particular package was a solitary “if” statement added to a single line of code. This statement checks to make sure that the object operated on is indeed an object: in certain situations in the production app it throws a fatal exception claiming a “non-object.”

First we had to ask two (rhetorical) questions:

(1) Where do PHP Composer packages come from?


(2) How do you get composer to install a non-composer package?

The first step was to fork the package on GitHub:

The original package is Piotr Śliwa’s excellent:

And the fork lives here:

We looked at simply adding the forked package to Packagist, but although we intend on maintaining this as a “real long-term fork”, that is only if this change or an equivalent fix are not added to the primary package in the near to medium term. Since that seems like an edge case, we were happy to go the VCS route. Satis and Toran Proxy just looked like overkill for this simple implementation.

Once the forking was complete, we cloned the forked package into GitHub for Mac (nice!).

We branched into “missing-object-protection” (the name of the branch will be important later).

We edited the file “lib/PHPPdf/Core/ComplexAttribute/ComplexAttribute.php”, committed the change, and pushed.

Then on to editing composer.json.

We tried to run “composer require” and “composer update” on a development version of the application, after “composer remove” took care of the original psliwa/PHPPdf package. However, we ran into the issue that our newly created PHPPdf branch no longer satisfied the requirements for the PDF Bundle dependencies that was also used by the production app!

Back to GitHub we went, and we forked:


Then we cloned that into the desktop and made a solitary commit to the new fork’s master branch: a single commit updating the requirements in that project’s composer.json.

Then we updated our repositories in our development machine’s composer.json, just after the “require-dev” entry, so it contained entries for both newly forked packages:

    "repositories": {
        "yourcomputergenius/php-pdf": {
            "type": "vcs",
            "url":  ""
        "yourcomputergenius/php-bundle": {
            "type": "vcs",
            "url": ""

We were able to leave the names the same in the “require” section of the composer.json file — one of the beautiful (and maddening) things about composer is the presence of these sorts of conventions. Composer is smart enough to figure out which packages are being replaced by custom repos.

However, we did update the “require” section of composer.json to look for the “dev-missing-object-protection” branch, as below:

        "psliwa/php-pdf": "dev-missing-object-protection"

The long and short of the day is that the application runs “composer update” and successfully grabs those two packages from the forked repos. Hooray!