The <legend>Behaviour as parent</legend> inside the Navigation block is coming from our own module. It's an optional element for the fieldset, and a combination that is being used elsewhere as well. Presence of a should not cause this issue. In 1.x this was working perfectly, before this change was introduced. I can confirm the issue is present in both 2.0.x and 1.0.x branches.
Yes, wherever we use the same combination it's broken, only tested on 2.0.x.
This issue introduced a regression on vertical tabs form when element is in place over the fieldsets.
Implemented the proposed solution, ready for review.
I have to agree with you on this. I will try to discover the possibility of creating a new context.
Based on the split-preview module example, I added an html preprocess to completely remove the admin toolbar from rendering preventing the following issue:
The responsive preview iframe is loading the translated page, but the toolbar inside the iframe is making AJAX requests with a cache token that was generated for the original page context. When the iframe loads a different language variant, the CSRF token becomes invalid.
Updated the automated tests to account for this.
Added the missing part in the 10.5.x patch.
public function getPendingUpdateFunctions() { ...
return $this->alterAvailableUpdateFunctions($not_executed_update_functions);
Fixed the patch for 10.5.x.
@nicxvan Our use case that requires this is the following:
We have an install profile and we need to make sure, that all dependent components/modules run their post_update functions before the install profile post updates, hence why the existing solutions are not enough, like it is described in the issue description.
In the patch made for 10.5.x in comment #27 I realized that one function call is missing and the feature doesn't work as expected. Uploading the correct patch.
Rerolled patch over 10.5.x.
Patch for 10.5.x version of core.
Rerolled over 11.x.
joevagyok → made their first commit to this issue’s fork.
Thank you for the fast resolution!
Clearing the local cache to invalidate it and prevent access denied error due to mismatch of langcodes is not a viable option.
Latest release containing this is causing fatal error:
Error: Call to a member function label() on null in Drupal\entity_browser\Plugin\views\field\SelectForm->viewsForm() (line 129 of /var/www/html/build/modules/contrib/entity_browser/src/Plugin/views/field/SelectForm.php).
We should not assume the presence of _entity over there.
Re-roll over latest 8.x-2.x.
Released in 3.1.3 and 2.1.6 versions.
Thank you everyone!
There are consistent failures over the 2.x branch: https://git.drupalcode.org/issue/responsive_preview-3541821/-/pipelines/...
joevagyok → created an issue.
Please open an MR to have automated tests running over the changes.
joevagyok → created an issue.
Dropping D9 in a minor release, is fine. We should maintain Drupal releases up until their EOL. Based on the discussion in the MR, I would suggest adapting the core version constraints to ^10.1 || ^11 and making sure we have these respective builds in gitlab CI, which we do, by looking into the green pipeline.
joevagyok → created an issue.
Closing as duplicate.
Thank you for the report and the fix!
Thanks for the report!
joevagyok → made their first commit to this issue’s fork.
@vladimiraus I am not sure if the new issue is really necessary. This issue is perfectly describes the problem. I think a new MR would be sufficient, but I can create a new issue if you insist.
joevagyok → made their first commit to this issue’s fork.
I think it would be very useful to have actual clickable actions under /admin/content/shorthand table besides "Update story", like "Delete story" and "Delete story versions" that would take you to a confirmation page where you can select with checkboxes the version the user wish to delete.
Changed the approach to check for default_formatter key in the definition before we render any field relying over that.
Adding patch file for composer.
joevagyok → created an issue.
Rebased the content of the previous MR and opened a new MR against 3.x since I was unable to change the target branch to 3.x.
Re-rolled the patch from #18 over the latest 3.0.0-alpha3 release.
I re-rolled the contents of the MR over the 11.2.x branch. Currently fails to apply over 11.2 release.
Merged, thank you all!
Good work! Thank you everyone.
Sadly, we decided to pursue a different path in our project. I withdraw my proposal and closing this issue.
Tested, works well now. Thank you!
Thanks for reporting the issue and looking into it with a proposed solution. Tests are failing, so some more work is needed.
joevagyok → created an issue.
Thanks for the report on that! I opened a new MR with the fix.
Thanks for the work!
joevagyok → created an issue.
joevagyok → created an issue.
Thanks for the review comments. The MR is in a work in progress.
joevagyok → made their first commit to this issue’s fork.
Anyhow, rebased the MR over 8.x-2.x.
I think this issue should be closed in favour of Drush 13 update where Drush 12 should be the minimum version required. https://www.drupal.org/project/extra_field/issues/3511072 📌 Drush 13 compatibility Active
joevagyok → made their first commit to this issue’s fork.
The MR had missing pieces from the patch, I pushed it.
I attached a patch file for composer patching against 1.19 version.
joevagyok → made their first commit to this issue’s fork.
Thank you all!