To be honest I don’t even know why I’m writing this out. For quite some time I have been looking and trying to read more about how Composer works. The reasoning behind that is I was asked to take lead on a project at work. Nothing like not understanding how something works and being thrown in the deep end, right?

Okay, that’s not really true since I do know some about how Composer works. I have a previous role to thank for that too. It introduced me to some of the basics, it also helped give me a few headaches and some cardio for the day on some occasions. It was when pushing to production didn’t quite go as I had expected. Learned about Git on that one.

Now, the project I was asked to be a part of was something I had looked into quite some time ago and never really got a chance to dive deeper into. It was Bedrock. More specifically Sage. I had helped a person out in getting a site up and running using the theme and a vanilla installation of WordPress. Wasn’t too crazy or labor intensive either. It was a few commands I had run and things were working. It was a good feeling knowing that I was able to get something up and running.

This was the next thing I wanted to tackle though. I saw a person ask a question of getting Bedrock and Sage running on Pantheon. The cool part here was that this was in line with the project I was asked to help out with. It was to help get a WordPress Composer Managed upstream up and running. The cool part here being that a lot of the work was pretty much done long ago. The key was trying to get Sage to deploy to the platform. This was the interesting part because it dealt with getting composer to run inside of the installed WordPress folders.

The neat thing being I was able to get things to run by using Composer script hooks. If you are a fan of WordPress actions and hooks, then you will feel pretty at home with those. They work in almost the same way WordPress action hooks work. Difference being is these will run when Composer is doing it’s thing.

For example, I wanted to run a composer install command after all the packages were downloaded. In this case we would use the post-install-cmd event to get our command to run. It would looke something like the following snippet:

{
    "scripts": {
        "post-install-cmd": "composer install"
    }
}

That’s great!

Sort of. The weird part here being that it will run at the root of the project. What we need it to do is run inside of a different folder that resides inside of the root. This was funny to me only because I had to do some digging and searching for how and believe it or not it was as simple as adding a flag. The final addition to the script was:

{
    "scripts": {
        "post-install-cmd": "composer install --working-dir=path\/to\/folder"
    }
}

You will notice that there are some escaping characters on there.

The cool part here being that you could add your own commands as well to better help your development should you really want. It’s neat, it’s fun. It was a good moment when I got it up and running though.

This was a small part and small dive into working with Composer and WordPress. There are so many other uses of it too and I would love to write more about this because I do feel like there is plenty of work to be done.