This release is a mixed bag in the best sense. There is a new opt-in way to catch visual regressions before they reach production, a change in how the shipped tooling is delivered, accessibility checks that now come in the box, some quality-of-life improvements to everyday commands, a reliability fix for Lagoon-hosted projects, faster CI, and the usual runtime refresh. Here is what each of these means for a project built on Vortex.
Catch visual regressions before they reach production
You change a Twig template, the tests pass, the PR merges. Then someone notices the footer has shifted twenty pixels on every page, or a font swap quietly broke the spacing across the site. Functional tests do not catch this. They check behaviour, not how the page actually looks.
This release adds an opt-in visual regression workflow built on Diffy(Opens in a new tab/window). It compares a baseline environment against your deployed pull request environment and reports the visual differences back on the PR. The important part is that it only runs when you ask it to. The workflow is gated behind a PR label, so visual diffs do not slow down every push. You add the label when a change is worth a visual check, and skip it when it is not.
The shell tooling now ships as a versioned package
Vortex has always carried a set of shell scripts that do the unglamorous work: downloading databases, provisioning the site, deploying, sending notifications. Until now those lived in your project tree under scripts/vortex/. That meant the tooling was effectively frozen at whatever version you last copied in, and it cluttered the repository with framework code you were not meant to touch.
In this release that tooling moves into its own Composer package, drevops/vortex-tooling, and is resolved from vendor/drevops/vortex-tooling/src/. The tooling is now independently versioned, tested, and upgradable, and your project tree is cleaner for it.
For most projects there is nothing to do. The bundled .ahoy.yml, CI configuration, and deployment hooks are reconciled automatically when you update Vortex, and CI installs the package through ./scripts/vortex-tooling.sh. The one thing to check: if you have custom code that called a script directly by its old path, update the reference from scripts/vortex/<name>.sh to vendor/drevops/vortex-tooling/src/<name>.
Accessibility checks ship in the box
Accessibility is one of those things that is easy to agree on and easy to defer. There is rarely a moment where someone decides to skip it. It just never quite makes it onto the board.
This release ships a ready-to-run Behat accessibility feature with every new project, so the baseline check exists from day one instead of being a task you keep meaning to add. Run it with ahoy test-bdd, or scope to just that feature with ahoy test-bdd -- --tags=@accessibility. It will not replace a full audit, but it puts a check in place by default, which is usually the hard part. Alongside it, the Behat dependencies have moved to stable releases.
Commands that answer to the names you already use
If you work across several stacks, you carry muscle memory from all of them. You type ssh to get into a container, status to see what is running, rebuild when you want a clean slate. Then you switch to a Vortex project and have to remember the exact command names.
This release adds aliases to the common Ahoy commands so the names you already reach for just work:
| You can now type | Runs the same as |
|---|---|
ahoy ssh or ahoy shell | ahoy cli |
ahoy status, ahoy describe, ahoy ps | ahoy info |
ahoy rebuild | ahoy build |
ahoy destroy | ahoy down |
ahoy fetch-db, ahoy db-download, ahoy db-fetch | ahoy download-db |
Nothing to configure. The canonical commands still work exactly as before.
A note on custom provision scripts
One change does need your attention if you use it. Custom provision scripts used to live in scripts/custom/. They now live directly in scripts/, and scripts/custom is deprecated. Provisioning still automatically runs any script with a provision- prefix and a .sh extension.
If you have custom provision scripts, move them from scripts/custom/ into scripts/. If you would rather not move them yet, you can set VORTEX_PROVISION_SCRIPTS_DIR=./scripts/custom to keep the previous location. Either way, the behaviour is explicit and under your control.
Upgrading
If you are already running Vortex, this is a one-afternoon upgrade rather than a project. Most of it lands automatically when you update: the tooling package, the CI changes, the Lagoon default, the faster test split. The one thing to action by hand is moving custom provision scripts out of scripts/custom/ if you have any. The visual regression workflow is opt-in, so you can adopt it whenever you are ready.
Full details are in the GitHub release notes(Opens in a new tab/window), and the Vortex documentation(Opens in a new tab/window) covers the setup for everything above.