🇭🇺Hungary @Grabby

I am getting the following also with 5.0.3 and D10.2.5 and PHP 8.2.17:

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "entity.backup_migrate_settings.canonical" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 206 of core\lib\Drupal\Core\Routing\RouteProvider.php).

I had consigned myself to living with this issue since it only affected admin users, but I confess that now that I looked at it, it was gone BEFORE applying the patch. Applying it made no difference for me. Maybe something in rc7 fixed it. Thanks for addressing the issue in any case!

Thanks for that. I did as you suggested. I created a new view mode for editable fields. Then for the two fields of interest I changed the label to “Hidden” and the format to “Editable field”. Then I went to my view and changed the Formatter to rendered entity. Unfortunately, the view mode I created was not an option. Did I mention this is for entity reference fields? My only options were for taxonomy term view modes. The weird thing is that after I changed the label to “Hidden” and the format to “Editable field” for the two fields I wanted, all my disabled fields had their format changed to “Editable field”! All except for the disabled entity reference fields, that is.

Grabby → created an issue.

Grabby → created an issue.

I am using 9.5.10 and the latest (4.2.5) version of VBO, so I’ve raised an issue in their queue and we’ll see what they say.

Grabby → created an issue.

Thanks @CKIDOW, the patch works for me, albeit not with the private file system. Small price to pay, though, for the functionality.

Thanks for the quick response. It does indeed work in Claro, but not in Gin, see attached pix.

Grabby → created an issue.

Grabby → created an issue.

Thanks @Adil_Siddiqui, patch works for me. RTBC?

Grabby → created an issue.

Thanks for your quick attention to this issue. I’m sorry to hear it is such an involved problem. I can’t help fix it, but I will do my share of testing when the time comes!

Grabby → created an issue.

I’m running D9.5.10 (PHP 8.1.21) with Laragon on a Windows box and tried #14, but I’m still getting

Warning: rename(tmp//twig/.4zqGXfPLZK7G4mnjw2abMtYMKkU,tmp//twig/64d68a2a2a255___string_template__1e7a22_5NnBESfxNIwNCEGCXhF2pxNyN/hXVFktFf4R1YIAvzgQqXtx4ksD18LS7FG6vvGU5r9og.php): Access is denied (code: 5) in Drupal\Component\PhpStorage\MTimeProtectedFastFileStorage->save() (line 105 of mysite\web\core\lib\Drupal\Component\PhpStorage\MTimeProtectedFastFileStorage.php)

In my case it’s triggered by adding or configuring blocks in layout builder.

No, running composer require drupal/slick_views:^2.8 will not produce it, but running

composer require drupal/slick_views:^2.8-rc1 does. I hacked the slick_views.info.yml file to get around it by changing

- slick:slick (>= 2.10)

to

- slick:slick (>= 2.10-rc1)

Grabby → created an issue.

I just wish I knew why it shows up in /vendor/drupal as a Nested Root.

Thanks for the quick response. I tried today’s 8.x-2.x-dev, but unfortunately there’s no change, the layout is still broken. It wouldn’t be a big deal to rebuild it, though it shouldn’t have to happen. One weird thing is Blazy now doesn’t show up on the Available updates page. It’s there – composer show says * 2.x-dev, * dev-2.x – and it’s enabled, but for some reason it isn’t listed on Available updates. The necessary db update said something about entity reference formatting, which is interesting because one of my other problems is that I have an EVA view that I can’t get any Gridstack layouts to display. They display with all the standard layout builder and Bootstrap layouts, but not with Gridstack. Just mentioning.

Grabby → created an issue.

Grabby → created an issue.

I can confirm that I’m using 2.2.7.

Grabby → created an issue.

Grabby → created an issue.

For reasons unrelated to Webform I switched branches in my workflow to one where Webform was not installed yet, then installed it, imported my form config from the first branch, and the problem went away, though my new filter.format.webform_default.yml file had no role delimiter. I manually added the role delimiter as shown in your yml file and everything is still good, so not sure what happened initially, but you can mark this issue closed. Thanks for your help!

I’m running 9.5.9 and have CKEditor 5 enabled. I am also using CKEditor Font Size and Family → .

Not sure what I should have updated since it’s a fresh installation of 6.2.0-beta5. All the files listed in the link are in my exported configuration.

Thank you for the suggestion. I checked the ‘HTML Editor Settings’ and both ‘Element text format’ and ‘Mail text format’ were set to default. I tried checking ‘Disable HTML editor’ and now was allowed to change the message boxes. I tried re-enabling ‘HTML Editor Settings’ and I got back to where I started, not able to edit the messages. Then I changed the settings from default to ‘Full HTML’, then ‘Restricted HTML’, then ‘Basic HTML’, and finally ‘Plain text’. Those all worked. When I changed back to ‘Default’ I again got the message that I had insufficient permissions to edit it, so the only setting that didn’t work was ‘Default’!

Grabby → created an issue.

I would like to change font family and size on a node-by-node basis using Drupal’s built-in CKEditor 5, I am not using DXPR Builder. The font size dropdown would be adequate for my purposes, but it behaves erratically. If I, say, change just the font size from “default” to “huge” there is no change, but if I change the font family from, say, “default” to “Tahoma” AND the size from “default” to “huge”, then there is at least a change. Other changes are similarly haphazard.

Grabby → created an issue.

My use case for this doesn’t depend on any correlation between edit form layout and content layout, but simply presenting a coherent looking edit form. I am working on a project with 30+ fields of all kinds on many content types and having them all stack in a column on the left with labels above the fields is far from ideal. So I’m with #3. I personally think the lack of edit layout capability for the most basic Drupal entity, the node, is the most glaring hole in the Drupal ecosystem at present.

You are correct, after emptying all the cache tables in the database there is no error.

Grabby → created an issue.

I appreciate the hard work going into the rewrite. That said, it seems to me that a module concerned with deleting revisions would be at least as concerned with the maximum retained as with the minimum. For my part I use the module to keep revisions to the bare minimum possible since I don’t need them on some projects. Not sure if this amounts to a feature request and, if so, whether it should be a separate issue, but I would really like to be able to specify the MAXIMUM number of revisions to keep, with as few as one possible. Thanks again for all the effort!