Vortex 1.36, released as Phase, is the release where several long-running threads landed together. Migrations became something you can rehearse, AI agents got a proper entry point into a project, browser-based JavaScript tests moved into the standard toolkit, and provisioning picked up a guard that catches a failure most teams only find in production. There are no breaking changes.
Migrations you can test before the migration weekend
Content migrations are usually the least rehearsed part of an upgrade. The code gets reviewed, the tests pass, and then the migration itself runs once, on the night, against the real database, with everyone watching. If it fails halfway, you are debugging in the worst possible conditions.
This release lets provisioning use a secondary database. You point Vortex at a dump of the site you are migrating from, and it imports that alongside the destination site, then runs your migration commands in a defined order.
The effect is that a migration becomes something you can run locally on a Tuesday, and something CI can run on every pull request. A migration that runs in CI is a migration you have already rehearsed, dozens of times, against a real dataset, before the night it matters.
A guard against config import undoing your database updates
Here is a failure quiet enough to reach production. A contributed module ships an update hook that changes configuration. Your deployment runs the database updates, the hook does its work, and then config import runs and puts the old configuration straight back. Nothing errors. The site is simply wrong in a way nobody notices for a week.
Vortex now compares configuration before and after the import during provisioning, and fails the provision when the difference suggests a database update has been reverted. You find out at deploy time, with a red build, which is the cheapest possible moment to find out.
AI agents get a map of the project
If your team uses AI assistants on a Drupal codebase, you have probably watched one confidently invent a command that does not exist, or reimplement something the template already provides.
Vortex now ships an AGENTS.md file. It tells an agent where the generic documentation lives, at vortextemplate.com/docs(Opens in a new tab/window), and where the project-specific documentation lives, in the project's own docs/ directory. That split is the useful part: your team documents only what is specific to your project, and the agent reads the shared documentation for everything common to every Vortex project.
The installer became agent-friendly at the same time. A --schema flag returns structured information about the available options and requirements, --validate checks a configuration before a run, and --agent-help describes the commands in a form an agent can work from. Together they make an unattended, non-interactive install something you can rely on.
Browser-based JavaScript tests in the box
Functional JavaScript tests drive a real browser against your site, which is the only way to test anything that depends on JavaScript actually executing. Setting them up has always been fiddly enough to postpone.
They now run through the Chrome container Vortex already provides for Behat, configured the same way. The full stack is covered by one toolkit: unit, kernel, functional, functional JavaScript, and behavioural tests.
More ways to get a database
Getting a realistic database into a development environment is solved differently at every organisation. This release adds 2 more routes.
- Amazon S3. Where production cannot be reached directly and a dump is dropped into a bucket instead, Vortex can download from there.
- A profile fallback. When no database exists yet, provisioning can install from a Drupal profile to create a seed database, later replaced by the real one. That solves the chicken-and-egg problem of standing up the very first environment.
Drush also gained its own PHP runtime configuration through a custom drush.ini, for the commands that need more memory or a longer execution limit than a web request does.
Smaller additions worth knowing about
- The
xmlsitemapmodule ships in the template, sositemap.xmlgeneration is there from the start. - Shield allows the ACME challenge endpoint through, so Let's Encrypt certificates can be issued on an environment that sits behind Shield.
- The coverage threshold appears in the CI job summary as well as the logs.
- Renovate now watches the root
package.json, so front-end dependencies used for module development stay current alongside the PHP and Docker ones.
Upgrading
There are no breaking changes, so the update is routine. 2 things are worth checking. Provisioning now uses direct Drush commands throughout, in place of the mixed approach that switched behaviour depending on whether configuration files were present. And some database variables were renamed from VORTEX_DB_<ACTION>_* to VORTEX_<ACTION>_DB_* for consistency, so check the names if you override those in CI or hosting configuration.
Migrations, S3 downloads and Functional JavaScript tests are all opt-in, so you can pick them up when they earn their place. 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 each.
