Hi spuky, this happens with just core views and Easy Breadcrumbs.
With a view title set to a replacement token like {{ name }}, the title is set correctly, but the breadcrumb will be {{ Name }} (autocapitalised).
For the moment we're just replacing {{ Name }} with a generic title that works for the one view where this is an issue, but it would be good to have it pull the same title as the view.
Can confirm that we encounterd this issue (in our case, an at the start of a header) and the commit in the MR (1c95fbbb) resolved the issue.
We didn't experience the problem Matthew reported in the MR comment.
Thanks Scott, that does solve our immediate issue.
As it doesn't look like this is going to be implemented upstream in the near future, is anyone aware of a workaround to force this behaviour, if you're happy to take a scorched earth approach to attributes on elements?
We've got clients trying to paste in a lot of documents from Word, and the "remove formatting" button only stripping styles from inline elements tends to leave the document with a broken mix of styling, mostly relating to sizing and spacing. Stripping styles after the fact in the filter prevents intentional styling and makes the editing experience very inconsistent when they're still visible within the editor.
Can confirm that is working here.
A fix for this issue has now been merged into CKEditor's master branch.
Can also confirm that the MR resolves the errors for us, with no obvious side effects.
Hephaestus → created an issue.
We're encountering the same issue when using image_effect → 's EXIF auto-orient feature on image styles. When opening a node with a large number of images attached, PEL will quickly run out of memory. Specifically due to the transformDimensions call it makes, which tries to get the EXIF data from file_mdm.
Hi couloir007, did you find a solution or workaround to this? We're in the same position where the only reliable link between thousands of existing Drupal accounts and the IdP are the email addresses.
Hi Wim, I can confirm that the private files migration works correctly through the AM:A UI, it's only when using drush ama:import that it fails with this error.
Thanks!
Hephaestus → created an issue.
Thanks for the quick reply Spokje, your mention of the contrib modules prompted me to take a deeper look. The only one referencing MenuActiveTrail is gin_toolbar which extends it with the Drupal\gin_toolbar\Menu\GinToolbarActiveTrail class. It doesn't override the constructor, and the service definition is:
services:
gin_toolbar.active_trail:
class: Drupal\gin_toolbar\Menu\GinToolbarActiveTrail
parent: menu.active_trail
Uninstalling Gin Toolbar and re-adding the lazy: true configuration for MenuActiveTrail results in the site working properly, so the issue seems to reside there.
I will re-open this issue on the Gin queue.
This change appears to be causing the issue discussed in 🐛 MenuActiveTrail ($menu_link_manager) must be of type Menu\MenuLinkManagerInterface, DependencyInjection\Container given Active after upgrading to 10.2.0-beta1.
Hephaestus → created an issue.
Hephaestus → created an issue.