`vip dev-env update` erases and replaces custom wp-content with demo content (regression since v3.10.0)

[michael-sumner]

Description

When running vip dev-env update ..., the command erases all existing custom /wp-content files and replaces them with the default demo application code. This is a regression introduced in version 3.10.0 that breaks existing development workflows.

We normally delete the /wp-content directory and replace it with our git clone of the VIP-go skeleton that houses the contents of the /wp-content files.

Running the vip dev-env update ... would delete our custom code within /wp-content and replace it with the demo code instead.

After we removed the /wp-content and then cloned our own /wp-content directory, we run the following to update the setup:

vip dev-env update --slug <slug> --mu-plugins ~/.local/share/vip/dev-environment/<slug>/wordpress/wp-content/mu-plugins --app-code ~/.local/share/vip/dev-environment/<slug>/wordpress/wp-content --media-redirect-domain example.com --cron

This then allows us to keep the /mu-plugins and /wp-content within the Xdebug context for debugging purposes.

But, when running vip dev-env update ... it deletes our cloned /wp-content directory.

Expected Behavior

• vip dev-env update should preserve existing wp-content customizations
• Only missing/new files should be added, existing custom files should remain unchanged
• This was the behavior in VIP CLI v3.9.6 and earlier

Actual Behavior

• All custom wp-content files are deleted
• Directory is completely replaced with demo/default WordPress content
• Any custom themes, plugins, uploads, and configurations are lost

Environment

• VIP CLI Version: 3.21.0 (issue persists from 3.10.0 onwards)
• Operating System: macOS
• Shell: zsh 5.9
• Docker/Lando: Using default Lando configuration

Steps to Reproduce

1. Create a VIP development environment with custom wp-content files
2. Add custom themes, plugins, or other wp-content customizations
3. Run vip dev-env update ... (see example command above)
4. Observe that all custom wp-content has been replaced with demo content

Root Cause Analysis

The possible issue may have been introduced in PR #2169 ("refactor(dev-env): merge dev-tools into wordpress") in version 3.10.0.

Change in assets/dev-env.lando.template.yml.ejs:

The wordpress-installer service entrypoint was changed from:

# v3.9.6 (working)
entrypoint: /usr/bin/rsync -a --chown=${LANDO_HOST_USER_ID}:${LANDO_HOST_GROUP_ID} /wp/ /shared/

to:

# v3.10.0+ (broken)
entrypoint: sh -c '/usr/bin/rsync -a --delete --chown=${LANDO_HOST_USER_ID}:${LANDO_HOST_GROUP_ID} /wp/ /shared/; /usr/bin/rsync -a --chown=${LANDO_HOST_USER_ID}:${LANDO_HOST_GROUP_ID} --delete /dev-tools-orig/ /dev-tools/'

The Problem: The addition of the --delete flag to rsync causes any files in the destination (/shared/, which maps to the local wp-content directory) that don't exist in the source (/wp/ from the WordPress container) to be deleted. This results in complete replacement rather than preservation of existing customizations.

Impact

• High: This is a breaking change that affects all users with custom wp-content
• Data Loss: Users lose their custom development work
• Workflow Disruption: Forces manual backup/restore processes
• Regression: Previously working functionality is now broken

Suggested Fix

1. Option A: Remove the --delete flag from the rsync command to restore the previous behavior
2. Option B: Add logic to detect and preserve existing /wp-content customizations
3. Option C: Make the sync behavior configurable via a flag (e.g., --preserve-content or --clean-install)

Workarounds

Temporary Workaround 1 - Downgrade:

npm install -g @automattic/[email protected]

Temporary Workaround 2 - Manual Backup/Restore:

# Before starting environment
cp -r ~/.local/share/vip/dev-environment/<slug>/wordpress/wp-content /tmp/wp-content-backup

# After environment starts
rsync -a /tmp/wp-content-backup/ ~/.local/share/vip/dev-environment/<slug>/wordpress/wp-content/

Related Information

• Changelog: https://github.com/Automattic/vip-cli/compare/3.9.6...3.10.0
• Related PR: #2169 - refactor(dev-env): merge dev-tools into wordpress
• Release: https://github.com/Automattic/vip-cli/releases/tag/3.10.0

Additional Context

This issue has persisted through multiple releases (3.10.0 through current 3.21.0), suggesting it may not have been widely reported or noticed. However, it significantly impacts developers who maintain custom wp-content in their VIP development environments.

The fix should be straightforward - either removing the --delete flag or implementing proper preservation logic for existing content.

[michael-sumner]

[!NOTE]
The --delete flags will reappear when running vip dev-env update

I was able to get this working temporarily by removing the --delete flags from the .lando.yml file. Run this command in the terminal: (if you have sed command installed, which is common in MacOS)

sed -i '' '/entrypoint:.*rsync.*\/shared.*\/dev-tools-orig/ s/ --delete//g' ~/.local/share/vip/dev-environment/<slug>/.lando.yml

(Make sure to change the <slug> above to your VIP app slug)

Now, when running the vip dev-env start then the custom /wp-content directory does not get replaced.

[michael-sumner]

Update: (VIP-CLI version 3.21.0) Disregard the workaround. I was able to use the following configurations:

1. Clone the VIP repo locally
2. Clone the vip-go-mu-plugins-built repo locally (note: use the the -built repo)

Proceed with the vip dev-env create --slug <slug>

And in here, use the "Custom" option with the path to the app-code locally:

How would you like to source application code

<Custom>
~/Documents/GitHub/<vip_repo>

And then run the following commands: (as they were not present in the create subcommand yet:

vip dev-env update --slug <slug> --mu-plugins ~/Documents/GitHub/vip-go-mu-plugins-built --media-redirect-domain <prod_domain> --cron

3. And when you run the --editor workspace it will get xdebug running properly: (you can select your own editor here if it exists)

vip dev-env start --slug <slug> --editor=cursor

[github-actions[bot]]

This issue has been marked stale because it has been open for 60 days with no activity. If there is no activity within 7 days, it will be closed.

This is an automation to keep issues manageable and actionable and is not a comment on the quality of this issue nor on the work done so far. Closed issues are still valuable to the project and are available to be searched.