Composer - production

trellis
1

In the Composer.json file can you specify a

“require-prod” or “require-staging” so that for example you would only deploy things like analytics/sitemaps/limit login etc to the production site and not the dev or staging ones, as an example of course.

2

There are a couple ways you could probably do this, although all of them feel a little hacky to me. Here are a couple (untested) possibilities I thought of:

  • Use Composer’s events in concert with the scripts section of composer.json to to fire internal stuff or just run CLI commands. You could:
    • Run an composer script that modifies your required packages on the fly during deployment based on the environment it detects
    • Run WP-CLI commands (either directly from PHP or on the CLI) to turn the plugins you want on or off based on the environment
  • Modify your Ansible roles to check the environment, and then run WP CLI commands to add/remove/activate/deactivate the plugins you want.

Philosophically, though, I’d be reluctant to do any of these things: IMO a big part of the advantage of the Trellis system is that you know you’re getting essentially the same environment for development, staging, and production. If you’re swapping plugins in different environments, you introducing some pretty big differences, which means more difficult debugging when things break.

3

Good point and I agree with your sentiment.

I had one case that was on my mind and its not necessarily something I would do but, for example if you had a sitemap plugin or something similar that managed to contact Google (other search engines are available) from your staging platform then you could have duplicate content issues with your production (live) site if that was running also.

I expect there are ways around this but I’m sure there could be issues with other plugins that contact the external services hence the reason for the question.

4

IMO it would really depend on your use cases. Usually I just manually activate plugins on production that I leave deactivated on staging/development, and as long as I’m not pushing DB updates to production they stay the way I want them.

Depending on the plugins you’re using, you could fork them ( or hook into them, if they make hooks/filters available) and kind of “turn off” the functionality that would be problematic. I’m thinking something like giving Google Analytics a fake code if you’re in staging environment. That’s a bit more work, but if you use the same plugins over and over it might work out.