Can a theme leverage block config Yaml files when installed for the first time?

Question

In my Drupal 8 contrib theme, when the theme is first enabled, a number of system blocks are dumped into the first region that's in my theme's info.yml file. From a UX perspective, this is not really desirable as it makes the theme look ungainly and off balance. The two core blocks in question are "Powered by Drupal" and the "Footer Menu" blocks.

I've played around with placing these two blocks where I want them (in my theme's case, the footer_first and footer_second regions), exporting the config for those and then placing the Yaml files in /mytheme/config/install. I then try a fresh Drupal 8 Beta 1 install on my local and activate the theme once again but the config files seem to have no effect. The two system blocks in question are yet again placed in the first region that's in my theme which is the top area.

I can fool Drupal by placing the footer regions first in my theme's info.yml file but this presents other issues - for example, when users view the block admin page and see those regions come up first when they are actually last.

My guess is, there is no good solution for this but I thought I would ask in case anyone had some ideas.

Answer 1

It turns out tim-plunkett was correct in his comment above. I used the config export function at /config/development/configuration/full/export to export all the block settings for my theme.

I then took all the generated YAML files and placed them in a new folder within my theme at /config/install. I then uninstalled the theme and then reinstalled it as the default. Voila, all my blocks, i.e., menu, help etc... were in their designated regions according to what had been exported in the YAML files.

Some examples of the file names are:

block.block.gratis_help.yml
block.block.gratis_main_menu.yml
block.block.gratis_branding.yml

Answer 2

I had the same issue, but for an admin theme. To copy blocks from the existing admin theme into a new one:

# temporarily set existing_admin to be default theme
drush config-set system.theme default existing_admin -y

# will copy blocks from default theme
drush en -y new_admin_theme

# return to previous default theme
drush config-set system.theme default previous_default_theme -y

# enable new admin theme with copied blocks
drush config-set system.theme admin new_admin_theme -y

Answer 3

Had the same issue:

• Place custom blocks in theme using the UI.
• Export config.
• When it came time to import my config in a new environment custom blocks not appearing in proper region despite .yml files for individual blocks being present in my default config directory...
• As described above solution was to disable and uninstall custom theme and then re-enable.

Here are the steps (Where vcs is our directory for default config defined in settings.php and my_custom_theme is our theme name).

After running drush si, lets import our config.

drush cim vcs --partial -y

At this point although our config has been imported our custom blocks are not appearing in the regions as set in the config .yml files.

Enable a core theme so we are free to uninstall our custom theme.
drush cset system.theme default seven
Important Rebuild the cache now.
drush cr
Uninstall our custom theme.
drush pm-uninstall my_custom_theme -y
Enable our custom theme.
drush en my_custom_theme -y
Set our Custom theme as default theme.
drush cset system.theme default rrre_theme -y
Import our default config.
drush cim vcs
Run Server.
drush rs

:)