Modules

Vortex isn't a Drupal distribution. It ships no installation profile unless you ask the installer for a custom one. The only recipe it carries is the small recipes/page recipe, which creates the demo content model during provisioning.

What it does ship is up to 26 contributed modules, depending on your installer answers, each already wired into the environment-aware settings and the provisioning scripts. You add the rest after the initial setup is done.

This page is for developers working on a project built from Vortex. It explains how each shipped module is required, configured, and installed, and what the installer removes when you leave a module out. For what each module does, see Contributed modules. For the custom modules, see Module scaffold.

The installer can remove every module in this section except Search API, which stays required even without the Solr service. Its Modules question lists 19 of them. Deselecting one removes the following in a single pass:

• Its Composer requirement
• Its settings override
• Its provisioning steps
• Its Behat feature
• Its assertions in the settings tests
• Any other block the template marks for it, such as its variables in .env

Keep Drupal helpers when you keep the demo module: ys_demo declares it as a dependency and uses it in its deploy hooks, so ys_demo can't install without it.

The other 7 of the 26 modules aren't in the Modules question:

• ClamAV, Redis, and Search API Solr follow the Services question.
• Migrate Plus and Migrate Tools follow the Use a second database for migrations? question.
• Storybook follows the Storybook component library? question, which the installer asks only when you choose a custom theme.
• Search API follows no question and always stays.

The Modules and Services questions select every option by default, but the migration and Storybook questions default to No. A run with every default answer therefore removes Migrate Plus, Migrate Tools, and Storybook, and keeps the other 23 modules.

How modules are configured

The following table lists the mechanisms that bring a shipped module into a project:

Mechanism	Location	Effect
Composer requirement	require in composer.json	Makes the module available to the site. ➡️ See composer.json
Settings override	web/sites/default/includes/modules/settings.<module>.php	Applies configuration conditioned on the detected environment, reading values from environment variables. ➡️ See Settings
Config export exclusion	$settings['config_exclude_modules'] in a settings override	Keeps a module that never reaches production out of the exported configuration, so enabling it locally never dirties the config. ➡️ See Settings
Provisioning	scripts/provision-00-enable-demo-modules.sh	Stands up the demo site in the local, ci, dev, and stage environments. Applies the recipes/page content model, sets the site name, and replaces core's toolbar with core's navigation as the administration interface. Installs the contrib, service, and custom site modules (including core's media), and runs their deploy hooks. ➡️ See Provision
Development provisioning	scripts/provision-10-enable-dev-modules.sh	Installs the modules that never reach production (the development tools and the email rerouting safety net) in the same 4 environments, plus the Storybook module when Storybook is selected. ➡️ See Provision
Migration provisioning	scripts/provision-20-migration.sh	Installs the ys_migrate demo migration module, and with it Migrate Plus and Migrate Tools, in every environment except prod, unless DRUPAL_MIGRATION_SKIP is set to 1. Ships only with the migration feature. ➡️ See Migrations
Module dependency	ys_demo.info.yml	Installs Drupal helpers and Testmode as dependencies of the demo module. ➡️ See Demo module

A module can be required without being installed anywhere: the settings override is then ready for the day the project enables it. seckit is the only module shipped that way on purpose. Fast 404 is never installed either, because its handler runs straight from the settings file. Every other module on the Contributed modules page is installed by one of the preceding mechanisms, so selecting the module is enough to get it enabled.

Leaving out the demo module or the Solr service breaks that for 1 module each. Drupal helpers arrives only as a dependency of ys_demo, so a project without the demo module has it required but not installed. Search API stays required without Solr, but the line that installs it leaves with the service.

Check which modules are enabled

When provisioning runs its custom scripts in the local, ci, dev, and stage environments, the output includes the following lines:

• Installed contrib modules. and Installed custom site modules. from scripts/provision-00-enable-demo-modules.sh, plus 1 line per selected service, such as Installed Redis module.
• 1 line per development module from scripts/provision-10-enable-dev-modules.sh, such as Installed Devel module., except SDC Devel, which prints Installed Single Directory Component development tools.

In prod and any other environment type, the 2 scripts print Skipped demo modules operations in production environment. and Skipped installing development modules in production environment. instead.

To list the modules enabled on your local site, run the following command:

ahoy drush pm:list --type=module --status=enabled