Pin block component versions to active, so a stale hash cannot 500 the Canvas pages

Problem/Motivation

The shipped Canvas config pins hard-coded component_version hashes for block.* components. That is not portable, and on Horizon Aid the same pattern makes every Canvas page return HTTP 500 on a plain Drupal CMS base (horizonaid #3620437):

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

Why a hard-coded hash cannot work for a block component

Canvas auto-creates a component config entity per block plugin — on an installed site it reports provider: system, so Canvas created it, not the recipe. Recipes do not overwrite config that already exists, so the recipe's own canvas.component.block.*.yml never imports, and any hash it declared is left unreferenced. The hash is derived from the component payload, so which value lands on disk depends on who created the entity first.

Status in this recipe

Educare currently pins 7d528e00f56b3abf for block.system_branding_block, which happens to match the value Canvas derives on a Drupal CMS base — so Educare is not broken today. That is luck, not design: the hash was captured from an environment whose payload matched. Any change to the block payload, the theme, or the base makes it dangle exactly as Horizon Aid's does.

This is also currently masked on Varbase by a patch that is being removed. vardot/varbase-patches carries canvas MR !927 (#3585221), which makes assertVersionExists() fall back to active_version instead of throwing. Its removal is tracked in varbase-patches #622. Once it is gone, a stale pin is a 500 on Varbase too.

Proposed resolution

Use component_version: active for block.* components. assertVersionExists() accepts a version that equals active_version or is a key in versioned_properties, and active is always such a key, so it never dangles; Canvas resolves it to the local component version at import time.

Seven block.* pins change:

• canvas.page_region.vartheme_bs5_educare.header.yml — block.system_branding_block, block.system_menu_block.main, block.views_exposed_filter_block.search-block_1
• canvas.page_region.vartheme_bs5_educare.footer.yml — block.system_menu_block.secondary, block.system_menu_block.social-media-menu, block.system_menu_block.footer
• canvas.content_template.node.page.full.yml — block.system_breadcrumb_block

The sdc.* pins are deliberately left alone. Those components ship with vartheme_bs5_educare, so this recipe controls their payload, their hashes are deterministic, and pinning them is an intentional guarantee.

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

User interface changes

• None expected. Educare renders today; this removes the latent failure rather than fixing a visible one.

API changes

• N/A

Data model changes

• Block component references 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 and footer page regions and the Page full content template, so a stale hash cannot make Canvas pages throw OutOfRangeException.

AI-Generated: Yes