We're seeing the same issue. It doesn't actually cause a problem unless PHP has the display_errors option switched on.
Here the problem is caused by having both an Entity Browser field and a core Media Library field on the same form. When trying to remove an item from the media widget, the Entity Browser code is getting confused because the button for core Media Library is also called remove_button
Attaching patch which checks the field name on the triggering element matches the expected one for this widget. This allows both the media library and entity browser to function correctly again here.
@itamair Yes! Tested on the site we originally saw the problem on, and new patch #49 resolves the issue.
To elaborate on the #44 issue - the regression we're seeing in Localgov Drupal after this change is because it no longer falls back to the default Views getValue() if it *is* a SearchApiResultRow but doesn't have a usable corresponding field.
I don't have the why on this part, but on this view the $real_geofield_name comes back with `location` but there's no such field in the result row. (There is a `localgov_location` field, but that returns a simple lat/long rather than a POINT(), so doesn't work here either...)
The attached patch adds the fallback behaviour back in and fixes the issue for me.
Previous patch allowed the views to render again, but breaks as soon as you try to apply a facet...
New patch attached, based on changes for same problem fixed in main Facets project.
grahamC → created an issue.
I have this issue too on a customer site recently upgraded from 9.5 to 10.2.
In the error 'Cannot read properties of undefined', the undefined is the off-canvas wrapper element ([data-off-canvas-main-canvas])
That element was entirely missing for me... It's supposed to be put in place by a #theme_wrapper (see system_element_info_alter()) but somehow another module's theme_wrapper is preventing the off-canvas one from running...
The offending module for me is
Responsive and off-canvas menu →
- and commenting out the responsive_menu_preprocess_html() function fixes the issue here.
@flefle - do you have this module also?
The code that causes the problem is essentially as below:
hook_preprocess_html(&$vars) {
$vars['page']['#theme_wrappers'][] = 'responsive_menu_page_wrapper';
}
I can't yet understand what's wrong with adding a theme wrapper like this and why it causes the one from `system` to go missing, though...
As a potential solution, merge request !368 introduces a heuristic that if "Back to site" would land on an "admin" path, it should instead be replaced with a link to the front page.
grahamC → created an issue.
@webflow
I understand where you're coming from, but considering the current state of the main openid_connect project, ditching 1.x seems a little premature...
openid_connect 2.x (currently "beta") has no Drupal 10 release either, so you're effectively requiring people to upgrade to the alpha-quality 3.x branch to use this module.
I was just about to attach the same patch against 1.4 as #7 but was beaten to it. Works fine from my (limited) testing with just the change to the info.yml file.
One major Drupal 10 issue the automated patch has missed:
The module makes use of Internet Explorer conditional comments to include a particular javascript library. As this functionality has now been removed from Drupal ( change record → ) the JS is rendered without comments and runs in modern browsers too, causing weird AJAX errors in unrelated modules.
Updated patch simply removes the problem script, because who needs IE9 support?