And is now included in the new D11 release.
Feel free to create a new issue for this please. A new version supporting D11 was just released.
This was just merged. Thank you!
I've merged only what the Automated Project Update Bot did, not sure why the other commits were done. I will test this with Drupal 11 and if all works fine I will tag a new release.
hchonov → changed the visibility of the branch project-update-bot-only to active.
hchonov → changed the visibility of the branch project-update-bot-only to hidden.
hchonov → changed the visibility of the branch project-update-bot-only to hidden.
hchonov → changed the visibility of the branch project-update-bot-only to active.
hchonov → changed the visibility of the branch project-update-bot-only to active.
Could you please elaborate on how this can be reproduced? In this function apparently we are running into an autosave submission, but the autosave submit element is not there, which does not seem right.
Thank you. This is now merged.
Actually I've just discovered that an existing search page config in the system is even missing the uuid and this is still breaking for me when saving as a config entity. This is what the config_plus module was created initially for to prevent from configs in the system without uuids. It turns out this config has the issue. Further it is not even possible to set the update due to core checking for the uuid changing ignoring the fact that it might not be there at all. I am just including a quick fix in here and we can discuss how to proceed.
I am not really sure why config factory instead of the config entity API was used here to create new entities, but this is not the right way. The config_plus → modules catches such issues and throws errors, which is how I've found out about this. Maybe I am missing something or should I open a new issue to fix this?
Our use case is like this that we have a content type that is not translatable, but the site has multiple languages enabled without language detection enabled and it is possible to create content in that content type for different languages. However since pathauto automatically creates the aliases with the language of the entity if we would create content in a non-default site language then we cannot visit the url of the page. I think that we need an approach similar to 🐛 If you don't want to translate your URL alias, the original URL alias won't work with your translations Needs work that will set the language to undefined in case the entity is not translatable. The only issue I can think of is though what should happen if the content type is made translatable at a later point, so this needs to be defined and tested how the aliases old and new will behave.
This was just merged. Thank you!
This was already resolved in another issue.
This was just merged. Thank you!
This was already fixed.
Thank you. This was just merged.
hchonov → made their first commit to this issue’s fork.
This is now fixed.
The method in the MR needs also to be implemented properly and not to be left with a simple TODO :).
effulgentsia → credited hchonov → .
I've just merged this one into 2.x.
valthebald → credited hchonov → .
valthebald → credited hchonov → .
Thanks for the remainder, @BramDriesen :)
Thank you. This will be part of the 1.6 release.
Does the layout builder use a dedicated operation as well? I mean can we fix it in a similar way as it was done here - 🐛 Stop triggering autosave on delete forms Fixed ?
Merged. Thank you. This will be part of the 1.6 release.
Merged. Thank you. This will be part of the 1.6 release.
The patch here fixes the issue for me where when accessing the page with a bad / wrong query parameter for the contextual filter with cold caches the page gets cached without the view and then accessing the page again without any query parameter returns again the page without the view instead of showing the view with all available filters.
I can only confirm the issue as it happened to me as well.
I've noticed there were still a lot of duplicates in the queue, so adding a condition to not create a queue item if the same one already exists in the queue.
Re-roll.
LGTM
Not sure if this caused the problem, but updating from 1.9.2 to 1.9.3 broke our Google tracking and we had to revert back to 1.9.2.
This breaks the loading of GTM when both usercentrics and simpleklaro are installed, but simple klaro is not enabled. Could we please add a check to ensure that Klaro is enabled and only then run the hooks?
Whoever comes across this but does not use custom code - the issue in the facets module has been fixed here - https://www.drupal.org/project/facets/issues/3367124 🐛 Drupal 10: InputBag::get() may no longer return an array in Symfony 6 Fixed
hchonov → created an issue.
Committed to 2.x. Thank you all!
Opened a new major branch 2.x where I will push this patch.
This should fix the failing test as now it is expected that the library is loaded on new entity forms.
Re #3186353-14: Image effect to crop by aspect ratio only →
This removes the 'arbitrary aspect ratio' feature. Don't know if this is a required feature for this functionality.
yes, it is a required since this is the main idea of the image effect - to crop by aspect ratio.
This is ready to be committed. Please create a new major dev release. Since there are some test failures that do not seem to be caused by the D10 update of the module we would need a new issue to tackle them. Also I closed as duplicate 📌 Drupal 10 compatibility Needs review so please give credits to the people that worked on the issue over there.
I am closing this in favor of the one where more people worked on but with a note over there that credits are given to the folks that used to work here too.
The real issue here is that _webform_update_html_editor() is using the config storage directly to write the config and thus leaving the config without an UUID. We identified this since we use the
config_plus →
module that has a protection against saving configs without an UUID. The UUID is being added to an entity only when using the entity storage to save the entity. Therefore we should not be using the config storage here to create config entities but rather the config entity storage. I am attaching a patch that properly installs the config entities.
Re-rolled for 1.1.x
I have responded to the issue. Please note that the 2.x is still in development. I will be happy for having co-maintainers on the 2.x branch if you would like to actively work on the development of the module for the planned features and help with test coverage so that we get out of alpha.
The current patch is altering in which language the entity is being loaded as snapshot in conflict_entity_load(). The cause is to be searched at the place that is using it and not loading it. This is only covering up the bug that might come up at a harder place to search for later. So please check about the usages of $entity->{EntityConflictHandlerInterface::CONFLICT_ENTITY_ORIGINAL}. If we would accept the current change then $entity->language() and $entity->{EntityConflictHandlerInterface::CONFLICT_ENTITY_ORIGINAL}->language() will return a different language which would be inconsistent.
Thank you!
FYI this was a BC break and a new major release should have been created.
Actually ✨ Remove PHP8.2 Deprecation Fixed was not fixed properly and now we get this error
Plugin "config_patch_output_text" (Drupal\config_patch\Plugin\config_patch\output\Text) must implement interface Drupal\config_patch\Plugin\config_patch\{out
put}\{Output}PluginInterface.because before the curly brace we have a slash so we need to escape the curly brace.
Attaching a patch fixing the issue.
oups sorry, I did not see that this was already fixed.
The patch had only one small issue with a double dollar sign. I fixed it and I feel comfortable RTBCing this small issue.
Re-roll for 10.1.x
Re-roll for 10.1.x
a.dmitriiev → credited hchonov → .
But this issue shouldn't be occurring after https://www.drupal.org/node/3292540 → or am I missing something here?
hchonov → created an issue.
Just a re-roll for 2.x.