I created a SubTheme of Bootstrap. Most everything is working well.

When I initially install my SubTheme, the default block layout for Bootstrap is not passed to the SubTheme. What the SubTheme sees in the block layout is pretty random and is not useful.

My solution is to enable Bootstrap first and then enable the SubTheme which makes the default block layout available. At this point my customization is easily applied.

CommentFileSizeAuthor
#16 block_placement.png225.44 KBC13L0
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Greg Sims created an issue. See original summary.

markhalliwell’s picture

Title: Default Block Layout for SubTheme » Sub-theme doesn't inherit base theme default block config
Project: Bootstrap » Drupal core
Version: 8.x-3.0-beta1 » 8.0.x-dev
Component: Starterkit (CDN) » theme system

Hm, well it should. I suppose there's something going on in ThemeInstaller that should be fixed.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jphelan’s picture

Same issue

dcrocks’s picture

Themes inherit blocks from the active theme when they are installed, or alternately, blocks defined in the the theme's config/install?optional directory. Bootstrap defines its blocks in its config/optional directory, so when you install your theme after installing bootstrap you inherit bootstrap's blocks then. You can copy bootstrap's config/optional directory to your theme's config/optional directory to eliminate the double install. Or you can raise the issue as whether it the proper behavior for theme's with base themes to inherit the configuration of the base theme when installed.

For some documentation, see Optional configuration provided by modules and themes is now stored in config/optional

Jeff Burnz’s picture

@dcrocks - this bit "Themes inherit blocks from the active theme when they are installed", is not my consistent experience, it can fail and the default blocks can be dumped into the first region defined in info.yml.

As yet I've been unable to figure out a way to force that inheritance from base theme to sub-theme without manually creating the config files and placing in optional before sub-theme installation. The problem is mostly custom blocks, and well, this whole crazy idea of blocks being tied to themes which frankly is a massive pita. IMO we need to seriously discuss decoupling block layout from themes, i.e. #1787634: [META] Decouple layouts from themes

dcrocks’s picture

Inheriting blocks from the active theme on theme install is certain to be inconsistent because you can't be certain the 2 themes have the same region names. To me this is very messy, especially for new users of drupal. But it has often been argued it is easy to clean up. That is why I favor putting block definitions in the themes config/install directory. This way I guarantee my theme will look the same no matter where or when it is installed. But the same people who favor just cleaning up argue that is too much work and difficult for new users. I disagree and think the theme block inheritance system can make drupal very ugly for new users, who are quite capable of cutting and pasting from existing themes, should good examples be available.
Defining regions in the .info file and blocks in /config actually constitutes a single page layout system, in a back handed sort of way.

jphelan’s picture

In my case I'm trying to make a subtheme for the Adminimal theme to do some simple css changes. However the block are all screwed up and there are blocks Adminimal uses that seem to not be available to my theme. Works if I copy over and rename the config files but that kind defeats some of the purpose of using a subtheme. So since it's the admin theme I don't set either as default.

dcrocks’s picture

Adminimal theme is a subtheme of Seven and does have its own config/install directory with all the blocks defined for the seven theme but renamed for adminimal. But it is apparent that config is not inherited and I'm not sure if its possible to do so because of name conflicts. For adminimal to work with seven as a base theme, it had to do what you had to do for your theme with adminiml as a base theme; copy block yml files to your theme's /config/install.
Not the best but I'm not sure how to make a theme inherit a base theme's config. As pointed out, there are other solutions being proposed but they seem to be fairly large changes with undetermined completion dates.

Note that seven does not define any blocks in its /config directory. They are actually defined by the config/install directory for the install profile; minimal, standard, etc. So depending on that, the blocks you define may not have the necessary modules installed.

Jeff Burnz’s picture

@dcrocks these themes have exactly the same regions.

Block inheritance should never happen, because block layout should not be tied to themes in any way. It's a mangling of concerns that should be separate. That is, again, separate from block config which themes should be able to supply, but the relations should end there. Blocks should be tied to layouts, which might also be supplied by the theme, but maybe not - maybe they're coming from Panels or some other module.

@jphelan the reason is blocks are tied to themes, almost every other bit of config can be easily inherited (which would be even easier to achieve if themes could use hook_install), even could be done for blocks if we had hook_install.

markhalliwell’s picture

Version: 8.2.x-dev » 8.3.x-dev
Priority: Normal » Major

This is still a very annoying issue when initially creating sub-themes (especially from an already designed base/sub-theme).

As it stands now, a sub-theme must include all the config/optional/block-*.yml files to be installed, causing for a headache of management.

staceroni’s picture

I was seeing the random block placement after activating a new theme, as well.

My new theme does not have /config/optional files, and the base theme does not have any as well. When activating the new theme, I expect it to duplicate the current active block configuration to the new theme.

My problem was with block machine names.

Current active theme: Foo
New theme: Bar

I had a block placed twice in Foo, resulting in the machine names:
block_myblock
foo_block_myblock

When I activate the new theme, the blocks are named:
bar_block_myblock
bar_block_myblock

which results in an exception:
Drupal\Core\Entity\EntityStorageException: 'block' entity with ID 'bar_block_myblock' already exists

So to avoid this error, I removed any block named foo_block_*** and named them with an identifier:
block_myblock_1
block_myblock_2

Now I can activate the theme Bar, and I get all expected block configuration and no errors.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

C13L0’s picture

Issue tags: +FLDC17

This error can be reproduced with the following steps:

1. Fresh install of 8.4.0-dev

2. Created 3 blocks with the machine names of:

  • testblock_content
  • testblock_sidebar_first
  • testblock_footer_first

3.Placed each block into it’s designated Bartik region (content, sidebar first, footer first)

4.Download latest version of Bootstrap (8.x-3.1)
$ drush dl bootstrap

5. Created bootstrap subtheme using the cdn version.
https://drupal-bootstrap.org/api/bootstrap/docs%21Sub-Theming.md/group/s...

6. Navigate to admin/appearance
Click “Install and set as default” on your custom bootstrap subtheme

$ drush cr all


Conclusion:

Bootstrap does not have the same regions as Bartik. So, it appears that blocks are randomly placed in various regions. (See screenshot)

Expected behavior:
In D7, when enabling a new theme, a warning message would show in the UI similar to the following:
[warning] The block cielo_subtheme_testblock_footer_first was assigned to the invalid region footer_first and has been disabled.


Recommendation:

Add a warning message to display in the UI.

Bartik uses the following code to display a warning message when a block is assigned to an invalid region found in core/modules/block/block.module

  146          if (!isset($regions[$block->getRegion()])) {
  147            if ($block->status()) {
  148:             drupal_set_message(t('The block %info was assigned to the invalid region %region and has been disabled.', ['%info' => $block_id, '%region' => $block->getRegion()]), 'warning');
  149            }
  150            $block


Passing the baton:

I’m a front-end dev and would like to pass this to someone who can make it happen!

C13L0’s picture

FileSize
225.44 KB
Ablont’s picture

I was encountering the same problem and i found a way:
You need the exact same regions as in the base theme!
You should just copy the ones from the base theme and reinstall your theme.
After you enabled it the blocks should have the same position as in the base theme.

Anybody’s picture

This issue cost me 3 hours .... finally copied the base themes config/optional .yml files and replaced the base theme name in the file contents and names, reinstalled the subtheme and cleared caches ... then it worked
.... before my subtheme block settings were not working at all.

I'm so sad .... :( Going to bed now... crying.

Could we please state this out somewhere? In my case this happened in bootstrap theme.

htia’s picture

Hi, I encountered the same issue with a fresh install of Drupal 8.2.x with Boostrap theme and creating a subtheme from it.
The assumption is that i have just created some new content types and custom fields, but no new blocks. After installing the subtheme, the layout is messy like the first screenshot attached to this thread.

Here is the way I used to solved it :
- Download Bootstrap Theme
- Create the custom theme folder
- Copy the starterkits/cdn (from the Boostrap theme folder) content to the custom theme folder
- Copy the config/optional folder (from the Bootstrap theme folder) to custom theme "config" folder
- In the custom theme config/optional folder, rename everything that content "bootstrap" in filenames and files content with the name of your custom theme
- Install your custom theme
- Clear the cache

Hope this can help.

codesmith’s picture

What's described in #17 was not my experience. I tried to create a sub-theme of Seven to create a custom Admin theme. I kept Seven's regions set up in my theme info file. Installing the theme resulted in most (not all) of the blocks from my website theme being dumped into the Header region. It did not duplicate the existing blocks that were in Seven.

Furthermore, I uninstalled my custom admin theme to change some settings and then re-installed. I then got a Fatal error:

Drupal\Core\Entity\EntityStorageException: 'block' entity with ID 'MYADMINTHEME_BLOCKNAME_2' already exists. in Drupal\Core\Entity\EntityStorageBase->doPreSave() (line 425 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).

codesmith’s picture

Is there a way to prevent blocks from being copied/created when installing a theme?

Ablont’s picture

I don't think you can prevent that.
But you can try deleting the blocks when you uninstall your module.
I had the same problem with content types... i had to delete all of them in my modules uninstall hook.
Maybe that may help you with your latest problem.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

RAWDESK’s picture

@dcrocks #10
Thanks for providing the solution in my efforts to subtheme seven theme, in order to have some custom styling and user.html.twig template extended.
It solved my issues as reported initially here, but for some reason my subtheme 'seven_sub' is only applied to admin pages like users/admin and admin/config/people.
If I navigate the site (via my frontend theme), the administration menu is styled by parent 'seven' theme, where I expected also /themes/custom/seven_sub/css/seven_sub.css to be embedded.

PS. This behaviour is identical on adminimal theme, after installing and enabling it.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

AaronMcHale’s picture

I experienced this issue but only when the base theme is installed as a result of the sub-theme being installed.

Steps to reproduce:
- Create a theme and define some regions and block configuration
- Create another theme and set the first theme as the base theme, include the same region configuration but not any of the block configs
- Enable the sub-theme, which will also enable the base theme, the block configuration will only be present for the base theme

The work around I have noticed is to enable the base theme, then enable the sub-theme, doing them one after the other does not cause this issue.

bdanin’s picture

This is an issue for me as well, and it's not clear how it's supposed to work nor what one should do.

What I would like to do:

- Have a base-theme that defines regions and block placements
- Have a sub-theme that will inherit the base-theme's regions and block placements.

Maybe there should be a flag in the .info.yml file that can be toggled with "base_inheritance: false" but would otherwise keep a base-theme and sub-theme's regions in sync with each other

Having to manually copy (and later keep track of any changes to) theme regions between a base and sub-theme is not good. At minimum, we need to be able to import the regions from one theme to another, so we can define a single source of truth for regions (maybe region declarations should come from a referenced file like libraries?)

trwill’s picture

This is also an issue for us, and I could see it being very confusing to a novice. If you have a base theme, extending it should maintain all of the block config and placement, and treat the base theme dependencies and placement as an 'interface' (meaning if subtheme extends it, and we have the region available, place it). I understand why that's very complicated as subthemes can change regions etc, but in most cases they shouldn't (or at least the dev would be responsible).

For example:

- Base theme contains a block with some basic config
- Subtheme A and Subtheme B both extend Base theme
- The answer I'm seeing here is to export the yml in triplicate, one for each theme

This just isn't great - since I have to place the yml in subtheme A and B, I really no longer have a need for the base yml. Now when I create a new subtheme, I have to look at an extending subtheme to see what I need to restore my 'base' block layout. If I change block default config, now I have to update 3 ymls instead of 1, etc etc. Creates more maintenance than just inheriting everything that it can from the base.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Nick Hope’s picture

I created a Seven sub-theme and found that my these 3 blocks were missing:

  • Primary tabs
  • Secondary tabs
  • Status messages

In my case I solved it by copying these files from the Adminimal theme into my theme:

  • config/install/block.block.adminimal_theme_messages.yml
  • config/install/block.block.adminimal_theme_primary_local_tasks.yml
  • config/install/block.block.adminimal_theme_secondary_local_tasks.yml

I then renamed "adminimal_theme" to my theme name in both their titles and all the instances of "adminimal_theme" within them. Then I had to uninstall my theme, then reinstall it, then re-set it as the admin theme. Those 3 blocks then appeared in the block layout. My other blocks had gone so I had to place those again.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

gwefeistr’s picture

This happened to me, even though I was following the official Drupal dodumentation on sub-theming. As with the screenshot associated with this bug report, I had blocks in the wrong region e.g. the footer blocks (such as 'Powered by Drupal') in the header region. In the end I moved all the blocks to their correct regions, and I had a successfull sub-theme. But, it cost me a lot of time and worry as a newbie Drupal developer.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

bvoynick’s picture

Component: theme system » block.module

#17 is not my experience either, and is not what the code does as of 8.8.5.

It's true that this is what the documentation says will happen. At https://www.drupal.org/node/2165673 it reads "Drupal can inherit these block configurations and region placement from the base theme but if the theme regions defined in your sub-theme's info.yml file do not match those available in the base theme, unpredictable placements in random regions can occur." The part about region placement is indeed in the code, any blocks without an identical region to go to get dumped in the theme's default region instead.

However, it is not the base theme that the inherited blocks are taken from, it is the current default theme. block_theme_initialize() in core/modules/block/block.module determines which theme to grab block configuration from based on a call to \Drupal::config('system.theme')->get('default'). So, the issue lies in the Block module. (Updating this ticket's Component to match.)

The good news is, there is at least a workaround. When installing your child theme, you need to make sure the parent theme is not merely installed, but also the site's default theme.

One change that I'd think should be possible would be to look up the base theme of the theme being processed, and inherit from that instead. The one possible wrinkle is, I don't know if the order of the installed themes that are looped through in block_themes_installed() is guaranteed. I'd guess so but I don't know the theme system that well. If it is not, that could create problems, if a child theme that has no initial configured blocks is processed before its parent theme that also has no configured blocks. The child would end up still blockless at the end.

I'm not sure if that change would be what people expect, though, because imagine the following scenario:

  • User installs Theme A that provides a certain block configuration, call it Block Configuration 1, in its config/optional folder.
  • User deletes the blocks from Block Configuration 1 from their site and instead manually configures Block Configuration 2 for Theme A on their site. (Not changing Theme A's files, just changing the config in the database.)
  • User installs Theme B that specifies Theme A as its base.

What block configuration should we expect Theme B to inherit: 1, or 2? This ticket's title assumes that it should be 1, the blocks specified in the theme's configuration files. However, the d.o documentation referenced above reads ambiguously to me. I could take either from the documentation. The current implementation, while faulty in that it disregards the base theme entirely, is otherwise implementing that it should be Block Configuration 2 inherited.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

jcandan’s picture

I added clarification in two parts of Drupal documentation about this. With this new clarification, this bug, titled Sub-theme doesn't inherit base theme default block config, should be marked resolved.

The clarification is this:
Block placement inheritance only occurs:

  • from the current default theme,
  • only if the sub-theme does not have any of its own block placement configs,
  • and will place blocks in the theme's default region if a matching region could not be found.

However, this discussion reveals several opportunities for improvement, and one or multiple tickets should be created to address the concerns noted above:

  • Allow sub-themes to conditionally configure whether to inherit block placements.
    False by default, but this should be a separate ticket since it is a breaking change.
  • Inherit block placement for sub-themes regardless of sub-theme block placement configurations.
    Sub-themes should adopt block placement configs, and consider its own configs as overrides.
  • Inherit from parent theme rather than default theme.
    This might be considered a much broader change since several sub-theme inheritance properties all assume this.
ressa’s picture

Thanks @bvoynick and @jcandan for clarifying what is required for a sub-theme to inherit block placement from its base theme. I have updated Creating sub-themes, for Drupal 8, 9 and 10.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

Issue tags: +Bug Smash Initiative