v1.0.8

Registry readiness

Housekeeping release from the officialization gap-check against DDEV's published add-on requirements. No add-on behaviour changes.

Fixed

• README badges — added the three missing template badges:
  • Add-on registry
  • Last commit
  • Release
• install.yaml — minimum DDEV version raised to >= v1.24.10, per the upstream template
• tests.yml — updated to the current upstream shape:
  • paths-ignore for Markdown on both pull requests and pushes
  • Remote-debugging wording replaces the old tmate description
• PR template — the manual-testing line named the wrong add-on (ddev-tailscale-router); it now names ddev-sql-sync

Verified

The official DDEV add-on update checker now reports:

All checks passed, no actions needed.

v1.0.7

Highlights

• Dumps are now staged privately on the server and verified before import: the remote stages the dump in a dedicated ddev-dumps folder (mode 700, dump file mode 600) inside the alias's tmp, and on success writes a completion marker carrying the byte size. The host downloads the marker with the dump and checks the size before importing — a partial dump from a failed run is removed on the server and can never be imported as if it were whole.
• Sanitize can no longer fail quietly: if sanitize is on (the default) but nothing could be applied for the detected platform, the run ends with a prominent error and a non-zero exit after the import, instead of a success banner over live production data.

Fixed

• Default dump dir: ~/sql-sync — the built-in default and the shipped example's dir: — resolved to a literal ~/ folder inside the home directory. ~ and ~/ prefixes now expand properly.
• Alias parsing strips YAML inline comments from unquoted values on every key, including the database: block, so copying the README's example block no longer produces garbage ssh targets; quoted values keep their #.
• WordPress sanitize uses the site's actual table prefix — read from wp-config.php and passed through by the remote, or detected from the imported tables on --no-dump runs — instead of assuming wp_.
• WP-CLI is also probed in ~/bin, ~/.local/bin and /usr/local/bin before falling back to mysqldump, so an install outside the ssh session's minimal PATH is no longer missed.
• A gzipped dump (for example from a custom dump: command) is detected by its magic bytes and imported as .sql.gz. The remote copy is deleted only after a successful import; a failed import leaves it in place and prints where, with the --no-dump retry.
• A failed dump step stops the run immediately with a clear message, instead of the error scrolling past inside later rsync output.
• Duplicate alias definitions are a hard error naming the alias, instead of silently using the first one.
• The disk-space check is no longer silently absent: when the database size cannot be estimated — including the dump: strategy, which now estimates whenever credentials resolve from the alias or the platform — a normal run says the check was skipped.
• .env parsing accepts export -prefixed lines and strips inline comments from unquoted values; quoted values are untouched.
• The installed aliases.yml no longer describes itself as the example file.
• README: the "Testing safely" ladder describes --no-sync truthfully (the dump is created on the server; nothing is downloaded until a later --no-dump run), the Drupal sanitize precedence is documented as shipped (an alias sanitize: file wins over drush sql-sanitize), the dry-run section notes the one transient temp file in the Drupal credential path, and the quoted strategy messages match the real output.

v1.0.6

Breaking change

The @self target is now required.

Sync commands take a source and a destination — cp, rsync, scp, and Drush's sql-sync all do. The target was previously optional ("@self is implied"), which broke that convention.

• Before: ddev sql-sync @prod
• Now: ddev sql-sync @prod @self

@self remains the only accepted target — any other target is rejected as before, so the tool still never writes to a remote server. A missing target now fails with a clear message instead of proceeding.

All flag forms state the target too:

• ddev sql-sync @prod @self -y
• ddev sql-sync @prod @self --dry-run
• ddev sql-sync @prod @self --no-sync
• ddev sql-sync @prod @self --no-sanitize

Updated

• Command usage, help text, and examples
• README — Usage and Testing safely sections
• Install message
• Tests — every invocation uses the explicit form, plus a new case asserting that a missing target is rejected

v1.0.5

Highlights

• Adds --dry-run preflight mode
• Adds a disk-space guard for normal runs
• README gains a "Testing safely" section

--dry-run preflight

ddev sql-sync @prod @self --dry-run performs every check up to the dump — and nothing destructive:

• SSH connectivity (BatchMode, 10s timeout, through the jump host if configured)
• Platform and dump-strategy detection, probed exactly as a real run probes
• Credential resolution, reported as database name and username only — the password is never printed, and a fixture test asserts it never appears
• Resolved database size from information_schema
• Tmp-dir writability and free space
• mysqldump presence, when needed
• Local dump-dir check

Each check reports an ok / FAIL verdict, followed by the plan:

• Strategy, source, and size estimate
• Local landing path
• Whether sanitize would run, and which kind

It closes by stating that no dump was taken and nothing was written on the server.

By construction, the dump execution sits behind a single preflight gate in the remote script, and tests assert that in dry-run mode:

• No dump command runs
• No remote temp file is created
• Nothing is imported

Disk-space guard

Normal runs gain the matching guard: before dumping, the run aborts with a clear message if free space in the remote tmp dir is less than the estimated database size.

Documentation

README gains a Testing safely section: dry-run, then --no-sync, then a full run.

v1.0.4

Changed

Platform default: when no platform is given, the add-on now assumes the generic php platform instead of laravel.

This amends the v1.0.3 behaviour.

Resolution chain

1. The alias's platform: key, if set
2. The project's DDEV type — laravel / wordpress / drupal* map to themselves
3. php — for DDEV's generic php type, an unrecognised type, or no type at all

The php platform

• Always uses mysqldump — no app-native export
• Credentials come from the app's .env, merged under the alias's database: block
• Has no bundled sanitize — an alias sanitize: file is honoured; otherwise the run reports that no sanitize ran

The remote script's fallback for direct/manual use is likewise php, with the assumption notice printed as before.

v1.0.3

Fixed

The remote dump script silently assumed the laravel platform whenever SQL_SYNC_PLATFORM did not reach it, and never announced the platform it used.

Affected path

The mysqldump fallback for WordPress and Drupal aliases — where a missing platform value sent credential extraction to the app's .env logic against a WordPress/Drupal root, with no sign in the output.

The fix

• The remote script now echoes the platform it is using at the start of every run
• When no platform is specified, it prints a clear notice that laravel is assumed, instead of assuming it silently

Tests

Adds fixture tests that invoke the remote script exactly as the host command does over SSH — full SQL_SYNC_* environment, script fed to bash -s on stdin — for:

• WordPress
• Drupal
• The no-platform case

v1.0.2

Added

Optional per-alias jump host support.

• A jump: key in aliases.yml is passed to ssh -J (ProxyJump) for the dump, rsync, and cleanup connections

Note

~/.ssh/config ProxyJump remains the recommended, durable setup. The jump: key is a one-off convenience for cases where you don't want to edit your SSH config.

v1.0.1

Documentation

• Documentation and examples updated to use generic placeholders

v1.0.0

First release

Drush-style sql-sync for DDEV: sync a production MySQL database into a local DDEV project over SSH.

Features

• Drush-style invocation and aliases — alias YAML config in .ddev/sql-sync/aliases.yml, never overwritten
• Platform defaults from the project's DDEV type
• Dump via the app's own export (WP-CLI / Drush) or mysqldump, with credentials resolved from the app config:
  • .env
  • wp-config.php
  • settings.php
• Credentials are merged field-by-field with an optional explicit database: block in the alias
• Download over rsync
• Import via ddev import-db
• Sanitize on by default:
  • Bundled SQL for Laravel and WordPress
  • drush sql-sanitize for Drupal