I'm pretty sure it is still needed as I had to reroll it and use it - altough I'm using my own slightly expanded version of this https://git.drupalcode.org/project/drupal/-/merge_requests/1934/diffs which also covers relationships (I think, it was long time ago)... maybe the basic issue is resolved, I may test it some day.
Meanwhile, here is the patch I'm using with 10.3 (no guarantees, it simply works for me) if anyone wants to try it.
Install that module and then run update again.
composer require "drupal/jquery_ui_accordion:^2.1"
I would suggest searching exported config for format_type: accordion afterwards to see where accordion is used, change it and then get rid of jquery_ui_accordion module for good.
Can confirm both the error and the solution working.
Added removal of state after config is created. New patch attached.
Note that when domain was previously created, had configuration saved in state and then was removed, its configuration is still saved in state and will remain there as there is no longer domain by which we can find that stale state now. Not sure how to solve this.
I guess it is the same for new config approach. It will too get stale when domain is removed later, but we can resolve that one in future when moving configuration to domain.
t_d_d → made their first commit to this issue’s fork.
Updated steps to reproduce in IS with point mentioning interface language being important when trying to reproduce bug.
Still an issue on D10 (10.1.6).
Not sure if it was mentioned before but for reproducibility, in my case this bug only manifests itself when creating translation from interface language different from original node language. For example, while this /en/node/276/translations/add/en/cs works (adding translation for originally EN node from EN interface), this does not /cs/node/276/translations/add/en/cs (adding translation for originally EN node from CS interface - and this path where button to add translation uses).
I can confirm that 8.x-2.5 patched (by composer) with patch made from #42 allowed me to switch to CKEditor 5 smoothly without any problems (Drupal 9.5.11).
Patch for #42 attached if anyone needs it before this got release.
It really seems like something along #3:
composer-merge-plugin is meant for projects that cannot ship their composer.lock...
Anyway, I have just deployed on another machine and manually removing old webform module (folder) before composer install was enough for it to run smoothly. As it seems impossible to fix this, maybe we should document it on
https://www.drupal.org/node/3003140 →
like this (unless there is way to run composer install without validation of lock):
Troubleshooting
Failing composer install after webform update
If your composer install fails after webform update with libraries missing in lock file, e.g.:
Verifying lock file contents can be installed on current platform.
- Required package "xxx/yyy" is not present in the lock file.
You may need to remove old webform module (just the folder) from the target machine before running composer install. See
https://www.drupal.org/project/webform/issues/3398375
🐛
composer install - library is not present in the lock file
Active
.
t_d_d → created an issue.
Patch attached.
t_d_d → created an issue.
Applying #18 to my usecase, I found 2 bugs:
Ajax returned twice but one result had empty data. Regardless, module's JS ran twice leading to all kind of strange behavior.
It was caused by response having 2 different "insert" commands ("replaceWith" and "prepend" (probably something unique to my usecase)) and module was not checking whether the command it is altering is really "replaceWith" one, despite comment in code noticing the possibility there might be other "insert" commands.
"Load more" button was staying even though there were no more results.
It was caused by setting text for when there are no more results empty (valid option in pager settings in views). In such case, pager template does not render anything and as a result, pager is missing in new content. So far it is valid behavior, but then JS, not finding pager in new content, left old one intact.
Attached patch adds fixes to these problems on top of #18. Module now only acts upon "replaceWith" "insert" command and when text for no more results is missing, it removes the pager entirely when there are no more results.
I had same issue. Drupal 9.5.10, PHP 8.1.11. Module installed via composer and enabled with drush.
If it helps with debugging, after this happened, I uninstalled the module through UI and then enabled it through UI and it works.
t_d_d → created an issue.