wordmove-ng 6.0.0 → 6.0.2

data/docs/configuration.md

@@ -0,0 +1,345 @@
+---
+title: Configuration
+nav_order: 5
+---
+
+# Configuration
+{: .no_toc }
+
+`movefile.yml` describes your local install and every remote. It is a YAML file, evaluated as an ERB template first, so it can read environment variables.
+
+1. TOC
+{:toc}
+
+## File name and location
+
+wordmove-ng looks for `movefile.yml`, `movefile.yaml`, `movefile` or `Movefile` in the current directory and then in each parent up to the one containing `wp-config.php`. `-c other.yml` selects another file inside the project.
+
+{: .note }
+Indentation defines the structure. Two spaces per level, no tabs. `wordmove-ng doctor` validates the file against a schema and tells you what is wrong.
+
+## Complete example
+
+```yaml
+global:
+  maintenance_mode: false
+
+local:
+  vhost: http://site.test
+  wordpress_path: /home/john/sites/site
+  database:
+    name: site
+    user: root
+    password: root
+    host: 127.0.0.1
+    # port: 3306
+    # socket: /path/to/mysqld.sock
+
+staging:
+  vhost: https://staging.example.com
+  wordpress_path: /var/www/staging
+  database:
+    name: staging
+    user: staging
+    password: "<%= ENV['STAGING_DB_PASS'] %>"
+    host: localhost
+  ssh:
+    host: staging.example.com
+    user: deploy
+  exclude:
+    - ".git/"
+    - ".env"
+    - "node_modules/"
+    - "wp-config.php"
+    - "wp-content/*.sql.gz"
+
+production:
+  vhost: https://example.com
+  wordpress_path: /var/www/example
+  database:
+    name: example
+    user: example
+    password: "<%= ENV['PROD_DB_PASS'] %>"
+    host: localhost
+    # mysqldump_options: --max_allowed_packet=50MB
+    # mysql_options: --protocol=TCP
+  ssh:
+    host: example.com
+    user: deploy
+    # port: 22
+    # password: only with sshpass installed; prefer keys
+    # rsync_options: --verbose
+    # gateway:
+    #   host: bastion.example.com
+    #   user: jump
+  exclude:
+    - ".git/"
+    - ".env"
+    - "node_modules/"
+    - "wp-config.php"
+    - "wp-content/*.sql.gz"
+  forbid:
+    push:
+      db: true            # never push the database to production
+  hooks:
+    push:
+      after:
+        - command: wp cache flush
+          where: remote
+          raise: false
+```
+
+## First level keys
+
+`local` is mandatory and must keep that name. `global` is optional. Every other first level key is a remote environment, selected with `-e`. See [Multiple environments]({{ site.baseurl }}/environments/).
+
+## `global`
+
+| Key | Default | Meaning |
+| --- | --- | --- |
+| `maintenance_mode` | `false` | Wrap the target's database import and adaptation in `wp maintenance-mode activate`/`deactivate`. `WORDMOVE_MAINTENANCE_MODE=1` in the environment forces it on for one run. |
+| `collation_fallbacks` | built-in table | Collations rewritten before import, e.g. `utf8mb3_uca1400_ai_ci: utf8mb4_unicode_ci`. Setting the key replaces the default table. |
+| `charset_fallbacks` | `utf8mb3: utf8mb4` | Charsets rewritten before import. |
+| `sql_adapter` | ignored | Accepted with a warning for 5.x movefiles. |
+
+## `local` and each remote
+
+### `vhost`
+{: .no_toc }
+
+> mandatory
+
+The URL you use to reach the site, including any subdirectory WordPress is installed in. It should match `wp option get home`. Omit the trailing slash. `init` pre-fills it from `wp-config.php` or `wp option get home`.
+
+### `wordpress_path`
+{: .no_toc }
+
+> mandatory
+
+The absolute path of the installation. Spaces and other shell characters are handled; no manual escaping. On a remote it is the path **on that host**.
+
+{: .warning }
+Avoid values where one environment's `vhost` or `wordpress_path` is a prefix of another's (`https://site.test` and `https://site.test.example.com`): the search-replace of the shorter value would also rewrite the longer one. The doctor reports this.
+
+### `database`
+{: .no_toc }
+
+> mandatory keys: `name`, `user`, `password`, `host`
+
+| Key | Meaning |
+| --- | --- |
+| `name`, `user`, `password`, `host` | as in `wp-config.php`. For a remote, as seen **from the remote host**: wordmove-ng connects over SSH first and runs `mysqldump`/`mysql`/`wp` there. |
+| `port` | optional; `init` splits `DB_HOST` values like `localhost:3307`. |
+| `socket` | optional unix socket; `init` splits `DB_HOST` values like `localhost:/path/mysqld.sock`. |
+| `mysqldump_options` | passed verbatim to `mysqldump`/`mariadb-dump`, e.g. `--max_allowed_packet=50MB --ignore-table=db.wp_bigtable`. |
+| `mysql_options` | passed verbatim to `mysql`/`mariadb` on import, e.g. `--protocol=TCP`. |
+
+`mariadb`/`mariadb-dump` are preferred when installed, falling back to `mysql`/`mysqldump`. Imports run with `--binary-mode` (unless `mysql_options` already sets it), `SET FOREIGN_KEY_CHECKS=0` and a trailing `COMMIT;`; a MariaDB sandbox header is stripped.
+
+### `paths`
+{: .no_toc }
+
+> optional
+
+Customise WordPress internal paths when they are not the defaults, relative to `wordpress_path`. Configure it on every environment whose layout differs.
+
+```yaml
+paths:
+  wp_content: app
+  wp_config: config/wp-config.php
+  uploads: app/uploads
+  plugins: app/plugins
+  mu_plugins: app/mu-plugins
+  themes: app/themes
+  languages: app/languages
+```
+
+## Remote-only keys
+
+### `ssh`
+{: .no_toc }
+
+> mandatory key: `host`
+
+```yaml
+ssh:
+  host: host
+  user: user
+  port: 22                    # optional
+  password: secret            # optional; needs sshpass, prefer keys
+  rsync_options: "--verbose"  # optional, appended to rsync
+  gateway:                    # optional jump host, becomes `ssh -J`
+    host: bastion
+    user: jump
+    port: 22
+```
+
+Every operation uses the **system `ssh` client**: rsync for directories, `ssh` for remote commands and hooks, `scp` for dump files. Whatever works for `ssh` on your command line works here: ssh-agent, `~/.ssh/config`, `ProxyJump`, hardware keys, modern key types. Only `host` is mandatory because the rest can live in `~/.ssh/config`:
+
+```
+Host client_x_staging
+  Hostname 79.99.8.94
+  User welaika
+  Port 1337
+  ProxyJump bastion
+```
+
+```yaml
+staging:
+  ssh:
+    host: client_x_staging
+```
+
+- Without `password`, connections run with `BatchMode=yes`: a failing key authentication is an error naming the failed command, never a prompt.
+- `password` is passed through `sshpass -p` to `ssh`, `scp` and `rsync`. It requires `sshpass` locally and exposes the password in the process list.
+- `rsync_options` are appended to the defaults `-rlpt --compress --omit-dir-times --delete`. See [rsync options for CI]({{ site.baseurl }}/usage/#rsync-options-in-a-continuous-delivery-context).
+- `gateway` becomes `ssh -J [user@]host[:port]`. A `gateway.password` cannot be honoured and is ignored; the doctor warns.
+- Remote commands always run through `sh -c`, so the remote login shell can be bash, zsh, fish or csh. Programs only need to be in the `$PATH` of a non interactive login.
+
+### `exclude`
+{: .no_toc }
+
+> optional
+
+Patterns ignored during `push` and `pull`, which also means matching files are **not deleted** on the destination when missing at the source. Each entry becomes an rsync `--exclude`, relative to `wordpress_path`, so all rsync pattern syntax applies; see [working on specific plugins]({{ site.baseurl }}/usage/#work-only-on-specific-plugins-or-themes).
+
+```yaml
+exclude:
+  - ".git/"
+  - ".gitignore"
+  - ".env"
+  - "node_modules/"
+  - "tmp/*"
+  - "movefile.yml"
+  - "wp-config.php"
+  - "wp-content/*.sql.gz"
+```
+
+### `hooks`
+{: .no_toc }
+
+> optional
+
+Commands run before or after a push or pull, locally or on the remote. See [Hooks]({{ site.baseurl }}/hooks/).
+
+### `forbid`
+{: .no_toc }
+
+> optional
+
+Blocks actions by configuration; forbidden tasks ignore command line flags and are skipped with a warning. Values must be booleans.
+
+```yaml
+forbid:
+  push:
+    db: true
+    uploads: false
+    plugins: false
+    themes: false
+    languages: false
+    mu_plugins: false
+  pull:
+    db: false
+```
+
+### Removed: `ftp`
+{: .no_toc }
+
+FTP, FTPS and SFTP transports were removed in 6.0. A remote with an `ftp` block fails validation with a clear message. See [Upgrading]({{ site.baseurl }}/upgrading/#4-ftp-and-sftp-are-gone).
+
+## Environment variables and `.env`
+
+Because the movefile is an ERB template, secrets can come from the environment:
+
+```yaml
+production:
+  database:
+    user: "<%= ENV['PROD_DB_USER'] %>"
+    password: "<%= ENV['PROD_DB_PASS'] %>"
+```
+
+Set them in the shell (`export PROD_DB_PASS="…"`) or in a `.env` file next to the movefile:
+
+```bash
+PROD_DB_USER="username"
+PROD_DB_PASS="password"
+```
+
+`.env.<environment>` (for example `.env.production`) is loaded when that environment is selected with `-e`. Add `.env*` to `exclude` and to `.gitignore`.
+
+System variables work too: `wordpress_path: "<%= ENV['HOME'] %>/sites/example"`.
+
+## YAML and ERB tips
+
+### Anchors to avoid repetition
+{: .no_toc }
+
+```yaml
+global:
+  default: &default
+    vhost: "http://example.com"
+    wordpress_path: "/var/www/site"
+    database: &db
+      host: localhost
+      user: username
+      password: password
+      name: database
+    ssh: &ssh
+      host: server
+      user: foo
+
+staging:
+  <<: *default
+  vhost: http://staging.example.com
+  database:
+    <<: *db
+    name: db_staging
+  ssh:
+    <<: *ssh
+    user: foobar
+
+production:
+  <<: *default
+  vhost: https://www.example.com
+  database:
+    <<: *db
+    name: db_production
+```
+
+The `default` anchor lives under `global` because every other first level key is treated as an environment.
+
+### Variables inside the template
+{: .no_toc }
+
+```yaml
+production:
+  <% prod_wp_path = "/home/site/public" %>
+  vhost: "https://example.com"
+  wordpress_path: <%= prod_wp_path %>
+  hooks:
+    pull:
+      after:
+        - command: 'cd <%= prod_wp_path %> && wp core version'
+          where: remote
+```
+
+### Conditional sections
+{: .no_toc }
+
+```yaml
+  hooks:
+    pull:
+      after:
+        <% if ENV.fetch('NOTIFY', nil) %>
+        - command: 'bash ./scripts/notify.sh'
+          where: local
+        <% end %>
+        - command: 'wp cache flush'
+          where: remote
+```
+
+`ENV.fetch('NOTIFY', nil)` returns the variable or `nil`; you can also compare against values (`<% if ENV.fetch('TARGET', '') == 'blue' %>`).
+
+## Schema validation
+
+`wordmove-ng doctor` validates every section against the schemas in [`lib/wordmove/assets`](https://github.com/tekgnosis-net/wordmove-ng/tree/master/lib/wordmove/assets), reports unknown or mistyped keys, rejects `ftp` blocks and flags prefix collisions between search terms.

data/docs/contributing.md

@@ -0,0 +1,55 @@
+---
+title: Contributing and releasing
+nav_order: 12
+---
+
+# Contributing and releasing
+{: .no_toc }
+
+1. TOC
+{:toc}
+
+## Reporting a bug
+
+Run `wordmove-ng doctor` first and include its output. Then open an issue with the command you ran, the relevant part of `movefile.yml` with secrets removed, the full error output, and your OS, Ruby (`ruby --version`) and wordmove-ng (`wordmove-ng --version`) versions. Only the latest release is supported; bugs in the legacy `wordmove` 5.x gem belong to its own tracker.
+
+## Development
+
+```bash
+git clone https://github.com/tekgnosis-net/wordmove-ng.git
+cd wordmove-ng
+bundle install
+bundle exec rake                                 # specs + rubocop, what CI runs
+bundle exec rspec spec/deployer/ssh_db_spec.rb   # one file
+bin/wordmove-ng --help                           # run from the checkout, from any directory
+```
+
+CI runs the suite and rubocop on Ruby 3.0 through 4.0. Code must run on all of them. New rubocop offences are fixed rather than added to `.rubocop_todo.yml`, which only grandfathers the pre-6.0 backlog.
+
+Repository layout, request flow and conventions are described in [`CLAUDE.md`](https://github.com/tekgnosis-net/wordmove-ng/blob/master/CLAUDE.md).
+
+## Commit messages
+
+Write [Conventional Commits](https://www.conventionalcommits.org): `fix: …` (patch), `feat: …` (minor), `feat!: …` or a `BREAKING CHANGE:` footer (major), and `docs:`, `chore:`, `ci:`, `test:`, `refactor:` for everything that does not ship a change. The version number and `CHANGELOG.md` are generated from them; never edit `lib/wordmove/version.rb` or the changelog by hand.
+
+## Releasing
+
+Releases are automated by [release-please](https://github.com/googleapis/release-please) and published to [rubygems.org](https://rubygems.org/gems/wordmove-ng) with [trusted publishing](https://guides.rubygems.org/trusted-publishing/), so no API key is stored anywhere.
+
+1. Every push to `master` updates a "release PR" that bumps the version and the changelog from the commits since the last release. release-please proposes a patch release for any Conventional Commit, `ci:` and `docs:` included, so merge the PR only when there is something worth shipping.
+2. Merging it creates the `vX.Y.Z` tag and the GitHub release.
+3. The `publish` job in `.github/workflows/release.yml` re-runs the suite on the tagged commit, builds the gem, pushes it to rubygems.org and attaches the `.gem` file to the GitHub release.
+
+Pushing a `v*` tag by hand at the head of `master` triggers the same publish job.
+
+`master` is protected: changes land through pull requests whose `test` checks pass, and the rules apply to administrators too. release-please opens its PR with a fine-grained personal access token (secret `RELEASE_PLEASE_TOKEN`) because PRs opened with the built-in Actions token never trigger the checks.
+
+## This documentation
+
+The site is built from the `docs/` folder on `master` with Jekyll and the just-the-docs theme by `.github/workflows/pages.yml`. Preview locally with
+
+```bash
+cd docs && bundle install && bundle exec jekyll serve
+```
+
+Please keep it, and the README, updated when changing user-facing behaviour.

data/docs/database-sync.md

@@ -0,0 +1,91 @@
+---
+title: Database sync
+nav_order: 7
+---
+
+# Database sync
+{: .no_toc }
+
+1. TOC
+{:toc}
+
+## What happens on `-d`
+
+Both directions have the same shape. The **source** database is only ever read.
+
+| Step | `pull -e production -d` | `push -e production -d` |
+| --- | --- | --- |
+| 1. Prerequisites | probe local for `gzip`, `mysql`, `wp`; remote for `gzip`, `mysqldump` | probe local for `gzip`, `mysqldump`; remote for `gzip`, `mysql`, `wp` |
+| 2. Backup the target | local DB to `wp-content/local-backup-<ts>.sql.gz` | remote DB downloaded to `wp-content/production-backup-<ts>.sql.gz` |
+| 3. Dump the source | remote `mysqldump`, gzip, `scp` down | local `mysqldump`, normalise collations, gzip, `scp` up |
+| 4. Import on the target | `mysql` locally | `mysql` on the remote over SSH |
+| 5. Adapt on the target | `wp search-replace` locally for `vhost`, then `wordpress_path` | `wp search-replace` on the remote for `vhost`, then `wordpress_path` |
+| 6. Clean up | temp dumps removed | temp dumps removed |
+
+Step 1 aborts with a list of missing programs before anything else happens, so a misconfigured host never leaves a half-done sync.
+
+`wp search-replace` runs with `--all-tables --skip-columns=guid --allow-root`, so every table in the target database is adapted, including non-WordPress tables sharing it, and post GUIDs are left alone as WordPress recommends. wp-cli unserializes PHP data properly, so serialized options, widgets and page-builder data survive. `--no-adapt` skips step 5.
+
+## Backups and recovery
+
+Backups are gzipped SQL files in the local `wp-content/` folder, named after the target environment and a Unix timestamp. To restore one:
+
+```bash
+gunzip < wp-content/production-backup-1757400000.sql.gz | mysql -u user -p example      # on the remote
+gunzip < wp-content/local-backup-1757400000.sql.gz | mysql -u root -p site            # locally
+```
+
+If the remote `wp search-replace` fails after the import, the log names the backup file and the remote is left with the local URLs. Either restore, or re-run `wordmove-ng push -d`, or run the search-replace by hand on the remote:
+
+```bash
+wp search-replace 'http://site.test' 'https://example.com' --all-tables --skip-columns=guid --path=/var/www/example
+```
+
+Add `wp-content/*.sql.gz` to `exclude` so backups are never synced.
+
+## Maintenance mode
+
+```yaml
+global:
+  maintenance_mode: true
+```
+
+wraps steps 4 and 5 on the target in `wp maintenance-mode activate` and `deactivate`, so visitors see the WordPress maintenance page rather than a site pointing at the other environment's URLs for a few seconds. Deactivation runs even when the adaptation fails. `WORDMOVE_MAINTENANCE_MODE=1` forces it on for a single run. Default: off.
+
+## MariaDB and MySQL compatibility
+
+- `mariadb` and `mariadb-dump` are preferred when present, falling back to `mysql` and `mysqldump`, on each side independently.
+- Dumps starting with the MariaDB sandbox header `/*!999999- enable the sandbox mode */` import cleanly on servers that do not understand it.
+- Imports run with `--binary-mode`, `SET FOREIGN_KEY_CHECKS=0` and a trailing `COMMIT;`, unless `mysql_options` already sets binary mode.
+- `database.socket` and `database.port` are first-class; `--socket` inside `mysql_options` or `mysqldump_options` still works.
+- Newer `utf8mb3` collations (`utf8mb3_uca1400_*`, `utf8mb3_unicode_520_ci`) are rewritten to `utf8mb4_unicode_ci`, and `utf8mb3` to `utf8mb4`, before import. Override or extend the mappings:
+
+```yaml
+global:
+  collation_fallbacks:
+    utf8mb3_uca1400_ai_ci: utf8mb4_unicode_ci
+  charset_fallbacks:
+    utf8mb3: utf8mb4
+```
+
+- `wp` is always called with `--allow-root`, so root-owned Docker installs work.
+
+## Large databases
+
+Pass options straight to the dump and import tools:
+
+```yaml
+database:
+  mysqldump_options: "--max_allowed_packet=1G --single-transaction --quick --ignore-table=example.wp_actionscheduler_logs"
+  mysql_options: "--max_allowed_packet=1G"
+```
+
+`--hex-blob` in `mysqldump_options` makes binary columns safe to move between servers with different defaults.
+
+## Table prefixes
+
+Local and remote must use the same table prefix. `wp search-replace --all-tables` rewrites values, not table names.
+
+## Prefix collisions
+
+If one of the four search terms (local and remote `vhost` and `wordpress_path`) is a prefix of another, for example `https://site.test` and `https://site.test.example.com`, the replacement of the shorter value also rewrites the longer one. The doctor reports this as an error and the database step warns before running. Use distinct values.

data/docs/environments.md

@@ -0,0 +1,65 @@
+---
+title: Multiple environments
+nav_order: 9
+---
+
+# Multiple environments
+
+`local` is always your development environment and must keep that name. Every other first level key of `movefile.yml`, at the same indentation level, declares a remote. Here two remotes, `test` and `live`:
+
+```yaml
+local:
+  vhost: "http://site.test"
+  wordpress_path: "/Users/me/Sites/site"
+  database:
+    ...
+
+test:
+  vhost: "https://test.site.net"
+  wordpress_path: "/srv/test/www"
+  database:
+    ...
+  ssh:
+    ...
+
+live:
+  vhost: "https://site.net"
+  wordpress_path: "/srv/live/www"
+  database:
+    ...
+  ssh:
+    ...
+```
+
+Pick the remote with `-e`. With a single remote it is used by default and `-e` can be omitted; with several, omitting it is an error.
+
+- `pull` always lands in `local`; `-e` names where the data comes from: `wordmove-ng pull -t -e live` copies themes from `live` to `local`.
+- `push` always starts from `local`; `-e` names the destination: `wordmove-ng push -t -e test` copies themes from `local` to `test`.
+
+You cannot sync two remotes directly; go through `local`.
+
+## Backups per environment
+
+Before a database import the target's database is saved locally, named after the target: `wp-content/local-backup-<timestamp>.sql.gz` on a pull, `wp-content/live-backup-<timestamp>.sql.gz` or `wp-content/test-backup-<timestamp>.sql.gz` on a push.
+
+## Protecting an environment
+
+Use `forbid` to make some operations impossible on a given remote regardless of flags, typically the production database:
+
+```yaml
+live:
+  forbid:
+    push:
+      db: true
+      uploads: true
+```
+
+## Sharing configuration between remotes
+
+Use YAML anchors under `global` to avoid repeating blocks; see [Configuration]({{ site.baseurl }}/configuration/#yaml-and-erb-tips).
+
+## Distinct values
+
+Keep each environment's `vhost` and `wordpress_path` distinct and never a prefix of another's (`https://site.net` versus `https://site.net.staging`), otherwise the search-replace of the shorter value rewrites the longer one. `wordmove-ng doctor` reports such collisions.
+
+Thanks to **@charmcat**, who shared her troubleshooting with the original authors and suggested this page.

data/docs/hooks.md

@@ -0,0 +1,103 @@
+---
+title: Hooks
+nav_order: 8
+---
+
+# Hooks
+{: .no_toc }
+
+Hooks run arbitrary commands before or after a `push` or `pull`, locally or on the remote.
+
+1. TOC
+{:toc}
+
+## Syntax
+
+```yaml
+production:
+  hooks:
+    push:
+      before:
+        - command: 'echo "do something"'
+          where: local
+          raise: false        # raise is true by default
+      after:
+        - command: 'echo "do something"'
+          where: remote
+    pull:
+      before:
+        - command: 'echo "do something"'
+          where: local
+      after:
+        - command: 'echo "do something"'
+          where: remote
+```
+
+- `hooks` is optional and is configured per remote environment, never under `local`.
+- Two groups, `push` and `pull`, each with `before` and `after`, each a sequence of command objects.
+- `command`: the command to run. Quote it, preferably with single quotes, since double quotes are often used inside commands.
+- `where`: `local` or `remote`. `remote` is always the environment given with `-e`, or the only remote when there is one.
+- `raise`: default `true`. With `false`, a failing command (exit status > 0) is logged and the operation continues.
+
+Hooks run regardless of which components you selected: `push --all` and `push -t` trigger the same hooks. `wordmove-ng doctor` validates them.
+
+## Execution
+
+- Both local and remote hooks run inside the respective `wordpress_path`. Change directory inside the command if needed: `cd tools && ./build.sh`.
+- Hooks run in order, synchronously. What you read is what you get.
+- Remote hooks use the same `ssh` settings as everything else (host, user, port, password, gateway) through the system `ssh` binary, and run inside `sh -c`, so the remote login shell does not matter. Programs must be in the `$PATH` of a non interactive login; if `wp` is not found, add its directory to `PATH` in `~/.bashrc` or `~/.profile` on the remote, or use an absolute path.
+- Hook output is logged with movefile secrets masked as `[secret]`.
+
+## Error handling
+
+```yaml
+hooks:
+  push:
+    before:
+      - command: 'exit 1'
+        where: remote
+        raise: false
+      - command: 'echo "Still working"'
+        where: local
+```
+
+The first command fails, the second still runs, and since these are before-push hooks the push happens too. The error is visible in the log. Without `raise: false` the failure stops everything.
+
+## Examples
+
+```yaml
+hooks:
+  push:
+    before:
+      - command: 'npm run build'                       # build assets before pushing
+        where: local
+      - command: 'rm -rf ./tmp/*'
+        where: local
+    after:
+      - command: 'wp rewrite flush'
+        where: remote
+      - command: 'wp cache flush'
+        where: remote
+      - command: 'wp option set blog_public 0'         # keep staging out of search engines
+        where: remote
+      - command: 'find . -type f -exec chmod 664 {} +'  # fix permissions
+        where: remote
+      - command: 'find . -type d -exec chmod 755 {} +'
+        where: remote
+      - command: 'bash ./scripts/notify.sh'            # tell the team
+        where: local
+        raise: false
+  pull:
+    after:
+      - command: 'wp option update siteurl http://site.test'
+        where: local
+      - command: 'wp plugin deactivate wordfence'       # no security plugin locally
+        where: local
+        raise: false
+```
+
+Maintenance mode around the database replacement is built in (`global.maintenance_mode`), so hooks are not needed for that.
+
+## ERB inside hooks
+
+Because the movefile is an ERB template, hooks can be conditional or share variables with the rest of the file. See [Configuration]({{ site.baseurl }}/configuration/#yaml-and-erb-tips).