🇵🇱Poland @besek

besek → created an issue.

@iro, thanks for checking!

The reason why there are two headers is caused by the fact that we are using "group by column" option and default Drupal behavior is to add separate header to every group created this way. Please see how it looks on Claro: claro_views_groupped_table.png →

However, sticky header on Claro works bit better, because it is moving only within one table and when it reaches the top of the screen, second header becomes sticky - all of them are working only within own table. While in Gin, the header that becomes sticky is always the first header from the first table and it travels through all of the page, creating an effect of duplicated headers from time to time. The other implication is that if tables has different width of the columns, this first header that became sticky is not aligned with the columns on nect tables.

So, in my opinion, the original bug here has been fixed (as sticky header is not covering group headers anymore), however there is still issue with how sticky headers are working in Gin. But it would probably require separate issue? I'm happy to report separate issue on this, unless anybody feels different?

But isn't it reasonable that you have option to unlock the content you are editing? It's almost like a "cancel edit button". The problem wold be if you want to break someone elses lock. And than permission would be needed.
But I don't think this change is needed as you should be able to unlock the content you just locked.

The patch from #3 works fine. Thanks @amitnar. Would you create MR?

I ran into the same issue. For me it happend after I deleted on fo the fields that was using field_permissions. Field was deleted from db, but permissions stayed un user.role.*.yml file. In effect, any other changes to the permissions of other fields, resulted in this error.

It looks like we need to make sure user.role.*.yml files are updated when entity or fields is deleted.

Manual fix from #11 worked fine for me

We should remember that this is not only Drupal automated updates but all processes that might be used for upgrading the website, that are impacted here. Considering changing in the versioning requires a lot of effort and also, probably shouldn't be done to already existing versions, maybe at least update of the release notes for version 2.2.0 https://www.drupal.org/project/honeypot/releases/2.2.0 → can be done to help people who may run into this issue?

besek → created an issue.

besek → created an issue.

besek → created an issue.

The patch works fine, it would be great to see this released :)

besek → created an issue.

Guys, in my case this issue occured in the views where I was trying to use one of the fields in the title of the view. For example, view title was:

Revisions list: {{ ['field_publication-revision_id'] }}

After removing token from title, view started to work again. I'm not sure if it's just about the title or other places where tokens are used in the view.

I'm assuming the way of using the token in the title was incorrect. I was trying to find out what could cause the issue and I'm wondering isn't it because of the fix in:
https://www.drupal.org/project/drupal/issues/2684251 🐛 Global Token Replacements is not working correctly in href Fixed

I understand these information might be incorrect or incomplete, but maybe my case would provide some help to others who have similair issue?

I've tested this on D10.3.2 and branch 2.0.x with a patch and it works really well. We have lot of legacy content with this problem and previously we were using this module with CKEditor 4. Now, with this patch it works great with CKEditor 5.
Thank you!
+1 for release

In my opinion, the reason for a new major version is exactly what was described by TR: 2.2.0 is not recommended version. Without it, composer would update to 2.2.0 and Drupal will be listing the module on the /admin/reports/updates/update list.
What's more - platforms like Pantheon, that has built-in automated process for update will fail on this and it will require manual updates to one version and next one after that.
And website owners would have to define version in composer.json to prevent the upgrade from hapening, if the newest version is not the one that is recommended.
Also, solution from #6 is a workaround but it causes that PROD upgrade would have to be split into two releases. Woth the major version it also would be two releases, but at least there wouldn't be automatic jump between versions.
And, BTW, some people read all release notes - for example I did. And I didn't see a warning that this update should be done version by version :)

So, as you said TR - it is not in scope of this module to change the way how composer or Drupal updates work, but I think the way how module is released should consider how composer works (even if we think it is not perfect).

Hi @dqd,

let me be more precise here: it is about any layout, built with layout builder. Whenever I would create new page in page manager (using layout builder) or content (of any content type) built with layout builder, the issue occurs.
I hope this helps?

Ok, thanks for clarification and the patch. I was testing mr on rc11 and it worked fine, so I thought this would be enough to use it as a patch.

@DuaelFr, there are small differences between your patch and what is in mr. Can you please clarify them? I'm wondering what is the goaald and which one should be used for patching RC11 on my website

I didn't check with Inline Entity Form, but just in case I tested compatibility with other modules, where it could potentially impact behaviour:
- Views Bulk Operations
- Views Entity Form Field
- Dashboards with Layout Builder
All of them seems to be working fine, with or without this patch :)

Just tested in linked issue. I think this one can be closed as Duplicate?

Thank you @hundri! I've verified your fix and it works very well!

I have the same issue :(
I was trying to disable this new feature (which is great, if it would work on modal forms) by disabling option "Enable sticky action buttons" in Gin settings. However disabling this option didn't change anything.
For now, only option I found to make those modal forms work was downgrading gin to RC10

Thanks @CRZDEV
Patch from #7 🐛 Declaration of Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend::__sleep() must be compatible Active works well. Although its name is bit confusing, because it suggests patch is form search_api_solr, while it is for search_api :)

After upgrade of Search API to 8.x-1.35 I could get everything to work correctly after applying two patches:
https://www.drupal.org/project/search_api_solr/issues/3449292 🐛 Fatal error Declaration of Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend::__sleep() Fixed for Search API SOLR
https://www.drupal.org/project/search_api/issues/3454939#comment-15642321 🐛 Declaration of Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend::__sleep() must be compatible Active for Search API

Looks like both modules needs to be released to have those issues covered in Drupal<11

I had the same issue and I've installed patch from https://www.drupal.org/project/search_api_solr/issues/3449292 🐛 Fatal error Declaration of Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend::__sleep() Fixed
After installing patch, the error changed to:

PHP Fatal error:  Declaration of Drupal\Core\DependencyInjection\DependencySerializationTrait::__wakeup() must be compatible with Drupal\search_api\Backend\BackendPluginBase::__wakeup(): void in /var/www/html/web/core/lib/Drupal/Core/DependencyInjection/DependencySerializationTrait.php on line 74

Fatal error: Declaration of Drupal\Core\DependencyInjection\DependencySerializationTrait::__wakeup() must be compatible with Drupal\search_api\Backend\BackendPluginBase::__wakeup(): void in /var/www/html/web/core/lib/Drupal/Core/DependencyInjection/DependencySerializationTrait.php on line 74

besek → created an issue.

#6 works fine with D 10.2.6 and beta10.
The only potential issue I see here is that it doesn't check the content workflow permissions and even if current user doesn't have permission to keep node in current state, it allows them to do it.
I guess it is ok, as long as it is know to the users?

I hope it will be included in the release soon! :) Thanks @sokru

I can confirm, I also had this issue because of the patch from 🐛 Fix PHP 8.2+ deprecation notices Closed: duplicate . Removal of this patch solved the problem.

I've tested patch #17 on Drupal 10.2.6 with Views Data Export 8.x-1.4 and it works really nice, thanks @erom.

I can confirm, patch from #4 works perfect, thanks!

I'm using this module on Drupal 10.2.5 and it works fine.
@marcoka if, in your case, it works on one site, but it doesn't on another, you should check if any other modules or configuration are causing conflict. And maybe than provide more info for this ticket

I'm using patch #5 with Drupal 10.2.4 and it works fine. It is not causing any issues while editing nodes with workflow

besek → created an issue.

@gilbertdelyon please check workaround I suggested here: https://www.drupal.org/project/media_library_edit/issues/3264180#comment... ✨ Enable Media Edit with inline media entities within text fields using CKEditor WYSIWYG Active

I also think it would be good feature, otherwise it's hard to explain content editors that they need to go somewhere else to edit image.
In the meantime I'm using "Media Library Edit" module together with https://www.drupal.org/project/edit_media_modal → . Both modules work fine together, although it would make much more sense to have both features in one module :)

I had the same issue and from solutions in #21 only disabling cache had positive effect. Patch from "nojs"/"ajax" route parameter in use-ajax link breaks CSRF protection 🐛 "nojs"/"ajax" route parameter in use-ajax link breaks CSRF protection Needs work unfortunately didn't help

@occupant, thanks, I've tested it and it really looks like it if working well now. Thank you!

Thanks @yan solution #43 really helped!

Ok, so as weird as it might be - I didn't have this issue on Drupal 9, but after the upgrade to Drupal 10, I have exactly the same issue as kriboogh.

Thanks _tarik_, it worked!

Thanks _tarik_, your solution worked for me well!
I bumped into another problem when this started to work: https://www.drupal.org/project/draggableviews/issues/3408185 🐛 Save order button removed if bulk operations in view (by claro) Active , but I think it actually is a seperate issue

I have the same issue, using Gin theme (button to Saver order is not removed, however is inactive until any item on the list is selected)

#15 works like a charm, thanks!

besek → created an issue.

besek → created an issue.

Thanks for the answer. I was testing on:

• Drupal 9.5.11
• Gin 8.x-1.0-rc4
• maxlength v2.1.2
• CKEditor5 Fullscreen v1.0.0-beta5

I've noticed some time ago, weird behaviour of maxlength. The counter is, as you described, right below the textarea when I'm creating new node. And fullscreen button works fine. However, when I save node and edit it again, the counter from maxlength is above the textarea and at this moment, fullscreen button is not working anymore.

I'm not sure why maxlength div is displayed in two different places, but I hope this description would help you to verify if this conflict should be resolved in CKEditor5 Fullscreen module?

Thanks!

besek → created an issue.

besek → created an issue.

Thanks @zanvidmar. Workaround sugested by you is less ugly than patch I used :)

besek → made their first commit to this issue’s fork.

besek → created an issue.

besek → created an issue.

I had the same issues, with very similar steps to reproduce as described in #5 🐛 Ajax error on views with aggregation Postponed: needs info .
Patch from #2 🐛 Ajax error on views with aggregation Postponed: needs info wroked well for me.

I think I got the same problem. Applying coupon from the promotion didn't change the total price in order checkout form. However, the new price was visible after page refresh.

Ok, this is actually correct. I thought it was working in Drupal 7 by default, but I've realised that I was actually using module https://www.drupal.org/project/wysiwyg_linebreaks → (currently supporting D9, but not CKEditor 5)

Thanks for explanation!

#80 worked for me, however it saevd node title as image alt. I think it should be configurable so you can choose what values you want to save in title and alt fields of the image. Thanks

besek → created an issue.

besek → created an issue.

besek → created an issue.

I'm sending extremly simple and temporary patch for those fields. It's not final solution of course, it is workaround if someone lost upload fields
https://www.drupal.org/files/issues/2023-07-04/simpleads-disapearing_fie... →

besek → created an issue.

besek → created an issue.

This fix from Tamper module:
https://www.drupal.org/project/tamper/issues/3119301 ✨ Skip tamper if item is empty Fixed
might be good solution. It provides new tamper "Skip tampers on empty". I've added this tamper to every field that I'm trying to manipulate and it works fine

Ok, I actually just resolved my issue: it was caused by empty line in my MYTHEME.theme file. But it might be also another file in theme. It's worth to verify if it's somewhere in the theme by switching to default theme and checking if error still occurs. I'm leaving it here, as it may help somebody.

Anyone found solution of this issue? I have the same problem and can't find what is causing it

I honestly don't know if it is thanks to the version 2.1.2 or Drupal core upgrade, but DraggableViews for custom blocks is now working for me.

besek → created an issue.

besek → created an issue.