Creating satis composer private repository for wordpress themes and plugins

7
votes

My objective is to have a composer.json file committed to our project repository that specifies what theme(s) or plugin(s) should be used for that project and when a developer pulls down the repo all they need to do is run composer install. We want to keep the plugins out of the project repo to stop the bloating of the project repo and it becoming slow to pull and push.

For standard wordpress plugins such as "Jetpack by WordPress.com" this is fine as we will use https://wpackagist.org/. However for Premium paid for plugins and custom made ones in house that cannot be open sourced we want to host them in a Private Composer Repository.

Because we will have multiple versions of these plugins I would like all versions to show such as 1.1, 1.2, 1.3 so the developer can specify in the composer.json which version is required, e.g. if a future version breaks something and we need to rollback to previous version.

I have read through the basics of setting up a Satis private repository which I have done so but I cannot get it to loop through the git tags of the versions and also specify that its a Wordpress plugin and install it in the correct location.

This was my first attempt in which it gets all git tagged versions:

{
    "name": "Private Repository",
    "homepage": "http://packages.privaterepo.com",
    "repositories": [
        {
            "type": "vcs",
            "url": "[email protected]:companyname/project.git"
        }
    ],
    "require-all": true
}

And this is one where I have to specify the version but get it to install in the correct Wordpress plugin location:

{
    "name": "Private Repository",
    "homepage": "http://packages.privaterepo.com",
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "company/project",
                "description": "WordPress Plugin",
                "version": "1.0",
                "source": {
                    "type": "git",
                    "url": "[email protected]:company/project.git",
                    "reference": "origin/master"
                },
                "type": "wordpress-plugin",
                "require": {
                    "php": ">=5.3.2",
                    "composer/installers": "*"
                }
            }
        }
    ],
    "require-all": true,
    "require-dependencies": true,
    "extra": {
        "installer-paths": {
            "wp-content/plugins/{$name}/": ["type:wordpress-plugin"]
        }
    }
}

Can anyone advise how I get both of these scenarios to work together?

1
phpwordpressgitcomposer-phpsatis
I do something very similar to you and the only difference I can see is that I I don't use require-all I require them all one by one (so "require":{ then a list). This works fine for me and the private plugins install with the wpackagist ones etc... – Simon Pollard
Which version of the code are you referring to the first or second? – Phil Cook
Sorry Phil, the second. And for the reference Under source) I was using the tag. – Simon Pollard
Thanks Simon thought I was on the right track, could you send me an example of tag you mentioned under the source. I think the only problem here is that I will need to update the satis.json file for each version of each plugin which with a large team like I have this would become a daily task which is what I am trying to avoid. Instead I just want it to read the Git Tags automatically. If this is what you are doing if you could send an example please. – Phil Cook
Ahh I am getting specific tags per plugin in one big composer file. So not sure it would actually be any use to you. My file is for a website and pulls in multiple plugins etc... I think what you are doing is different to this. – Simon Pollard

1 Answers

0
votes

I think I have a similar setup: In the local Satis repo we have both internal packages from a private Git server, and all external packages from Github.

The trick is to do two steps: Step one only pulls the metadata of all external packages, and this is where your version range comes into play to avoid pulling EVERYTHING.

The second step will scan through all local Git repos and detect all versions, and additionally will add the Composer repo created in step 1.

Effectively you will deal with two Satis configurations that will create two results, and the result from the first job for external packages will only fetch all metadata, and in the second step it is imported and used just like a local Git repo, and configuring that second step to scan for "all" versions and possibly creating ZIP files from them will create a nice local backup copy of every package you might need.

Or in other words:

satis-external.json

{
    "repositories": [
        {
            "type":"composer",
            "url":"https://packagist.org"
        }
    ],
    "require": {
        "any/package":">=2.0"
    }
    "output-html": false,
    "require-dependencies": true
}

Run it:

php -dmemory_limit=2G satis/bin/satis build satis-external.json external/

satis-internal.json

{
    "repositories": [
        {
            "type": "composer",
            "url": "http://url/from/external/above"
        },
        {
            "type": "vcs",
            "url": "ssh://internal/gitrepo.git"
        }
    ],
    "require-all": true,
    "archive": {
        "directory": "dist",
        "format": "zip",
        "prefix-url": "https://whatever/youneed",
        "skip-dev": true
    }
}

Run this

php  -dmemory_limit=2G satis/bin/satis build satis-internal.json internal/

Adding a "type=composer" repository in Satis will make that act like any other repository - especially it will download ALL packages mentioned there if you "require-all=true", so be careful not to add Packagist or any other repo directly.

Also note that "require-dependencies" is true for the external packages because you likely won't want to go through the hassle of adding every dependency of the packages you want to use.

If some of your paid packages offer remote repo access, you can add this repo in the external configuration together with access credentials - it should work.