Pin block component versions to active, as a hard-coded hash 500s every Canvas page on a Drupal CMS base

Problem/Motivation

On a plain Drupal CMS base, the install completes and then every Canvas page returns HTTP 500:

OutOfRangeException: The requested version `b168140fdcaebae5` is not available.
Available versions: `7d528e00f56b3abf`.
  in Drupal\canvas\Entity\VersionedConfigEntityBase->assertVersionExists()

config/canvas.page_region.vartheme_bs5_horizonaid.header.yml pins component_version: b168140fdcaebae5 for block.system_branding_block. The component on the installed site carries 7d528e00f56b3abf, so the pin dangles and rendering throws.

Why the pin dangles

Canvas auto-creates a component config entity for each block plugin. On the installed site that entity reports provider: system — Canvas created it, not this recipe. Recipes do not overwrite config that already exists, so the recipe's own config/canvas.component.block.system_branding_block.yml (which declares b168140fdcaebae5) never imports, and the region is left pointing at a version nothing defines.

The hash is derived from the component payload, so which value ends up on disk depends on who created the entity first. That makes a hard-coded hash for an auto-created block component non-portable by construction.

Steps to reproduce

Drupal CMS Project template - Horizon Aid

mkdir -p ~/workmspace/test/my-drupal-site-horizonaid1
cd my-drupal-site-horizonaid1
ddev config --project-type=drupal11 --docroot=web
ddev composer create-project drupal/cms
ddev composer config minimum-stability dev
ddev rm composer.lock
ddev composer require drupal/horizonaid:1.0.x-dev

1. Install through the browser installer, picking the Horizon Aid site template. The install completes.
2. Visit /, /about, /programs, /events, /donate — all 500 with the exception above.

Proposed resolution

Use component_version: active for block.* components, which is already this recipe's own convention — canvas.page_region.vartheme_bs5_horizonaid.footer.yml pins active for its block components and renders correctly on both bases.

active is portable because assertVersionExists() accepts a version that either equals active_version or is a key in versioned_properties, and active is always such a key. Canvas resolves it to the local component's current hash at import time — verified by reading the footer region back out of the database after install, where the shipped active values had become concrete per-environment hashes.

Four block.* pins change:

• canvas.page_region.vartheme_bs5_horizonaid.header.yml — block.system_branding_block, block.system_menu_block.main, block.views_exposed_filter_block.search-block_1
• canvas.content_template.node.country.full.yml — block.views_block.countries-related_slider

The sdc.* pins are deliberately left alone. Those components ship with vartheme_bs5_horizonaid, so this recipe controls their payload and their hashes are deterministic. Pinning them to a specific version is intentional, and replacing that with active would discard a real guarantee.

Why not patch Canvas instead

vardot/varbase-patches has been carrying canvas MR !927 (#3585221), which makes assertVersionExists() fall back to active_version instead of throwing. That patch is why this bug never showed on Varbase: it silently masked every stale pin. It is being removed (varbase-patches #622), which is what surfaced this.

Fixing the data rather than re-adding the patch keeps to what Drupal CMS and Drupal Canvas provide, with minimal additions and minimal patches.

Remaining tasks

• ✅ File an issue
• ✅ Addition/Change/Update/Fix
• ✅ Testing to ensure no regression
• ➖ Automated unit/functional testing coverage
• ➖ Developer Documentation support
• ➖ User Guide Documentation support
• ➖ UX/UI designer responsibilities
• ➖ Accessibility and Readability
• ❌ Reviewed by a human
• ❌ Code review by maintainers
• ❌ Full testing and approval
• ❌ Credit contributors
• ❌ Review with the product owner
• ✅ Update Release Notes
• ✅ Release, horizonaid-1.0.0-alpha2

User interface changes

• Canvas pages render on a Drupal CMS base instead of returning 500. No visual change where they already rendered.

API changes

• N/A

Data model changes

• Block component references in the header region and the Country full content template resolve to the local component version at import time rather than a fixed hash.

Release notes snippet

• Pin block component versions to active in the header page region and the Country full content template, so Canvas pages render on a Drupal CMS base instead of throwing OutOfRangeException on a stale hash.

AI-Generated: Yes