Allow to load configuration override across all domains.

I wonder about how we might do this. We do something similar with languages.

* If a language/domain specific config exists, use it.
* Else use the domain config for all languages under that domain.

I wonder if we could just allow prefixes to ignore the domain id portion of the config.

  protected function getDomainConfigName($name, DomainInterface $domain) {
    return [
      'langcode' => 'domain.config.' . $domain->id() . '.' . $this->language->getId() . '.' . $name,
      'domain' => 'domain.config.' . $domain->id() . '.' . $name,
      'langcode-global' => 'domain.config.' . $this->language->getId() . '.' . $name,
      'global' => 'domain.config.' . $name,
    ];
  }

And then we would cascade through in that order, where now we just loop through the first two.

I don't see how this could be done without loading and iterating over the domains, and in each one, iterating through the languages.

We do this by loading the config name first and then checking to see if a matching config file exists. That is, we loop through config names, not domains. So it sounds like what you are looking to do is counter to that logic.

But I am struggling to understand the use-case here.

You want to find all the overrides for each domain -- not at runtime, but during a migration action?

I suspect that what you are doing is a special case that is better handled in the migration code (through a custom service) rather than ported back to the module.

My advice is to use a service decorator to extend / alter the domain_config.overrider service to do what you need within the context of your migration.

Otherwise, we should propose an entirely new service that we could call in order to do this type of operation, because what you are doing -- if I understand correctly -- is not what this service is built for.

In an ideal world, we would use Config Collections (#3060758: Investigate using config collections), but that is a larger task, given that the collection system is largely undocumented.

Generic issue:
I have a specific configuration X. I want to know all the domains that override that specific configuration.

Yes, this is great and very clear.

I still think that this request is totally separate from what the domain_config.overrider service is for, so this patch is not valid as written.

domain_config.overrider is an event handler, not a stand-along service. It responds to the `config.factory.override` event, which is normally part of a request bootstrap. It's also tightly coupled to the DomainNegotiator (see initiateContext()), which is request-dependent.

So the overrider service is contextual to the current request in a way that your external migration likely is not. So we would need a new service that would allow that lookup to be more efficient. In versions < Drupal 8. we did something like this inside hook_cron() to account for such use-cases, but I don't think that would work here.

The "best" way to do that is likely to refactor to use config collections, which are supposed to register overrides similar to your use-case, but I don't have time for that.

For the short term, I can see a domain.config.collection service to run this calculation for you, then cache the output for efficiency.

MR is out of date.

Nitpick: The comment "Return config overrides across all ( or ony active ) domains." has unwanted spacing around the ().

Question:

Adding the $language as an argument to getDomainConfigName() is an API change -- though so it making it public and static.

Perhaps we should make a public static wrapper that uses the new arguments without editing the existing method? At the least $language should = NULL by default?

A good test for the approach would be to rewrite the now redundant code in Drupal\domain_config_ui\Config\Config, which does this:

  /**
   * Get the domain config name.
   */
  protected function getDomainConfigName() {
    // Return selected config name.
    return $this->domainConfigUIManager->getSelectedConfigName($this->name);
  }

And that calls Drupal\domain_config_ui\DomainConfigUIManager::getSelectedConfigName

  /**
   * {@inheritdoc}
   */
  public function getSelectedConfigName($name, $omit_language = FALSE) {
    if ($domain_id = $this->getSelectedDomainId()) {
      $prefix = "domain.config.{$domain_id}.";
      if (!$omit_language && $langcode = $this->getSelectedLanguageId()) {
        $prefix .= "{$langcode}.";
      }
      return $prefix . $name;
    }
    return $name;
  }

Though that may not be worth it, since the DomainConfigUIManager uses ids and not objects.

We might have some name conflict with this issue: #3060758: Investigate using config collections

MR needs to be rebased.

Made some comments in the MR.

"We must avoid using non object-oriented code as much as possible."

Made that method public static so it can be called from everywhere.

You should avoid using the name "ConfigCollection" as it will be needed when we will switch to using the core config collections.

Comments in MR.

Have been included in the first beta release of the new Domain Extras module.

This will need an update to be compatible with the new 3.x version.

@guiu.rocafort.ferrer a new issue should be created on the Domain Extras module page where the previous MR has been merged.

Marking as "Won't fix" as it should be fixed in the Domain Extras module's code.

Just created a new 3.x development branch there.

New issue created in the Domain Extras module: #3544885: Upgrade loadAllDomainOverrides for Domain 3.x compatibility

@guiu.rocafort.ferrer could you have a look at the MR there?