Drupal Version
Drupal 11.1
Domain module version
2.0.x-dev
Expected Behavior
Create domain specific configurations only when the corresponding config form path has been explicitly allowed.
Actual Behavior
We can see that the ConfigFactory doGet method returns a domain specific editable configuration even for configuration like core.extension 😱
Steps to reproduce
Looks like having activated the "Remember domain selection" in the domain configuration UI settings keeps the current selected domain in session and this might cause a few problems as we can see below.
/**
* {@inheritdoc}
*/
protected function doGet($name, $immutable = TRUE) {
// If config for 'all' domains or immutable then don't override config.
if (is_null($this->domainConfigUIManager->getSelectedDomainId())) {
return parent::doGet($name, $immutable);
}
Once the "Remembered" domain is kept in session we never get into the above code to return without instantiating a domain specific configuration.
/**
* {@inheritdoc}
*/
public function getSelectedDomainId() {
$id = NULL;
$request = $this->getRequest();
if (!is_null($request)) {
$id = $this->currentRequest->get('domain_config_ui_domain') ?? NULL;
}
if (is_null($id) && isset($_SESSION['domain_config_ui_domain'])) {
$id = $_SESSION['domain_config_ui_domain'];
}
return $id;
}
Every configuration is now being duplicated as a domain specific version when updated as long as we have that domain_config_ui_domain in session.
May be I broke something in some custom personal code, but if so, I haven't found where yet.
Issue fork domain-3513800
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3513800-all-configurations-are
changes, plain diff MR !138
- 3513800-tests
changes, plain diff MR !140
Comments
Comment #2
mably commentedComment #3
mably commentedComment #5
mably commentedHad to create two new services with lazy loading to avoid being hit by a circular dependency error.
New code instantiate domain specific editable configuration object only if we are on one of the allowed registered paths.
Comment #6
mably commentedComment #7
mably commentedComment #8
mably commentedSome unit tests are failing :(
Comment #9
mably commentedAll tests are passing again.
Comment #10
mably commentedComment #12
mably commentedMR 140 contains only 3 tests that are currently failing with 2.0.x version.
The related problems have been fixed in MR 138.
Comment #14
mably commentedComment #16
driskell commented@mably Since this code merged to beta3 we're seeing site information and any other configuration not loading on the frontend for the domain. It always loads the default configuration.
It looks to hit this line:
https://git.drupalcode.org/project/domain/-/blob/2.0.0-beta3/domain_conf...
But immutable is always TRUE when loading configuration. So it never loads any domain overrides.
Comment #17
mably commentedLooks like a regression to me :(
Will have to look at it.
Comment #18
mably commentedProbably not a domain_config_ui module problem as the default config override per domain is done by the DomainConfigOverrider class. The ConfigFactory class is only used when editing a custom configuration per domain.