Should this have been closed as outdated?
There's still a spaceless
tag in https://git.drupalcode.org/project/flag/-/blob/8.x-4.x/templates/flag.ht..., and a scan with
Upgrade Status →
reports incompatibility with Drupal 11 in themes that have templates based on it.
See also 💬 Spaceless Tag Issue Fixed
malcomio → created an issue.
I noticed that the commonmark-external-links plugin is marked as deprecated.
This annotation was committed for #3142418: Support multiple libraries per plugin → .
I tried deleting it, and clearing the cache, but got the same error for commonmark-heading-permalink (which isn't marked as deprecated.
See also 📌 Update to jQuery UI 1.14.0 Fixed for core.
malcomio → created an issue.
I appreciate that this is likely to be a major shift in the way that the module works, and it may be more appropriate to manage this use case in a different module.
malcomio → created an issue.
Even with our patch to facets in place, we encountered this error again, although in a slightly odd scenario that came up via a penetration test, with some special characters in the URL.
Our search results page is at /search-content - the security scanner managed to trigger this exception at /search-content%22%3bexpr%20268409241%20-%2028291%3b%22?search= (and some other similar URLs).
When we apply the patch in #12, it addresses the issue.
The error mentioned in #21 seems to have been happening because we were using an incorrect patch for 🐛 Links with "Show hierarchy in dropdown" disabled gives "Deprecated function: range(): Passing null to parameter #1" Active
The Civic website links to a new module on drupal.org: https://www.drupal.org/project/civicccookiecontrol →
The issue we are seeing is addressed in 🐛 ResourceNotFoundException on 404 pages Active
malcomio → created an issue.
In our case, this seems to relate to facets, as mentioned in #20
The mention of better_exposed_filters in the stack trace isn't the root of the problem for us.
When a facets block appears on a 404 page, it causes problems with URL generation.
I think that the appropriate fix relates to one of these issues:
#3291943: When rendering facets on non search page, it throws error instead of 404 on 404 pages →
🐛
ResourceNotFoundException with ajax facets when site running in subfolder
Needs review
In \Drupal\facets\Plugin\Block\FacetBlock::build
, if we add a condition to stop the block rendering on 404 pages, the problem goes away.
@idflood, @alex.bucach, @adrianopulaz, @johan den hollander - do the stack traces you see also mention facets?
With this patch included, we observed a strange issue where BEF checkboxes showed 0 instead of the expected markup.
We ran into this problem after switching from a patched version of 2.0.x-dev at commit 3e6c1ea7 to 2.0.9.
It's an odd issue, as it only seems to happen for anonymous users without any cookies from our site, and only on our (acquia) hosting, not on local dev environments.
MR 180 doesn't seem to have any changes any more.
One thing we will try is catching the ResourceNotFoundException
and throwing a NotFoundHttpException
malcomio → made their first commit to this issue’s fork.
malcomio → created an issue.
Having tested further, it seems like the patch fixes the problem for logged-in users, but not anonymous.
We started seeing this issue recently with better_exposed_filters 6.0.6 after upgrading core
As with #15, we have an exposed search form in the header block which shows on all pages.
From our tests so far, the patch in #12 seems to fix the issue, but we will test further.
I've updated the steps to reproduce.
I wasn't able to reproduce the issue mentioned in #4, but I think the problem is that the JS adds the "form-required" class to the legend and the span inside it.
This change fixes it for me in a subtheme of adminimal_theme
Probably need to check what happens in different themes - are there some themes where the class should go on the legend?
The default behaviour for a required field seems to be that it's on the span: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/themes/claro/...
Also the logic inside that JS file isn't very clear - would be good to review in more detail.
It was added in this commit for 🐛 If target field is multiple checkbox and condition is required then all checkboxes are being required. Fixed
malcomio → made their first commit to this issue’s fork.
malcomio → made their first commit to this issue’s fork.
This seems to be very similar to #2903144: Changing frequency to daily doesn't change the sitemap view to daily →
Thanks
malcomio → made their first commit to this issue’s fork.
malcomio → created an issue.
https://git.drupalcode.org/project/redirect/-/merge_requests/117 seems to be working - please review
I think this probably comes from the changes in https://git.drupalcode.org/project/twig_svg/-/commit/b3e19eeeb641f770749... for ✨ Mechanism for including SVGs from PHP code Fixed
malcomio → created an issue.
malcomio → made their first commit to this issue’s fork.
malcomio → created an issue.
Good point - this page handles at least two use cases:
1. finding an individual term
2. changing the overall tree structure
Sorting and filtering is useful for 1, but problematic for 2
Not sure what those modules are - do you mean https://www.drupal.org/project/maillog → ?
That module seems to work fairly well - any reason not to use it?
As noted on ✨ Add filter and sort capability to taxonomy overview page Closed: duplicate , it would also be useful to allow the list to be sorted, as well as filtered.
It's very similar, although that doesn't mention sorting.
Probably makes sense to close this as a duplicate, thanks.
Possibly a duplicate of 🐛 Subformstate incorrect interface error RTBC
malcomio → created an issue.
This seems to be very similar to 🐛 Error when saving text format - configuration property id doesn't exist Active
malcomio → created an issue.
malcomio → created an issue.
malcomio → created an issue.
malcomio → created an issue.
malcomio → created an issue.
I like the suggestion in #12 of removing the html file - it's not ideal to have random example library html pages available on your website, even if they don't have malicious scripts on them
Having looked more closely at the stack trace, our case seems to be caused by an outdated custom template.
Our case should be addressed by https://git.drupalcode.org/project/better_exposed_filters/-/merge_reques... - this is attached as https://www.drupal.org/files/issues/2024-07-02/3441559-14.patch →
I don't think this should have been closed.
We're still seeing it with version 6.0.6 of the module.
The original issue references bef-nested-elements.html.twig
The patch in #2 and MR 65 alter bef-links.html.twig
I think that this relates to the changes in
📌
Remove dependency on jquery_ui_datepicker
Needs work
. where the input type is being changed from text
to date
.
If custom code adds the datepicker, this would cause the duplication.
Does it happen without any custom code applying to the form inputs?
The relevant core commit is https://git.drupalcode.org/project/drupal/-/commit/da97aa7e11e318aac1325...
malcomio → created an issue.
Thanks - we also see this issue on Acquia, so it makes sense to have this in search_api_solr_admin
We were also encountering this issue when granting permissions via update hooks.
As a workaround, we added an update hook to manually revoke the permissions:
$storage = \Drupal::entityTypeManager()->getStorage('taxonomy_vocabulary');
$vocabularies = [
'article_categories',
'codes',
'event_categories',
];
foreach ($vocabularies as $vid) {
$vocabulary = Vocabulary::load($vid);
if ($vocabulary) {
$permissions = [
"create terms in $vid",
"delete terms in $vid",
"edit terms in $vid",
];
user_role_revoke_permissions('superuser', $permissions);
$storage->delete([$vid => $vocabulary]);
}
We haven't tested the original issue since then.
Here's the commit in the 6.0.x branch - this seems to be included in release 6.0.6, although the commit message doesn't mention this issue.
Duplicate of 🐛 Metrics command generates error Fixed .
We should release a new version with this fix.
malcomio → created an issue.
malcomio → created an issue.
Updated to include fetching thumbnail, as discussed on 📌 Implement a getName method in the VideoEmbedProvider Needs review
See also 📌 Implement a getName method in the VideoEmbedProvider Needs review - it would make sense to also implement a getName method.
I'd tried to apply these changes on top of my changes there, but they conflict.
Will try to combine them when I can.
Having updated to the latest version of wse, we have been able to uninstall as expected.
malcomio → created an issue.
As mentioned in #11, the current merge request includes various other changes that don't relate to this issue.
It makes sense to keep changes limited to the issue in question, and fix coding standards issues separately.
https://git.drupalcode.org/project/views_natural_sort/-/merge_requests/13 just addresses the deprecations in src/ViewsNaturalSortService.php
malcomio → made their first commit to this issue’s fork.
I think that the relevant change is the addition of the route subscriber in https://git.drupalcode.org/project/wse/-/commit/69838e13489891a9995fe8f8...
malcomio → created an issue.
Thanks - perhaps the issue has already been fixed.
We have a commit of wse that is 2 months old, and Drupal core is on version 10.2.5.
Will test again with updates.
malcomio → created an issue.
malcomio → created an issue.
malcomio → created an issue.
malcomio → created an issue.
This limitation of workspaces isn't obvious from the documentation - I've added some info to https://www.drupal.org/docs/8/core/modules/workspace/using-workspaces →
malcomio → created an issue.
I've also encountered this issue when installing 4.2.6 via an update hook.
This seems odd, because a similar pattern can be seen in getSubscribedEvents
in lots of other modules, e.g.
https://git.drupalcode.org/project/devel/-/blob/5.x/src/EventSubscriber/...
https://git.drupalcode.org/project/feeds/-/blob/8.x-3.x/src/EventSubscri...
I realised that this belongs in drush, not core: https://github.com/drush-ops/drush/issues/5933
malcomio → created an issue.
I think that this is an instance of https://github.com/phayes/geoPHP/issues/181
Given that the composer.json for views_geojson refers to https://github.com/itamair/geoPHP, it's odd that we're getting this error, although I can see that our project declares a dependency on the phayes version directly for some reason, so maybe that's why we're seeing it.
Even if that's the reason we're seeing it, it would make sense to catch any exceptions.
malcomio → created an issue.
malcomio → created an issue.
Thanks
Thanks - the link in the issue summary responds with a 404, which suggests https://learn.microsoft.com/en-us/bing/search-apis/bing-custom-search/re...