Problem/Motivation

Picking Varbase Starter in the Drupal CMS browser installer finishes and redirects to /admin/dashboard/welcome, but the site is broken: that page and the front page both return HTTP 500.

The cause is a half-applied recipe:

  • system.theme: default is set to vartheme_bs5 (the recipe's config action ran)
  • but core.extension: theme contains only claro and gin, so vartheme_bs5 was never installed, though it is present on disk

A default theme pointing at an uninstalled theme makes every request fatal.

Other symptoms of the same partial apply, all on the finished site:

  • canvas_page_template_component not installed, even though it is in the recipe's install: list
  • varbase_seo_base never ran, so metatag_views is not installed while views.settings: display_extenders still lists metatag_display_extender, giving a PluginNotFoundException on every views load
  • watchdog: The "password_policy" entity type does not exist, The "entity_subqueue" entity type does not exist
  • 16 Canvas errors: Unable to find component "vartheme_bs5:section"

Content does import (14 nodes, 5 Canvas pages), so the recipe applies in part before stopping.

Steps to reproduce

mkdir -p my-drupal-cms-test && cd my-drupal-cms-test
ddev config --project-type=drupal11 --docroot=web
ddev composer create-project drupal/cms
ddev composer config minimum-stability dev
ddev composer require drupal/varbase_starter:1.0.x-dev

Then open /core/install.php in a browser, give the site a name, pick the Varbase Starter template, create the account, and let the install run.

Environment: Drupal CMS 2.1.4, Drupal core 11.4.6, PHP 8.4, drupal/canvas 1.11.0, no patches. Reproduced twice from a clean database, including once watched live: the installer redirects to the finish URL and that response is already a 500.

Important contrast

On the same codebase, the drush paths both complete with exit 0 and 0 warnings/errors, and produce a working site:

  • drush site:install recipes/varbase_starter
  • drush site:install drupal_cms_installer installer_site_template_form.add_ons=varbase_starter

So this is specific to the interactive browser installer, not to the recipe's content.

Proposed resolution

Needs investigation into why the installer's batch stops partway while still redirecting to the recipe's finish_url. Two angles worth checking:

  1. whether the batch is aborting on an error that is swallowed rather than surfaced, and
  2. whether the recipe's system.theme config action can run before its own install: list has installed vartheme_bs5. If so, ordering or a guard is needed so the default theme is never set to an uninstalled theme.

Remaining tasks

  • ✅ File an issue
  • ❌ Find the abort point in the installer batch
  • ❌ Addition/Change/Update/Fix, or report upstream if it is a Drupal CMS installer defect
  • ❌ Testing to ensure no regression
  • ➖ Automated unit testing coverage
  • ❌ Automated functional testing coverage
  • ➖ UX/UI designer responsibilities
  • ➖ Readability
  • ➖ Accessibility
  • ➖ Performance
  • ➖ Security
  • ➖ Developer Documentation
  • ➖ User Guide Documentation
  • ❌ Reviewed by human
  • ❌ Code review by maintainers
  • ❌ Full testing and approval
  • ❌ Credit contributors
  • ➖ Review with the product owner
  • ❌ Release notes snippet
  • ❌ Release

User interface changes

  • N/A

API changes

  • N/A

Data model changes

  • N/A

Release notes snippet

  • N/A

Comments

rajab natshah created an issue.

rajab natshah’s picture

rajab natshah
he/him
commented

Correcting the root cause in the summary above — it is narrower than first reported.

Everything IS installed. Reading core.extension straight from the database shows 243 extensions, including redirect, password_policy, entityqueue, metatag_views, persistent_login, roleassign and vartheme_bs5. The recipe applies fully and the content lands (14 nodes, 5 Canvas pages, 59 media).

The failure is a stale container after the install, not a partial apply. A cache rebuild clears it completely:

drush cr
→ default theme: vartheme_bs5
→ / /features /blog /user/login all HTTP 200

The earlier evidence that pointed at a partial install (core.extension showing only claro and gin, vartheme_bs5 "missing") was itself a symptom: drush could not bootstrap cleanly against the stale cache, so it returned partial data.

So the real defect is: a browser install finishes and redirects the user to /admin/dashboard/welcome, which returns HTTP 500 until caches are rebuilt. The specific "entity type does not exist" varies per run (redirect, password_policy, entity_subqueue), which is consistent with a stale container rather than any one missing module.

Reproduced three times on clean databases, on plain drupal/cms with Drupal core 11.4.6, PHP 8.4, drupal/canvas 1.11.0, no patches. The drush paths are unaffected — both drush site:install recipes/varbase_starter and the drupal_cms_installer add-on path exit 0 and produce a working site.