.gitignore & Deployment Best Practices Question

Hello all,

I’m getting back into doing some freelance WordPress stuff – and with a decent SysAdmin/DevOps background I only found it natural to start off with a proper stack. Trellis was the obvious answer. It was a breeze to get going - kudos to the team.

Context/background:

  • Development (Base install + Bricks and a few plugins)
  • Staging (Remote Linode Deployment)

I have the end-to-end provision and deploy process working.

I have noticed my generated .gitignore file includes:

# Application
web/app/plugins/*
!web/app/plugins/.gitkeep
web/app/mu-plugins/*/
web/app/themes/twentytwentyfour/
web/app/upgrade
web/app/uploads/*
!web/app/uploads/.gitkeep
web/app/cache/*

# WordPress
web/wp
web/.htaccess

# Logs
*.log

# Dotenv
.env
.env.*
!.env.example

# Composer
/vendor

# WP-CLI
wp-cli.local.yml

My rather generic/ignorant question (apologies if already answered somewhere);

I have noticed that during deployment that the plugins folder is ignored.

Is it best practice to kick-off additional after-deploy hooks that handle composer based plugin installation? What about plugin activation – is it typical to automate that via some WP-CLI scripts after-deployment as-well?

Trying my best to stick to the intended principles and not stray off that path early on.

With Bedrock, the intention is that you handle all dependencies via composer, including plugins and WordPress core itself. Since composer handles installation of dependencies, you don’t need to include dependency files in your repo.

During your deployment process, a composer install (with some add’l flags) is essentially all that’s needed to install WordPress and plugin files. Trellis does this for you here:

Here’s a bit more on how composer and Bedrock work together:

https://roots.io/bedrock/docs/composer/

Here’s a helpful article on how to do that with premium plugins, which requires a bit more initial setup and configuration:

https://roots.io/bedrock/docs/private-or-commercial-wordpress-plugins-as-composer-dependencies/

When using an existing WordPress database with your site, there shouldn’t be a need to reactivate plugins after a Trellis deploy as they’ve already been activated previously. If you wanted to ensure a plugin is active at deploy, then yes, using a wp-cli command in a deploy hook is the way to go. Which deploy hook you use is up to you.

https://roots.io/trellis/docs/deployments/

Good luck out there!

2 Likes

Thank you – this is exactly what I was looking for.

1 Like