The header search box names a Views block display the recipe creates only after its own config, losing the Component dependencies

Problem/Motivation

Installing the recipe logs:

ddev drush si -y ../recipes/horizonaid

 [warning] The "views_exposed_filter_block:search-block_1" block plugin was not found
 [warning] The "views_exposed_filter_block:search-block_1" block plugin was not found
 [warning] The "views_exposed_filter_block:search-block_1" block plugin was not found

The recipe ships config/canvas.component.block.views_exposed_filter_block.search-block_1.yml, a Canvas Component over the Views exposed-filter block of a block_1 display on views.view.search. That display does not exist yet at that moment: the recipe creates it itself, in a config ACTION:

views.view.search:
  simpleConfigUpdate:
    display.page.display_options.exposed_block: false
    display.block_1:
      id: block_1
      display_title: 'Header search form'
      display_plugin: block
      position: 3
      display_options:
        exposed_block: true

and Drupal\Core\Recipe\RecipeRunner::processConfiguration() runs a recipe's config actions AFTER installing its config. So when the Component is saved, views_exposed_filter_block:search-block_1 has no derivative, Drupal\Core\Block\BlockManager falls back to the broken plugin and logs the warning.

The warning is the visible part. The real damage is that the Component's dependencies are calculated against the broken plugin and come out empty - permanently, because nothing re-saves it afterwards:

ddev drush cget canvas.component.block.views_exposed_filter_block.search-block_1 dependencies
'canvas.component.block.views_exposed_filter_block.search-block_1:dependencies': {  }

ddev drush cget canvas.component.block.views_exposed_filter_block.blog-all dependencies
'canvas.component.block.views_exposed_filter_block.blog-all:dependencies':
  config:
    - views.view.blog
  module:
    - views

It should read config: [views.view.search] and module: [views], exactly like every other exposed-filter Component in the recipe - those work because the views they name are created by an EARLIER recipe. A drush cr does not repair it: Canvas only re-saves a Component when its version hash or its metadata changes.

Separately, the arrangement puts two search boxes on /search: the header block, and the page display's inline exposed form that exposed_block: false turns back on.

Steps to reproduce

mkdir -p my-drupal-site-horizonaid
cd my-drupal-site-horizonaid
ddev config --project-type=drupal11 --docroot=web
ddev composer create-project drupal/cms
ddev composer require drupal/horizonaid
ddev drush si -y ../recipes/horizonaid
ddev drush cget canvas.component.block.views_exposed_filter_block.search-block_1 dependencies

Proposed resolution

Drop the block_1 display and the display.page.display_options.exposed_block: false override, and point the header at the page display's own exposed block, views_exposed_filter_block:search-page. Drupal CMS Search already ships that display with exposed_block: true, so the derivative exists before the recipe's config is installed and the Component is created with the right dependencies and no warning.

• config/canvas.component.block.views_exposed_filter_block.search-block_1.yml becomes ...search-page.yml, at version 435ec28df1ef5629.
• config/canvas.page_region.vartheme_bs5_horizonaid.header.yml names the new Component in its dependencies and in its component tree.
• The views.view.search config action loses the two lines that created and compensated for block_1. Everything else it sets - the placeholder, the label, text_input_required, the row style and the header - is unchanged.

The site keeps exactly one search box, in the header, on every page including /search. The theme's own icon-toggle component already documents this shape: "the 'Exposed form: search-page' block for a search toggle".

Verified on a clean build of Drupal CMS 2.1.4 + Horizon Aid: no warnings, canvas.component.block.views_exposed_filter_block.search-page installs with config: [views.view.search] and module: [views], the header renders views-exposed-form-search-page, and /search renders it exactly once and returns results.

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

• The search results page no longer renders a second search box below the header one. The header search box is unchanged.

API changes

• N/A

Data model changes

• views.view.search no longer gains a block_1 display, and its page display keeps the exposed_block: true Drupal CMS Search ships.
• The Canvas Component block.views_exposed_filter_block.search-block_1 is replaced by block.views_exposed_filter_block.search-page.

Release notes snippet

• The header search box now uses the search page's own exposed block, so installing no longer logs a missing-block-plugin warning and the search results page shows one search box instead of two.