Drupal module support matrix

BOA ships a curated set of performance + utility contrib modules with every D6 + D7 platform, and a maintenance pass enforces enable/disable state for known-good and known-bad modules. This page documents the flag legend, where the enforcement lives, and the control variables that govern it. The per-module bundle itself is built into every platform's shared o_contrib / o_contrib_seven module trees at platform-build time. This is not limited to the platforms BOA builds for you — register your own custom platform under the ~/static directory tree and the same maintenance pass symlinks the shared o_contrib / o_contrib_seven bundle into it too, so you never wire these modules into a custom platform by hand.

The flag legend

Each module carries one or more flags:

A module can carry multiple flags. [D6] / [D7] indicate which Drupal version supports it.

Where the enable/disable decisions live

The module enforcement runs from the nightly maintenance pass (aegir/tools/system/night/20-sites.sh, driven by owl.sh). owl.sh computes the ISO weekday with _DOW=$(date +%u) (Mon=1…Sun=7) and builds two different enable/disable lists depending on the day:

• On Tuesday (_DOW=2) the broad force-disable lists apply — for D7 that is coder, devel, filefield_nginx_progress, hacked, l10n_update, linkchecker, performance, security_review, site_audit, watchdog_live, xhprof (D6 has a parallel list). The day-dependent force-enable list (robotstxt, plus path_alias_cache on D6) is empty on Tuesday.
• On every other day only a minimal list applies: enable robotstxt (plus path_alias_cache on D6), disable dblog, syslog, backup_migrate.

entitycache is a special case: it is force-enabled on every nightly pass (including Tuesday), gated only by _ENTITYCACHE_DONT_ENABLE, independently of the day-dependent enable list.

A _MODULES_FORCE blacklist (automated_cron, backup_migrate, coder, cookie_cache_bypass, hacked, poormanscron, security_review, site_audit, syslog, watchdog_live, xhprof) is not an independent always-on disable pass. It is consulted only inside the disable routine, applied to the day-gated OFF list above: for a module already in that day's OFF list, membership in _MODULES_FORCE forces the disable past the "Required by" dependency check (below). So a _MODULES_FORCE member is only acted on when the day's OFF list already contains it — e.g. on non-Tuesday the D7 OFF list is just dblog, syslog, backup_migrate, so the other members are not iterated that day.

Sites whose main name carries .dev., .devel., .temp., .tmp., .temporary., .test., or .testing. are skipped entirely by the maintenance pass.

Two host-level variables in /root/.barracuda.cnf govern the pass:

• _MODULES_FIX — set NO to disable the entire enforcement (default YES).
• _MODULES_SKIP — modules that should never be force-disabled (an operator-managed safelist).

The enforcement is dependency-aware: a module otherwise force-disabled is not disabled if it is required by an enabled feature or another module, avoiding cascade-disable failures.

Bundled, supported, and force-disabled sets

• Bundled [B] — performance and utility modules that ship in every D6/D7 platform; the full [B]-flagged set (catalogued below) is what BOA seeds into each platform's shared o_contrib / o_contrib_seven module tree.
• Supported but not bundled [S] without [B] — modules BOA has Nginx rewrites and config support for, but does not bundle; operators or tenants enable them via Composer or Drush (full list below). Some are [S] only when a specific XTRAS package is present — e.g. imageapi_optimize is [S] only when the IMG XTRAS image binaries are installed (see _XTRAS_LIST & install modes).
• Force-disabled [FD] — modules BOA actively disables for security or operational reasons (devel, coder, security_review, site_audit, hacked, xhprof, plus core dblog / syslog). To keep one enabled after auditing it, add it to _MODULES_SKIP.

The full flagged catalogue

Every entry in the first table is both [S] supported and [B] bundled — BOA seeds it into each platform's shared o_contrib (D6) / o_contrib_seven (D7) tree. The Notes column flags the two variants: [SE] soft-enabled (on at initial install but not forced afterwards) and [NA] not applicable (used without ever being enabled). Two further bundled modules, entitycache and robotstxt, carry [FE] and are covered with the force-enable rules above.

Supported but not bundled — [S] only. BOA ships the Nginx rewrites and config so these work without .htaccess, but you enable the module yourself via Composer or Drush:

Enforcement troubleshooting

• "BOA keeps disabling my module." It is in a force-disable list — that is expected. Add it to _MODULES_SKIP in /root/.barracuda.cnf if you have audited it and want it on.
• "BOA keeps re-enabling a module I disabled." It is in a force-enable list. To keep it off, set _MODULES_FIX=NO to disable the whole enforcement (less surgical but unambiguous; _MODULES_SKIP only protects against disable, not enable).
• "Modules I expect aren't installed." Either the module is [S] but not [B] (enable it manually), or the platform predates the bundled set including it (rebuild with octopus up-lts o1 platforms).

D10+ platforms

The bundled-set + force-enable/disable mechanism is D6/D7-era. Modern Drupal (10+) uses Composer-managed dependencies, so BOA's involvement is at the platform-build level — which modules end up in the new platform's composer.json — rather than runtime enforcement. For a D10+ platform, that platform's own composer.json / composer.lock is the authoritative module list.

Related

• barracuda.cnf — defines _MODULES_FIX / _MODULES_SKIP.
• _XTRAS_LIST & install modes — host packages some modules depend on (e.g. IMG).
• Reference appendix — consolidated variable index.
• Discontinued features — modules dropped from the bundled set.