Problem with saving configs correctly between themes and blocks on specific domains

Well, as you already know and described: Domain settings are based on paths you choose where the Domain settings should be taken into account. You set it up under admin/config/domain/config-ui. This makes the select domain drop-down showing up on the respective path and makes Domain scalable without over-floating the whole admin UI with domain options, if only parts are required to be domain aware.

But your report is somewhat confusing: From my understanding you have tried to achieve domain specific block layout settings, but you are expecting saved changes not under the admin/structure/block path but under admin/appearance in the domain config list? Maybe this indicates a drawback in domains path attempt. Let me explain:

The problem with the path based settings attempt of Domain is that paths like admin/structure/block a) does not lead to a concrete configuration endpoint and is actually a path alias to the default themes block layout edit page, while choosing a non default activated theme there would lead to admin/structure/block/list/themename then, and b) is the depending theme you want to layout maybe not available for that domain. The block layout part of core have hold long discussions and many different opinions how to solve all challenges back in the days and still has conceptual things to be opinionated. The admin path was one of it. Apart from that you would maybe need to add every sub path like admin/structure/block/list/claro to the domain config. Which means there is possibly no way to "enable" block settings "as a whole or own domain specific setting" because of the mentioned theme context. Not sure yet.

But apart from that: Would you mind to edit your issue summary to make sure that there is no logical misunderstanding caused by reading it and could you please shorten the title for better readability? Thanks for taking the time to report.

> From my understanding you have tried to achieve domain specific block layout settings

No, it is the theme setting admin/appearance in the domain config list that we are trying to configure for the specific domain configs. I'll update the summary. I've attached the urls in our config in case maybe I'm misunderstanding further.

I am aware admin/structure/block doesn't lead to the same path because we are also seeing some weird behavior there where if we don't switch back to "All domains" and then uncheck "Remember domain selection" then we will see the name of the main tab theme on admin/structure/block say it's using "theme 2" but then in the "demonstrate block region (theme 1)" and all configure/edit blocks urls point to theme 1. Another file attached of what that looks like.

We do have a workaround which is currently:

1. Check "Remember domain selection"
2. Change the theme for a specific domain
3. Select "All Domains" for the theme after changing for specific domain
4. Uncheck "Remember domain selection"
5. Keep an eye on any new entries in /admin/config/domain/config-ui/list for a little bit. delete if found.

Thanks for the efforts to elaborate more on your issue. I am not sure how experienced you are with "Drupal-isms" and how things sometimes work directly OOTB and sometimes not.

I am still not sure yet if this actually is a support request how to set up Domain (I still cannot reproduce it from the description 100%) You repeatly try to change block settings but describe a way where you change the domain on admin/appearance beforehand. This is what I was referring to previously. The tricky thing at UX - even often underestimated by developers - is, that users expect very different things when looking on UI. And the Drupal admin UI went thru a huge overhaul and is still in progress to try to be even more intuitive in the future (where people argue if it gets to the better, other story). Finally I tend to say: complex tools have the habitat to have complex challenges in using them. And complex stands for powerful.

To show you my confusion at one example: In the original issue summary you stated that you were going to admin/appearance to change domain and then to admin/structure/block to change blocks. Now you say:

No, it is the theme setting admin/appearance in the domain config list that we are trying to configure for the specific domain configs.

Which is tricky in terms to understand what the user expects. Because I immediately thought: ok, so why the user was going to appearance first then? Since in Drupal you always change blocks for a specific theme. So if you want to change blocks for a theme for one domain, it is one single setting for Domain (only if you have enabled the theme for this domain of course): It is the settings of blocks on that theme but only on that domain then, if configured correctly. This can become confusing in mind. This is why I need to elaborate on your expectations. These block settings only appear on that domain then, yes, but only if this domain runs this theme, which is another setting. Do you understand? This way one theme can have 2 different block settings for 2 different domains but also can have to different themes for two different domains with the same block settings if you want so. And each of them can be registered for another domain with even other block settings. What I try to say is: what you finally did is not a work around, it is actually what you need to do to make sure that your settings are nested in each other in the correct way like you need it. Changing a theme for a domain requires to go to admin/appearance, choosing the domain and then changing the theme. To change block settings for a theme you go to admin/structure/block/list/themename change the domain there and then change the block settings. It feels complicated yes, and we all try to minimize such experience as much as possible for users, but it should not happen to the extend of loosing flexibility and power of the tool. This is always the borderline we fight in Drupal contribution.

By the way: Well this title is not really shorter now. :) let me try one.

To be fair, we're fairly new to drupal so there may be something I'm missing but it also feels like you're still missing what I'm saying and we're still just misunderstanding each other.

To change block settings for a theme you go to admin/structure/block/list/themename change the domain there and then change the block settings

We don't want this. Please consider this one of our biggest misunderstandings.

I only want the theme and theme settings saved for the domain per the path list I attached. Here it is again for reference. These are all paths that are enabled via the UI so there wasn't anything manually added in here. This works and saves Saved Configurations correctly: system.site, system.theme, system.theme.global.

• /admin/config/system/site-information
• /admin/appearance/settings/swift
• /admin/appearance/settings/pathways
• /admin/appearance/settings/collection
• /admin/appearance/settings
• /admin/appearance

Changing a theme for a domain requires to go to admin/appearance, choosing the domain and then changing the theme

I don't disagree, but you are missing the other steps we have to do: 1, 3, 4, 5 in the workaround. Even with this workaround, we've had an asset injector file end up in Saved Configurations causing the issue which is why 5 is there.

so why the user was going to appearance first then?

So, we discovered this problem by changing the theme for a specific domain. Selecting "Set as Default".

As I kept going, I found it was when I did a specific action that caused the issue. That specific action is

1. when I have "Remember domain selection" on
2. select a new domain on admin/appearance (which causes the reload)
3. turn "Remember domain selection" off
4. going anywhere else in admin and saving a setting

BUT it also happens when (so this would be why a user goes to appearance, to change the theme)

1. I have "Remember domain selection" on
2. select a new domain on admin/appearance (which causes the reload)
3. set a different theme as default for specific domain
4. turn "Remember domain selection" off
5. going anywhere else in admin and saving a setting

After the setting is saved, this is where the block.block.*, assetinjector.css.*, views.*, groups.* is being added to Saved Configurations. We are not expecting this.

Block, Views, Groups and Asset Injector are all items that showed up in Saved Configurations, which is most of what we are working in.

Well I just try to help you in my free time and since you mentioned the block settings page previously (and still in the summary) we are not talking about a misunderstanding. I hope you see where I come from. I think it already helps you to clarify your own report that we discuss here when I ask and tackle it down with you.

but it also feels like you're still missing what I'm saying

The opposite is the case. I carefully read what you are saying/writing. And I carefully ask and explain that there are many ways to achieve things in Drupal and this is why some details of your report can be interpreted different ways. It all helps you and others who want to chime in and help.

I don't disagree, but you are missing the other steps we have to do: 1, 3, 4, 5 in the workaround.

I do not miss these steps. I know how to set up Domain ;-) I just wanted to help and make clear that special step in case you do not know how it works. As I sad: user expectations how things "should" work are very different.

Even with this workaround, we've had an asset injector file end up in Saved Configurations causing the issue which is why 5 is there.

Which indicates that you probably do not know how it works. This is why I try to help. This happens when you forget to switch off "Remember domain" and edit some other configs in the meantime. We use Domain in many projects and none of the misbehavior on save happens to us.

I just wanted to be kind and help and additionally I try to keep the issue queue clean because Drupal and contrib modules is community work. For many of us volunteer work. So feel free to ask questions how to do things. I hope I was able to help but I have to leave for now.

Since you are new to Drupal let me "welcome you" officially *wave* and let me encourage you to try more. I know it can be irritating in between but you will be satisfied after a while. Hope it helps.

Okay, I see. Maybe we missed, unchecking the "Remember domain selection" button when we get configurations in other domains.

Isn't it a multi-user issue though? i.e. if "Remember domain selection" is meant as a GLOBAL config setting, is it global for the user? or global for Drupal?

So if I come in and we need to spin up a new domain and with a specific theme, I need to kick everyone out while I do that or else we end up with split configuration. So every domain specific site change will require everyone to stop what they are working on.

attached failure verification as proof of the test actually working before adding the fix back in.