Move Claro standard profile block config into the Claro theme

This makes a lot of sense, I've already seen a lot of problems with custom install profiles and blocks being placed in the wrong regions. If they were set in the theme then developers wouldn't have to do this themselves.

I don't know what makes sense for Bartik, does it make sense to split the issues? The use case for Seven is really strong.

I tested moving seven's config install files to the theme's directory from the standard profile's directory and drupal install finished without error. Nor was there weirdness after uninstalling then installing seven again. Haven't looked at impact against tests yet.
If config install files should be local for themes shouldn't they be local for modules as well?

I ran an experiment to confirm what I thought I saw in the code. A configuration file in profiles/standard/config/install overrides one with the same name in core/themes/themename/config/install, even after the theme is uninstalled and then re-installed. This makes sense when installing drupal, but I don't think it is appropriate behavior after install.

Still trying to figure out behavior.
1) So, during drupal install all the profile/config/install files for themes and modules are installed.
2) After drupal install if a theme's or module's config/install directory does not exist or is empty then profile/config/install files are ignored when re-installing the theme or module.
3) If a theme or module has a non-empty config/install directory then all those files will be processed, but if any file has matching entry('s) in profile/config/install, they will be overridden by the corresponding files in the profile/config/install files.

This really only applies to themes and modules installed during drupal install, so maybe the behavior (3) isn't so worrisome. So the simple answer is to move those install files to the object that is being installed.

Simple move

I don't quite know what this failure is saying. Clearly install has no problem. Is it saying this config info HAS to be in the install profile? Is this test checking to see if the config files exist in install directories before the install is attempted?

All the failures are due to unmet dependencies. You should move those block files to the 'optional' directory, so into themes/seven/config/optional and not install, because some blocks might have dependencies on modules and/or other configuration.

How do I determine the unmet dependency? Using config/optional works but seems misleading as these configuration files certainly are required for the theme to work properly. Is this just to get around some tests?

Moving them all to optional shouldn't be a problem, Drupal will always scan this folder when a new extension is installed.
So say that on initial install only 4 files are imported, when enabling a new module it will scan the folder again to figure out if there's something that can be newly imported or not.

And yes, this is to get around failing tests where not every module is enabled always, like say the help module.

This moves everything to optional.

The documentation for this is in the change records. Given that 8.0 is out, this is harder to find than it should be.
Optional configuration provided by modules and themes is now stored in config/optional

Added issues for stark and bartik. Raises the question as to whether config files for modules should also be stored with the module.

There weren't any test system failures for this change to Seven but it still seems misleading to me to have these files in an 'optional' folder. It might be better to leave the files in the profile/config/install directories and move a copy into the theme's config/install directory. Not pretty but would work. Any thoughts?

Would like to note this is a problem for modules as well. If you uninstall and then reinstall a module you will lose any configuration files installed by the install profile's config/install folder. RDF and Responsive Images are simple examples.

For consistency

How do you force retest on these?

Try again. 'git clone' is more complicated now since composer required to add vendor directory.

Thank to @dcrocks I can tell that this issue is related to #2665384: Admin theme gets wrong block placement during install when default theme contains block config

Since an uninstall, install cycle on this theme results in incorrect output, this should be in the bug queue, not task.

As per this issue i had verified and every thing working fine with using last comment #23 patch.

I appreciate the review. If you have time, could you review the 2 related issues?

Thanks @drocks i had updated other related issue too please check once.

I'm not convinced by this issue. Firstly the config should depend on Seven so having it in config/install should not be a problem for some of them - but there's a wider issue. These blocks are configured depending on what modules standard installs. This is standard config - not Seven's. If you install Seven after installing the minimal profile I would expect to do the block placement myself.

Setting back to "needs review" for more opinions.

One thing that is apparent is that when uninstalling a theme we should list the configuration that will be deleted so the user knows this is not a reversible step. At the moment that does not appear to be happening.

Just a couple of points.
These block config files are specifically for the themes they are defined for, not for the install profiles. They are meaningless to the install profiles if their theme is not also activated by the profile. They were previously in the profile's config directory because that was the only place they could be activated during install.

It has always been bad DX for core themes needing a visit to admin for block placement on install/reinstall. Block inheritance is a nice convenience but really is a nuisance when developing new themes or when working with established themes. Bartik, et all, should always work out of the box, especially for those new to drupal. What kind of experience is drupal providing when a theme becomes broken just because it has gone thru an uninstall/install cycle.

As has been pointed out elsewhere, a theme shouldn't be installed if its dependencies aren't met. Using 'config/optional' instead of 'config/install' provides a soft failure instead of a hard one. Also, bartik and stark are too often used in tests when those tests have absolutely no dependence on those specific themes. These constantly evolving themes are being used instead of static test system themes, resulting in completely unnecessary test failures.

@dcrocks hmm actually I agree with you about the way the block module responds to a theme install. Perhaps I'm wrong here - you're right that in D7 terms themes couldn't do this because they had no installation status and no they have so perhaps this is fixable.

In the Seven example here only the help block is dependent on something that is not required so it is the only one that needs to be in config/optional - the others should be able to in config/install.

Also I'm pondering about the affect of this change on existing install profiles.

I was surprised to learn this config resides in the standard profile. It seems appropriate to have it reside within Seven. As far as config/install vs config/optional, I can see both points in #31 and #32.

From #31:

In the Seven example here only the help block is dependent on something that is not required so it is the only one that needs to be in config/optional - the others should be able to in config/install.

From #32:

Block module is optional, so to me the sensible thing is to have its config in /optional.

I think the end result of these is going to be the same, in 99.9% of use cases, as most probably use the Block module... But, I guess technically #32 is correct, given Block module can be uninstalled.

Here's a thought - if we moved the config into the profile's optional configuration then it would be reinstalled with the theme but it would avoid polluting the theme with config that's dependent on an install profile.

This config does not belong in the theme - it is profile specific.

Needed a re-roll after #2994579: Remove obsolete login blocks.

The use case assumed here is "uninstall, then re-install". However there's a broader use case: sites where Seven was never installed in the first place. For example...

1. A site-builder starts with the Minimal install profile, and immediately wants an admin theme.
2. A site-builder starts from a distro, and is dismayed to find it uses a custom/contrib admin theme which they aren't familiar with. They'd rather have the default core admin theme.
3. An agency uses a contrib admin theme for all their clients. One of the support developers hates this, because it hides all the form descriptions. So the first thing they do after fetching a DB dump is enable Seven. They do this for every website, every DB dump.

The thing these all have in common is they want the familiar default admin UI quickly, and they want it to just work without manually setting blocks up. Regardless of which profile was used.

A profile is an opinionated assortment of config, to answer the question: "what sort of site is this for?". I don't think the blocks which Seven gets are profile-specific in that sense. Rather these are the minimum blocks every site needs to make the Drupal admin UI usable: local tasks and actions, messages, breadcrumbs, and help. Apart from the help block, they all come from system module.

Bartik in Standard gets a few extra ones which you can argue are profile-specific, such as the search block. Umami certainly has a lot of profile-specific ones; distros likewise.

So it sounds to me like a few important blocks (mostly from system module) belong in the theme's config, and profiles add the opinionated choices.

Added #3099503: Seven theme: blocks configuration missing if exported to profiles as a duplicate and will close that. Also added dxvargas as a contributor, he should get credit when this gets in for patches on the duplicate issue.

I applied the latest patch to an issue fork. I also added a patch without renames, in case those cause troubles when applying through cweagans/composer-patches (they do for me)

Patch #55 works for me on 9.3.9.

In #3277057: Make Claro the default admin theme in Standard profile we changed the default admin theme from Seven to Claro, and the Seven block config in the profile for Seven was repurposed for Claro.

Next steps here are to test the initial bug here against Claro and see if it is reproducible there.

The files were renamed from seven to claro in #3277057: Make Claro the default admin theme in Standard profile and then deleted in #3278565: Remove Claro block configuration from Standard. That is why the patch no longer applies. Is there anything more for this issue to do?

These files don't exist anymore; see #60. As far as I can tell, this issue should be closed as outdated.

Indeed, the block config has been in core/themes/claro/config/optional since #3079738: Add Claro administration theme to core. There's nothing to move. This bug has fixed itself in the intervening years...