Problem/Motivation

When creating a custom admin theme based on Claro it's not picking up Claros block configuration as per:

https://www.drupal.org/docs/theming-drupal/creating-sub-themes#s-inherit...

"If a sub-theme does not supply its own block configurations, Drupal will inherit these block configurations and region placement from the base theme."

I'm instead getting blocks that belong to the sites default end user theme, such as site_branding and powered. The only way around this is to copy Claro's config/ directory to my custom admin theme and manually change any references from claro to the name of my custom theme.

Steps to reproduce

Create a brand new Drupal 10.x site, and create a theme called custom_admin_theme, with the following custom_admin_theme.info.yml file:

name: 'Custom Admin Theme'
type: theme
base theme: claro
core_version_requirement: ^10

regions:
  header: 'Header'
  pre_content: 'Pre-content'
  breadcrumb: Breadcrumb
  highlighted: Highlighted
  help: Help
  content: Content
  page_top: 'Page top'
  page_bottom: 'Page bottom'
  sidebar_first: 'First sidebar'
regions_hidden:
  - sidebar_first

Enable this theme, and do a config export or head to /admin/structure/block/list/custom_admin_theme and you'll see the block configuration doesn't match what is provided by Claro.

Proposed resolution

As I'm not declaring a config directory in my custom theme, use the block config from the base theme Claro as per documentation.

Issue fork drupal-3372705

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

ThomWilhelm created an issue. See original summary.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

ressa’s picture

ressa
he/him
commented
Related issues: +#2635978: Sub-theme doesn't inherit base theme default block config, +#2635166: block_theme_initialize() falls back to putting blocks in the first region it finds, provide a better default, +#3278410: block_theme_initialize() sledgehammers square blocks into round regions, allow themes to provide a mapping of regions to 'roles'

I can confirm this, and that copying over and editing the config folder is a workaround. I am adding the issues where this will be fixed in.

ressa’s picture

ressa
he/him
commented

I updated the documentation pages:

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

gareth.poole made their first commit to this issue’s fork.

gareth.poole opened merge request !16425

gareth.poole’s picture

gareth.poole
Location Wellington, New Zealand
commented

I’ve updated BlockHooks::themeInitialize() so that, when the new theme has an installed base theme with block configuration, those blocks are used as the source; it falls back to the system default theme when the base theme has no blocks.

gareth.poole’s picture

gareth.poole
Location Wellington, New Zealand
commented
Status: Active » Needs review
smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work

Moving to NW per @acbramleys review. Definitely don’t want to be loading things twice

acbramley’s picture

acbramley commented
Title: Extending Claro theme not inheriting Claro blocks » Sub themes do not inherit base theme blocks
acbramley’s picture

acbramley commented
Status: Needs work » Needs review

I still thought that themeInitialize was hard to follow. I used Claude to help refactor it and split out a helper method.

I think ideally we move these into their own Hooks class along with the hooks that call themeInitialize and properly inject all dependencies but that will be much harder to review so I think it's best we keep it this way for now, and perhaps follow up with a further refactor.