Keep the modules, base recipes and configuration removed from the site templates in the profile

Problem/Motivation

A Drupal CMS site template has to resolve on Composer's default minimum-stability: stable. Several packages required through the Varbase chain have no stable release, so they are being taken out of the site templates and the base recipes.

Already removed:

• drupal/entity_clone, from Varbase Admin Base #3621449, Varbase Content Base #3621450 and Varbase SEO Base #3621451
• the four base recipes varbase_ai_base, varbase_api_base, varbase_auth_base and varbase_i18n_base, from Varbase Starter #3621334, Educare #3621335, Horizon Aid #3621336 and RightUp #3621337. They were required but never applied, and they carried packages with no stable release. They moved to drupal/varbase_project in #3621338.

Still to be removed, the remaining blockers measured with a clean-room composer require at default stable stability:

• drupal/ultimate_cron ~2, through Varbase Performance Base. Stable release requested in #2660208.
• drupal/rabbit_hole ~2, through Varbase Content Base. Requested in #3621376.
• drupal/advanced_text_formatter ~3, through Varbase Content Base. Requested in #3621362.

An existing Varbase site has all of these already. Once nothing in the chain requires them, a later composer update removes the code from under modules that are still enabled.

The profile is the right place to keep the requirements. It is consumed only through drupal/varbase_project, whose root sets minimum-stability: dev with prefer-stable: true. The site templates deliberately do not require the profile, so adding these here cannot put the blocker back into a template.

Requiring them here ahead of the remaining recipe removals means there is no window in which a Varbase Project site loses them.

Steps to reproduce

1. On an existing Varbase site, these modules and recipes are present.
2. As the site template and base recipe changes are released, nothing in that chain requires them.
3. A composer update removes the code while the modules stay enabled.

Proposed resolution

Require these eight in the profile's composer.json, at the constraints they carry in drupal/varbase_project and in the recipes they came from:

"drupal/advanced_text_formatter": "~3",
"drupal/entity_clone": "~2",
"drupal/rabbit_hole": "~2",
"drupal/ultimate_cron": "~2",
"drupal/varbase_ai_base": "1.0.x-dev",
"drupal/varbase_api_base": "1.0.x-dev",
"drupal/varbase_auth_base": "1.0.x-dev",
"drupal/varbase_i18n_base": "1.0.x-dev"

drupal/varbase_starter stays as it is.

composer.json only. Do not add anything to an install: list and do not enable or apply anything from the profile. An existing site already has what it needs enabled; a new site decides for itself.

drupal/canvas_override is deliberately not included. It is the fifth remaining blocker, it is Vardot-maintained, and it is being handled separately.

The Entity Clone configuration that Varbase SEO Base used to import is not carried over. If a site needs that configuration, it belongs in a follow-up.

Proposed resolution, part two: the configuration

Keeping the packages is not the whole job. Removing Ultimate Cron from Varbase Performance Base #3621493 and Varbase Search Base #3621494 also deleted seventeen ultimate_cron.job.* config files, because a recipe imports everything in its config/ directory and those imports fail once the module is gone. Nothing else ships them now, so the tuned schedules, lock timeouts and log retention would be lost.

Add the seventeen deleted files to the profile's config/optional/, byte-identical to what was removed: sixteen from Varbase Performance Base (captcha, content_lock_timeout, field, file, honeypot, layout_builder, node, password_policy, persistent_login, redirect_404, scheduler, simple_sitemap, system, ultimate_cron, update, webform) and one from Varbase Search Base (search_api).

config/optional, not config/install. Install config is created unconditionally and would fail, since Ultimate Cron is not installed and the ultimate_cron_job entity type does not exist. Optional config is filtered: ConfigInstaller::installOptionalConfig() keeps only config whose entity type resolves, described in core as "this also excludes config that has an implicit dependency on modules that are not yet installed", then drops anything whose declared dependencies are unmet.

So nothing changes for a site today, and the moment Ultimate Cron is enabled on a Varbase site Drupal creates every job whose own module is present. The configuration comes back by itself when the module does.

Remaining tasks

• ✅ File an issue
• ✅ Addition/Change/Update/Fix
• ✅ Testing to ensure no regression
• ✅ Reviewed by a human
• ✅ Code review by maintainers
• ✅ Release varbase-11.0.0

User interface changes

• None. Nothing is enabled or applied by this change.

API changes

• The profile requires eight more packages. Since several have no stable release, vardot/varbase itself does not resolve on a project at default stable stability. In practice it is consumed only through drupal/varbase_project, which sets minimum-stability: dev.
• Note that the project's CI does not exercise this: composer validate --no-check-all does not resolve dependencies, and there is no install job.

Data model changes

• None.

Release notes snippet

• Require in the profile the modules and base recipes that the site templates and base recipes stopped requiring, so a Varbase site keeps getting them. Nothing is enabled or applied by the profile.
• Keep the Ultimate Cron job configuration the recipes had to delete, as optional config in the profile, so it is recreated by itself if Ultimate Cron is enabled.