Deploying WordPress Plugins and Sites Built Using Composer

6 thoughts on “Deploying WordPress Plugins and Sites Built Using Composer”

  1. “Down with redundancy and bloat, folks.”

    No question that redundancy adds bloat and certain amounts of churn to update cycles. Sometimes its worth the trade-off to have more stability […or… could it be…stabuildity* YEEEAAAAAHHHH]. Increased dependencies adds more potential weak links in your chain.

    I’m curious what your take is on the NPM / Leftpad dust-up from earlier this year?

    * I just wanted to make a good CSI meme joke. Please dear god do not let this stupid word salad become a thing.

  2. Hey Josh,

    First off, I’ve got to say that I appreciate how clearly you express the benefits to using Composer, and outline a simple process for using it. Composer is indeed awesome, and you do a good job of selling it.

    A question: how do you develop in situations where your plugin is broken out into multiple Composer-managed dependencies, as Ingot is? Say I’m working on a module that’s part of a larger plugin. I’m doing my work in a branch within this module’s repo. If I want to try something out, is my only recourse to commit code in the module, push it, and then run `composer update` in the plugin’s directory? I know I could work out of the `vendor` directory, but obviously that’s not a good practice (no way to see the changes you’ve made, and the work has to be duplicated into the actual repo). I imagine I could use Composer in symlink mode, but that still seems to me like an odd solution.

    Is there a way to handle this well, or is it just a matter of making and accepting one of these compromises I’ve mentioned? Thanks!

    1. Hi Lucas!

      When I’m working on Ingot, or a plugin like that I do open the vendor directory in my IDE and edit the packages there. Since they are checked out as Git repos, I just Git add/commit/push right from inside of the package. I’m not sure if that’s good or bad practice, but it’s practical.

      1. That’s absolutely the right way how to do it. I was struggling with the same problems when I’ve started using Composer in my themes and plugins, but later on figured out that:
        1) If you don’t lock the dependency to a specific version (v1.2.3), but rather a branch (dev-master), composer will pull a .git dir with your dependency. If that’s not the case, you can always use –prefer-source flag.
        2) You can then commit freely directly from the vendor/// directory and push to the upstream. Only make sure that if you’re switching branches, keep the “dev-” in composer.json in sync with your changes.

        Composer is probably the best thing that happened to PHP in last 10 years (HHVM/PHP7 being right behind it).

        Hey Josh, one question. How do you do the deployments? One option is surely ssh to a server and run `composer install` again as suggested. But it can get very tedious, especially if you have to do it many times or you have a team of more people and not everyone has ssh access to the server. Do you use CI/CD? And if yes, how?

Leave a Reply

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