Add per-feature config flags so individual cwp-core behaviours can be disabled

[edwilde]

Summary

Add an enabled config flag to each behaviour cwp/cwp-core applies, all defaulting to true, so projects can turn off individual features without forking the module or overriding its YAML piecemeal.

Why

The module applies roughly twenty behaviours unconditionally, on the assumption that the consumer is a site hosted on CWP. The CWP platform was decommissioned in 2025 and those sites moved to Silverstripe Cloud or elsewhere, so that assumption no longer holds for anyone.

Some of what the module configures is now inert or wrong off-platform: the egress proxy, the syslog handler pointed at Graylog, and the oEmbed proxy all target infrastructure that is gone. The rest, including session timeout, lockout thresholds, NZISM password rules and the forced PBKDF2 encryptor, are policy choices a project may need to make differently, particularly where SSO or passwordless login is in play.

The module is still installed widely because it is a dependency of cwp/cwp, and removing it means working out which of its behaviours a site has come to rely on. Today the only ways to opt out are overriding individual values, winning a Before/After merge, or removing an extension in project YAML. All of them require tracking upstream config forever, and none of them says "this project does not want this feature".

Only three toggles exist today (egress_proxy_default_enabled, xss_protection_enabled, strict_transport_security), and they are inconsistent with each other and undocumented as a set.

Proposal

One boolean flag per feature, defaulting to true, with a single YAML file in the module listing them all so there is one place to see what can be turned off.

Where a class already exists, the flag goes on it with an early return:

private static bool $enabled = true;

public function process(HTTPRequest $request, callable $delegate)
{
    if (!$this->config()->get('enabled')) {
        return $delegate($request);
    }
    // existing logic
}

YAML-only features need a small class each to host the flag, so it sits next to the thing it controls. Disabling then reads:

CWP\Core\Control\InitialisationMiddleware:
  enabled: false

Compatibility

No breaking changes. Every flag defaults to true and can only ever disable a feature, never enable one that is currently off. A project that upgrades and changes nothing behaves exactly as it does today. Existing property names such as egress_proxy_default_enabled are kept and honoured, with enabled sitting above them.

Note

Worth flagging for review: this makes security-relevant defaults disableable, including forced SSL and password strength. That is deliberate, since projects can already bypass all of them less legibly, and a flag in a config diff is easier to audit. If some subset should stay mandatory, better to settle that before implementation.

Timing

Aimed at the next major, ideally alongside the stable CMS 6 release, so projects meet the new config surface while already reading upgrade notes. Documentation and per-flag tests are part of the work, not a follow-up.

Happy to raise a PR if the approach is agreed.

[emteknetnz]

This module is no longer commercially supported.

Happy to raise a PR

If you're happy to do the work, I recommend you simply fork the module and do the work there

[edwilde]

Thanks @emteknetnz, I have admin access here. I just want to check there are no big arguments against this.

[emteknetnz]

Oh right :-) No objection from me

[michalkleiner]

👍 from me, too