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.

The flag legend

Each module carries one or more flags:

Flag Meaning
[S] Supported — BOA-side Nginx rewrites + config are in place so this module works without .htaccess.
[B] Bundled — ships with the BOA platform automatically.
[FE] Force-Enabled — maintenance enables it if disabled.
[SE] Soft-Enabled — enabled on initial install but not forced by maintenance.
[FD] Force-Disabled — maintenance disables it if enabled.
[NA] Not applicable — used without needing to be enabled.

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 (adminer, advagg, boost, cdn, httprl, login_security, fpa, and many more) — the full [B]-flagged set is what BOA seeds into each platform's shared o_contrib 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 (ais, ckeditor, imagecache, responsive_images, …). 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.

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