Scoping a Search-Configuration Fix Across Shared Code Stacks
A university's Site Factory hosts 520 sites across three code stacks: stack-main (380 sites), stack-research (110), and stack-events (30). Governance is centralized, but 12 department site-group administrators can create sites and edit content. A department asks to change a shared search module's configuration from 'index all content' to 'index only published content' because search results expose draft titles. The same module is used by all stacks. The platform team has one maintenance window per month and a change freeze in two weeks. The department wants the fix on its 40 sites only. Budget does not allow a new stack this quarter.
1. Where should the fix be implemented, and what is the blast radius if the team treats it as a global code change?
Read the worked answer
Reasoning: A module setting such as which content is indexed normally lives in each site's configuration/database, not in the shared codebase. A global default change in code or an install-profile default would affect every site on the stack that receives the deployment, not just the requesting department.
- Preferred path: update the setting on the 40 affected sites through a controlled per-site configuration change, using the Site Factory API or a Drush script, after validating on one test site.
- Blast radius: a code-level default on stack-main reaches 380 sites; on stack-research it reaches 110. That is far broader than the 40-site request.
- If the change truly requires new code, scope it behind a feature flag or a site-specific configuration override rather than changing the shared default.
- Take a database backup before the batch change and verify search results on a sample of affected sites.
2. Which governance controls should limit site-group administrators, and what should be escalated to the platform team?
Read the worked answer
Reasoning: Site-group administrators are useful for delegating site creation and content operations within a bounded group, but they should not be able to change platform-wide behavior.
- Keep code deployment, stack creation, module/theme updates, and factory-wide configuration under platform-team roles.
- Let site-group administrators manage sites and users only inside their assigned group, with audit logs enabled.
- Escalate any request that changes a shared module default, affects more than one site group, or requires a code deployment.
- Require a documented exception for changes during a freeze, including approver, rollback plan, and post-change review.
3. Given the freeze and budget, propose a sequenced plan that fixes the 40 sites without violating governance.
Read the worked answer
Reasoning: The exposure of draft titles is a privacy/content-integrity issue, but that does not justify bypassing the freeze for a broad code change.
- Confirm whether the setting can be changed per site. If yes, request a narrow emergency-change exception for configuration only, not code.
- Validate on one non-production copy of an affected site; confirm published-only results and no broken search facets.
- Apply to the 40 sites in batches through the API, logging each site and preserving a backup.
- Verify a sample of sites and monitor search logs for 24 hours.
- If code changes are unavoidable, defer to the next maintenance window and use a feature flag so only the 40 sites opt in.