Still facing this issue on 2.0.4
Still facing this issue on 2.0.4 :(
Attaching corrected patch file
Attaching patch
I am getting
Uncaught TypeError: $menu.superfish is not a function
attach http://mysite.ddev.site/modules/contrib/superfish/js/superfish.js?v=2.0:32
each jQuery
attach http://mysite.ddev.site/modules/contrib/superfish/js/superfish.js?v=2.0:21
attachBehaviors http://mysite.ddev.site/core/misc/drupal.js?v=9.5.11:24
attachBehaviors http://mysite.ddev.site/core/misc/drupal.js?v=9.5.11:21
<anonymous> http://mysite.ddev.site/core/misc/drupal.init.js?v=9.5.11:24
listener http://mysite.ddev.site/core/misc/drupal.init.js?v=9.5.11:14
Same
#21 works much better than #9 for me - I can now scroll again
magtak → created an issue.
Facing the same issue. #9 doesn't seem to affect the behaviour.
I would also like this feature. This can allow to create reusable components using Layout Paragraphs.
Example component: 3 column layout with 3 child paragraphs inside, repeated multiple places in the website, currently implemented with a "paragraph block"
Solved, the field formatter was wrong - https://www.drupal.org/project/layout_paragraphs/issues/3282541#comment-... → pointed me to the solution.
Another solution I thought of is to have 1 custom block type per desired layout, use Layout Builder and multiple paragraph fields.
For example "Two Column Paragraph Block" which uses a 2 column layout provided by Layout Builder and has 2 entity_reference_revisions (paragraphs) fields, one placed inside one column and one in the other.
Same for 3 columns, 4 columns, etc.
This is not elegant as there will be so many unnecessary entity_reference_revisions (paragraphs) fields in the end as well as many custom block types.
I second @heddn 's concern about multilingual sites.
While working on this bug I used both
- node_revision_delete and
- entity_reference_revisions (*)
... to prune both node revisions ( (*) but also "orphaned entities" that I believe do *not* get deleted when the node revision does) and it did remove revisions in a way that wouldn't make sense for the governance of multilingual sites.
I work for Acquia Support and I came across this issue while debugging a use case where all the revisionable entities (Site Studio layout_canvas entities) were set to be sequentially re-saved (Site Studio rebuild).
Looking at the query,
...LEFT OUTER JOIN "cohesion_layout_revision" "base_table_2" ON "base_table"."id" = "base_table_2"."id" AND "base_table"."revision" < "base_table_2"."revision"...
The LEFT OUTER JOIN and the '<' conditional operator will match rows proportionate to the number of revisions an ID has, this will create new rows in an exponential way.
For the case I was looking at in particular, a 10h+ operation that resulted in 1000+ second SQL queries at times which locked the revisions table and thus blocked any content editing, finished in about 35 minutes with the patch applied with barely any queries taking over 1 second. The items generating those 1000+ second queries were processed instantly.
I checked our fleet's logs and there are multiple sites impacted by this as I can see thousands of slow ( > 1s) queries generated by the code above.
Patch #133 worked for the client I was working on given their Drupal version (9.5.x).
While we will be advising clients to use patches from this thread if they encounter this issue, this fix should be high priority and should be backported to all affected Drupal branches (8, 9, 10).