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.

[FE] is a Drupal 6/7 mechanism — BOA never enables a module on Drupal 8+. [FD] reaches Drupal 8+ too, but for exactly one module and by a different route — see Drupal 8+ below.

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, mydropwizard, performance, security_review, site_audit, watchdog_live, xhprof (the D6 list differs slightly; both are catalogued below). 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.

mydropwizard sits in both D6 and D7 Tuesday lists because the service behind it no longer exists. Its only job is pulling Drupal 6 LTS update-status data from updates.mydropwizard.com, and myDropWizard closed in February 2022; the module's hook_cron() still issues a synchronous request to that host on every availability check, which now fails at the TLS handshake, so the call can never succeed. Octopus stopped supplying it in November 2022, so no BOA-built platform since then carries it, but copies remain in two places — older platforms built before that, and codebases customers maintain themselves. Both are treated the same way, per the rule above: switched off where enabled, files untouched wherever they sit. Both a 6.x and a 7.x branch shipped, so both lists carry it.

A _MODULES_FORCE blacklist (backup_migrate, coder, cookie_cache_bypass, hacked, mydropwizard, 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.

Enforcement acts on the module, never on its files. Both D6/D7 lists are applied with Drush against the site's own enabled-module list, so a module is matched and switched off by machine name wherever it physically lives — the shared o_contrib / o_contrib_seven bundle, sites/all/modules, a single site's modules directory, or a codebase you maintain yourself. Drupal's registry holds one entry per machine name, so duplicate copies on disk collapse to that one entry and a single disable covers them all. BOA never deletes, moves or edits a module directory to enforce this: a disabled module stays on disk exactly where you put it.

Drupal 8+: linkchecker only, enforced without Drush

BOA stopped touching Drupal 8+ modules with Drush8, which is what carries out these actions on D6/D7: a Drush8 full bootstrap against a Drupal 8+ site can corrupt the site's internals, so outside the controlled backend path BOA never runs Drush8 against a D8+ site. There is therefore no D8+ force-enable list at all, and the D8+ force-disable list (_MODULES_OFF_EIGHT_PLUS) holds exactly one module.

That module is linkchecker, [FD] on every core for the reason it always was on D6/D7: its LinkCheck queue worker probes external URLs synchronously inside web cron, holding an FPM worker until the FastCGI kill, and the killed run releases its queue items so the next cron repeats them — a permanent self-DoS on shared pools. Only the route differs, and it involves no Drush at all. The Tuesday pass reads the site database directly (root mysql, db name parsed from the site drushrc; on D8+ a module's table presence is an exact installed-signal, because uninstall drops the schema and no disabled state exists) and e-mails the operator on a hit, repeating weekly until the module is gone. BOA never contacts the site itself.

Removal stays with the operator, through the site's own admin UI in web context: Extend → Uninstall → the module. For linkchecker, core's uninstall page first offers the required Remove LinkChecker link type entities step; complete that, then uninstall. Do not run Drush8 commands against a Drupal 8+ site.

_MODULES_SKIP silences the D8+ report for a module exactly as it exempts one from the D6/D7 lists. The absent force-enable twin is deliberate: enabling modules behind a config-managed site's back creates config drift.

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, catalogued in full below. 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:

The auto-managed sets

The modules maintenance actually acts on, as they stand in owl.sh. When is Tuesday for the broad weekly list, or every pass except Tuesday for the small nightly one — on Tuesday the broad lists replace the nightly trio, they do not extend it. Dependency check is honoured when a module is spared because something else requires it, and bypassed for the _MODULES_FORCE members that go off regardless.

Force-disabled [FD]:

The force-enable table is D6/D7 only. In the force-disable table every row but linkchecker is D6/D7 too: linkchecker is the one module force-disabled on D8+ as well, where the dependency check does not apply because the removal runs through a different route (below).

Force-enabled [FE]:

The remaining two flags need no separate table: [SE] soft-enabled (admin, rubik) and [NA] not-applicable (cache_backport, redis) are marked in the bundled catalogue above, and neither is touched by maintenance.

The control-panel site is separate. On the hostmaster site itself, the nightly run disables update, syslog and dblog once per pass. That is not part of _MODULES_OFF_*, is not gated by _MODULES_FIX, and never reaches tenant sites.

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. For the runtime side from Drupal 8 upwards, see Drupal 8+: linkchecker only, enforced without Drush above.

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.