@jmsomera MR has been updated.
Could you give it another try?
mably → changed the visibility of the branch 3552189-webform-integration-2 to hidden.
Your wish is my command. - Claude
Could you have a look at this issue's MR please?
And you can use the Asset Injector → module if you do not have access to the backend.
Released in <a href="https://www.drupal.org/project/domain_theme_switch/releases/3.0.0-alpha3">3.0.0-alpha3</a>.
FYI we are only deleting the successfully migrated configuration overrides.
We have the same problem when saving Domain overrides.
What is the best way to handle it?
Looks like the warning is still present when using the Domain module 3.x.
Couldn't it rather be done using a hook_entity_translation_create ?
Unless new, valuable information is provided, this issue will be closed in 3 months.
Problem has been identified : in our case the view configuration had been synchronized back to its old state after running the update hook.
The solution : simply run the update hook again using the Devel PHP module for example.
$module = 'domain_access';
$path = \Drupal::service('extension.list.module')->getPath($module);
include_once DRUPAL_ROOT . '/' . $path . '/' . $module . '.install';
domain_access_update_10001();
Or you can execute this code in Devel PHP and run update.php again:
\Drupal::keyValue('system.schema')->set('domain_access', 10000);
Other solution: recreate the domain access filter in your view.
Looks like I have been able to reproduce it on one of my sites.
Investigating.
The class is stil referenced in the PublicationDateItem field type class.
This feature should probably be refactored in a dedicated submodule.
Not sure to understand what this MR is doing exactly.
The removed line was added in this commit: https://git.drupalcode.org/project/publication_date/-/commit/304fd3d7d51...
For a particular reason I guess.
If no reproducible scenario is provided, I’ll close this issue in 3 months.
If no reproducible scenario is provided, I’ll close this issue in 3 months.
Hi @4kant, it looks like we have found another edge case that is not covered by our functional tests.
Can you give a full reproducible scenario on a fresh Drupal 11 install please?
Let's still hope that #3202329: Outbound path processors miss the route name and parameters lands in core soon!
That would definitely bring a significant performance improvement when using the domain source path processor.
Let's merge this for now.