task: #3620242 Move Search after Varbase Content Base in recipe.yml

#3620242

Mirrors #3620223 on the Horizon Aid site template, which makes the same one-line move.

What this does

Moves drupal_cms_search in recipe.yml from before the five Varbase base recipes to immediately after varbase_content_base. One line moved, nothing else.

 - drupal_cms_accessibility_tools
-- drupal_cms_search
 - easy_email_express
 - varbase_admin_base
 - varbase_security_base
 - varbase_media_base
 - varbase_editor_base
 - varbase_content_base
+- drupal_cms_search
 - varbase_workflow_base

Why

drupal_cms_search's own recipe.yml applies two wildcard config actions, verified in the recipe source:

  • node.type.* — sets a Search API Exclude third-party setting on every existing content type.
  • core.entity_view_display.node.*.defaultcloneAs: node.%.search_index.

Both act only on content types that exist at the moment Search is applied. Running Search before the Varbase base recipes therefore wires up less of the site's eventual content structure than it could.

What deliberately is NOT claimed here

Horizon Aid's issue also cites a harder failure documented in its own CI: without the curated core patch for #2741429, a fresh install dies inside drupal_cms_search's display cloning with getConfigDependencyName() on null.

That does not apply to Educare, and I checked rather than assumed. Educare's .gitlab-ci.yml, composer.json and README.md contain no vardot/drupal-core-patches reference and no such comment — the patches requirement and the Drupal CMS wiring script were removed in #3618244. Horizon Aid's .gitlab-ci.yml does carry it, at lines 396-434. So this change rests on the wildcard-ordering argument alone.

Testing

None run. No install, no browser check; the pipeline this MR triggers is the only signal so far. The change is argued from the Search recipe's own config actions, not from an observed before/after. Testing to ensure no regression is left unticked accordingly.

Worth a reviewer's attention: moving Search later means its wildcard actions now touch more content types than before, so the installed config differs — more node.type.* entries get the Search API Exclude setting and more node.%.search_index view displays get cloned. That is the intent, but it is a config-output change, not a no-op.

AI-Generated: Yes

Checkpoints

  • File an issue
  • Addition / Change / Update / Fix
  • Automated unit testing coverage
  • Automated functional testing coverage
  • Testing to ensure no regression
  • UX/UI designer responsibilities
  • Readability
  • Accessibility
  • Performance
  • Security
  • Developer Documentation
  • User Guide Documentation
  • Reviewed by a human
  • Code review by maintainers
  • Full testing and approval
  • Credit contributors
  • Review with the product owner
  • Release notes snippet
  • Release
Edited by Rajab Natshah

Merge request reports

Loading