Copy `wordpress` folder from previous release so that we can allow for auto-updating WordPress

[sean-dunwoody]

The problem:

Our current deployment recipe doesn't allow for auto-udpating WordPress.

It installs WordPress on deploy, which can be problematic (e.g. if you commit and test work the previous day, then WordPress launch a major version change, and you deploy the day after, the deployment could break things).

Using a symlink for WordPress core would be good in some ways, although it would mean deployments aren't atomic, and in any case it seems to cause issues with WordPress that are difficult to resolve.

The solution:

We should modify the deployment recipe so that on deploy, it copies the wordpress directory from the previous deployment. This would keep deployments atomic, avoid the need for a symlink (or having WordPress core in version control), and allow us to enable WordPress core auto-updates on these sites.

Some things that still need considering with this approach:

1. We only want to allow auto-updates for minor WordPress core versions, and we want major version updates to be a manual process. @simonrjones has suggested we should keep the WordPress core version tracked in source control somehow (maybe in a config file?) and use that on deploy to trigger wp core download --version=x if the major version has changed. Another approach would be to add a parameter on deploy for --wp-core-version which we could use to trigger wp core download --version=x on deployment (although this would leave us with no record of the version updates in source control)
2. How does this work on the first deployment? We need some way of executing wp core download if no previous release exists

[simonrjones]

FYI - The current recipe does allow for auto updating core (it sets writable permission on the WP folder). The the risk of downloading a newer version than has been tested with is indeed a problem.

If we copy the wordpress folder from the previous release on deployment this should work fine. And I think this approach would be backward compatible with the current Wordpress deployer recipe. On a first time install ideally we'd be using the current version of WP.

If we do want to track the major version of wordpress in source control I think we have the following options:

1. Use Composer to manage WordPress and WP plugins, it has version constraints which should work. However, would this stop auto updates happening?
2. Store the major version (e.g. 6.8) in a config file and write a small script to help install this. E.g. WP CLI custom command since that would work locally and on deployment.

@ChrisButterworth has experience of using Composer with WP.