Summary
The installer offers generated_content as an installable module but ships no provisioning wiring for it, so three downstream Vortex sites each wrote a near-identical script to drive it.
Details
The shape all three converged on:
- Run only in non-production environments.
- Run only when
VORTEX_PROVISION_OVERRIDE_DB is set, so re-provisioning against a real database never injects generated content on top of existing content; otherwise report that existing content is being kept.
- Offer an explicit skip flag for a fast provision.
- Raise the PHP memory limit for the generation run, which is heavier than the rest of provisioning.
The VORTEX_PROVISION_OVERRIDE_DB guard is the part worth keeping - it is what stops the script doing damage on a site provisioned from a real dump.
Points to settle:
- Whether this belongs as a step inside the existing
scripts/provision-00-enable-demo-modules.sh or as its own numbered script.
- It has to be fenced on the
generated_content module selection so it is absent when the module is not chosen.
- The generating module's machine name differs per site, so the template's version needs it from the installer token rather than hardcoded.
Summary
The installer offers
generated_contentas an installable module but ships no provisioning wiring for it, so three downstream Vortex sites each wrote a near-identical script to drive it.Details
The shape all three converged on:
VORTEX_PROVISION_OVERRIDE_DBis set, so re-provisioning against a real database never injects generated content on top of existing content; otherwise report that existing content is being kept.The
VORTEX_PROVISION_OVERRIDE_DBguard is the part worth keeping - it is what stops the script doing damage on a site provisioned from a real dump.Points to settle:
scripts/provision-00-enable-demo-modules.shor as its own numbered script.generated_contentmodule selection so it is absent when the module is not chosen.