Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#16 | block_placement.png | 225.44 KB | C13L0 |
Comments
Comment #2
markhalliwellHm, well it should. I suppose there's something going on in ThemeInstaller that should be fixed.
Comment #5
jphelan CreditAttribution: jphelan commentedSame issue
Comment #6
dcrocks CreditAttribution: dcrocks as a volunteer commentedThemes 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
Comment #7
Jeff Burnz CreditAttribution: Jeff Burnz commented@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
Comment #8
dcrocks CreditAttribution: dcrocks as a volunteer commentedInheriting 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.
Comment #9
jphelan CreditAttribution: jphelan commentedIn 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.
Comment #10
dcrocks CreditAttribution: dcrocks as a volunteer commentedAdminimal 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.
Comment #11
Jeff Burnz CreditAttribution: Jeff Burnz commented@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.
Comment #12
markhalliwellThis 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.Comment #13
staceroni CreditAttribution: staceroni commentedI 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.
Comment #15
C13L0 CreditAttribution: C13L0 as a volunteer commentedThis 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:
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
Passing the baton:
I’m a front-end dev and would like to pass this to someone who can make it happen!
Comment #16
C13L0 CreditAttribution: C13L0 as a volunteer commentedComment #17
Ablont CreditAttribution: Ablont commentedI 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.
Comment #18
AnybodyThis 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.
Comment #19
htia CreditAttribution: htia commentedHi, 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.
Comment #20
codesmithWhat'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).
Comment #21
codesmithIs there a way to prevent blocks from being copied/created when installing a theme?
Comment #22
Ablont CreditAttribution: Ablont commentedI 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.
Comment #24
RAWDESK CreditAttribution: RAWDESK commented@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.
Comment #26
AaronMcHaleI 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.
Comment #27
bdanin CreditAttribution: bdanin commentedThis 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?)
Comment #28
trwill CreditAttribution: trwill commentedThis 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.
Comment #30
Nick Hope CreditAttribution: Nick Hope commentedI created a Seven sub-theme and found that my these 3 blocks were missing:
In my case I solved it by copying these files from the Adminimal theme into my theme:
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.
Comment #32
gwefeistr CreditAttribution: gwefeistr commentedThis 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.
Comment #35
bvoynick#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:
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.
Comment #37
jcandan CreditAttribution: jcandan as a volunteer commentedI 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:
However, this discussion reveals several opportunities for improvement, and one or multiple tickets should be created to address the concerns noted above:
False by default, but this should be a separate ticket since it is a breaking change.
Sub-themes should adopt block placement configs, and consider its own configs as overrides.
This might be considered a much broader change since several sub-theme inheritance properties all assume this.
Comment #38
ressa CreditAttribution: ressa at Ardea commentedThanks @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.
Comment #44
catchWith the docs update, this is a duplicate of #3278410: block_theme_initialize() sledgehammers square blocks into round regions, allow themes to provide a mapping of regions to 'roles' and related issues.
Comment #45
catch