From df294d85426395dc94105e5ff8ed8494b0a6563f Mon Sep 17 00:00:00 2001 From: dougjq <68131341+dougjq@users.noreply.github.com> Date: Thu, 5 Dec 2024 15:15:27 -0500 Subject: [PATCH] Reference gotcha with deployment featuring changes to .gitignore We recently had a bad deploy and this comment is to remind us and others about the complexity of WordPress plugins in roots and interactions with .gitignore. If the plugin is composer managed, it's best to specify that in .gitignore because basically composer in roots wants to install that in web/app/plugins, which is source controlled. We don't want to see that plugin in our local working copies. But then we decided to move the advanced custom fields plugin from composer, where because of recent events it was not working like before, into directly managed source. And what we found recently was the first trellis deploy didn't come with the advanced custom fields source. We don't know why; maybe it's a trellis bug. Even if so, I don't think it would need to be fixed. Just tell people to deploy twice, problem solved. It repeatably failed for us the first time and worked for us the second deploy. --- trellis/deployments.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/trellis/deployments.md b/trellis/deployments.md index 98097ab8..927c71ab 100644 --- a/trellis/deployments.md +++ b/trellis/deployments.md @@ -51,6 +51,9 @@ trellis deploy It's normal and expected to see the WordPress install screen the first time you deploy. It's up to you to either import an existing database or install a fresh site. ::: +If deploying changes to an existing project's .gitignore, it may be necessary to deploy _twice in a row_ for previously ignored files to be deployed as expected. You may see this if you previously managed one plugin via composer, such that you issued a .gitignore directive for it, and then later switch that plugin from composer-managed to directly source controlled. + + ## Rollbacks Run the following from any directory within your project: