Modules BOA manages

On a Drupal 7 or Drupal 6 site, BOA takes an interest in a small number of your modules. As part of its regular maintenance it checks a short list and quietly makes sure a few performance modules are turned on, and a few risky ones stay off. It does this for good reasons — speed and safety — and for most sites you'll never notice it happening.

You only really meet this behaviour in one situation: you enable a module and later find it switched off again (or you disable one and it comes back). This page explains which modules BOA touches, why, and what your options are when its choice and yours disagree.

This only applies to Drupal 6 and 7 sites. On Drupal 10 and newer, your modules come from Composer and BOA does not enable or disable anything at runtime — what's in your codebase is what runs. If you're on modern Drupal, you can skip this page.

What BOA does, in plain terms

During maintenance, for each of your D6/D7 sites, BOA looks at a curated list of modules and does three things:

• Turns a few on if you've turned them off — these are modules BOA considers essential to how it runs your site fast (its caching and object-cache helpers, for example).
• Turns a few off if you've turned them on — these are modules that are known to slow a site down, leak information, or clash with the way BOA is set up.
• Leaves everything else alone. The vast majority of your modules are entirely your business. BOA never touches a module that isn't on its list.

It's deliberately gentle. If a module BOA would normally disable is required by another module you're using, BOA notices the dependency and leaves it enabled — so it won't break a feature just to enforce a rule.

Two things run on different rhythms, which is worth knowing so a change doesn't surprise you:

• A small essential set is enforced nightly. BOA re-enables its core object cache and its generated robots.txt helper, and switches off a couple of the riskiest modules (its live database/system logging and a backup module it supersedes), on every nightly maintenance pass.
• The broader clean-up of developer and debugging modules runs weekly. The longer list — things like the devel family and other diagnostics tools — is swept on a weekly cycle, not every night. So if you enable one of those, it may stay on for several days before a weekly pass switches it off again. It isn't instant, and that's normal.

Which modules are on the list

BOA groups the modules it cares about into a few categories. You don't need to memorise these — the point is just to recognise the shape of the list.

The modules in the force-disabled group are ones you'd rarely want on a production site anyway — developer and debugging tools like the devel family, alternative logging and cron modules, extra caching layers BOA already handles a different way, and code-audit tools. If one of these gets switched off again after you enabled it, that's BOA working as designed, not a fault.

The full, current list — every module, which group it's in, and which Drupal version it applies to — is published by your host. If you want to know exactly how a specific module is treated, that support matrix is the authoritative answer, so ask your host for it or check where they publish it. The list changes over time as modules come and go, which is why it's kept in one place rather than copied here.

"BOA keeps disabling my module"

This is the common one. You enable something, and a maintenance pass later it's off again. Work through these in order:

1. Is it on the force-disabled list? Check the support matrix your host publishes. If your module is in the force-disabled group, BOA is doing exactly what it's meant to — usually because that module is a performance or security risk on a live BOA site. This is the answer most of the time.

2. Do you genuinely need it on anyway? Then this is a policy decision, and the policy lives on the server, not in your account. You can't override the force-disable yourself from your own files. Open a support request, tell your host which module you need and why, and they can add it to the server-side exception list so BOA stops disabling it. That's a one-line change for them.

3. Is it required by something else you use? If the module is a dependency of another enabled module, BOA won't actually disable it — so if it is disappearing, it's genuinely on the force-disabled list and step 2 applies.

"BOA keeps re-enabling a module I turned off"

The mirror image. A module you switched off keeps coming back on. Same logic: it's on BOA's force-enabled list because BOA relies on it. For most of these there's nothing to do — leaving them on is what keeps your site fast.

There is one force-enabled module you can opt out of from your own files: BOA's Entity Cache helper. If you have a specific reason not to run it on a platform, you can tell BOA to stop turning it on by adding one line to that platform's own control file (boa_platform_control.ini, in sites/all/modules/ inside your platform):

; ## INI (platform level) located in sites/all/modules/

entitycache_dont_enable = TRUE

Save the file, and from the next nightly pass BOA leaves Entity Cache alone on that platform. (This is a platform-level setting — it applies to every site on that platform, and there's no per-site version.) For how these control files work in general — where they live, the copy-and-uncomment routine, how long changes take to apply — see Platform & site INI files.

For any other force-enabled module, there's no tenant-side opt-out. If you have a real need to keep one off, that's again a support request — describe the case and your host can adjust the policy on the server side.

A scratch site that BOA leaves alone

One handy detail: BOA skips module enforcement entirely for sites whose domain marks them as non-production. If your site's address contains one of these markers as a dotted segment —

.dev., .devel., .test., .testing., .temp., .tmp., or .temporary.

— for example myproject.dev.example.com, then BOA won't force-enable or force-disable anything there. That makes such a domain a natural place to try a module BOA would otherwise disable, without fighting the nightly pass. It's the supported way to get an unmanaged site: name it as a dev/test site rather than asking for the enforcement to be turned off.

What's not yours to change

The overall policy — the master on/off lists, whether the nightly enforcement runs at all, and the server-side exception list — lives in your host's own configuration on the server. You can't reach or edit that, and you don't need to: everything you can do from your own account is on this page.

• Your side: the entitycache_dont_enable opt-out above, using a dev/test domain for a scratch site, and asking your host to make an exception.
• Your host's side: the module lists themselves and the global switch that turns enforcement on or off.

So whenever the fix would mean changing the policy rather than your own files, the step is simply: open a support request. It's a small change for your host and it's the right place for it to live.

Related

• Platform & site INI files — how the control files work, where each one lives, and how to edit them safely.
• Which file do I edit? — a quick guide to which settings belong in the site file versus the platform file.
• Working with platforms — how BOA's platforms hold your sites, which is where these modules actually live.
• Reference — every control-file setting name (including entitycache_dont_enable) collected for quick lookup.
• Discontinued — modules BOA used to manage and no longer ships.