🇬🇷Greece @magtak

Account created on 2 February 2012, almost 13 years ago
  • Client Advisor at Acquia 
#

Recent comments

🇬🇷Greece magtak

Still facing this issue on 2.0.4 :(

🇬🇷Greece magtak

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
🇬🇷Greece magtak

#21 works much better than #9 for me - I can now scroll again

🇬🇷Greece magtak

Facing the same issue. #9 doesn't seem to affect the behaviour.

🇬🇷Greece magtak

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"

🇬🇷Greece magtak

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.

🇬🇷Greece magtak

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.

🇬🇷Greece magtak

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).

Production build 0.71.5 2024