I did manage to reproduce this problem in an older version of Drupal (10.3.6), but in current versions (10.5-dev and 11.2-dev) this issue no longer seems to occur. Therefore I am marking this issue as Closed (outdated).
If anyone is able to reproduce this issue in a current version of Drupal, please provide (additional) steps to reproduce and mark this issue as Active.
Thanks everyone for your time and effort!
borisson_ → credited tinto → .
I've created a MR that applies the patch in #26 (after checking: issue still exists, patch still applies, patch fixes the issue).
Can anybody please confirm that this needs test coverage? I cannot find any existing tests that verify if the expand functionality works for normal links, so it seems a bit odd to write a test only for <nolink> items. Thanks!
Rebased to 11.x
Greetings from the contrib room at Drupal Developer Days 2025 in Leuven, Belgium.
The reason I posted this here is because if it's currently not possible, I would like to turn this into a feature request.
Oops.
I think we can mark this one as fixed.
Could someone please credit @richo_au for updating the event page? Cheers!
I think this is a duplicate of 📌 Add speakers to Drupal event page Active .
To me it seems odd that the spacing relies on a (campaign?) banner.
Wouldn't it make more sense to add bottom margin/padding to div#page (or a top margin/padding to div#footer) instead?
While I'm typing this comment I notice that this very page does have spacing between footer and content, and it is attached to div#content-bottom-region by this css:
.page-inner > * {
margin-bottom: 2em;
}
So now I'm confused how some pages don't seem to have this margin.
@akmalfikri: which url did you use for your screenshot in #11?
Thank you everybody involved in organizing this contribution event for Drupal Malaysia!
Closing this issue and looking forward to the next one! :)
Thanks for reporting this! I agree, Drupal.org cannot afford to be walking around like this:
Furthermore:
- Not entirely sure, but looking at the releases/branches this should go in the 1.x branch
- Adding some extra information to the issue summary
- Reducing the image size in the issue summary somewhat
- Adding some context about the Drupal Malaysia first-time contributors workshop
Nice work everyone! Happy to see this moving forward.
Perhaps nitpicking on my part, but do we need to address the suggestion mentioned in #39?
apply a fix with a @todo pointing to the browser issue and instructing to remove the fix when that issue is addressed
I think the ZT Gatha font shouldn't be used for headers. It's difficult to read and the kerning / spacing looks off.
It's probably fine to use for the Drupal logo, but for anything else I would avoid it.
I've been looking for something like this many times. Even a primer with some general examples would be very helpful to so many users.
Revisited this issue during the DrupalCon Singapore 2024 Contrib Day.
It's been 6 months after the last update, and 2 years since the OP's last follow-up. Also, we are still unable to determine if this is a Drupal core problem or that one of the contrib modules is causing the issue, as there are no clear instructions to reproduce the issue without any additional contrib modules.
Taking the above into account, I'm going to mark this issue as Closed (cannot reproduce).
If anyone feels this is still an issue, please provide clear steps to reproduce in a clean Drupal 11 install - without any contrib modules installed - so we can further investigate.
Thank you @msn5158 and others for the time and effort you put into this!
I'm running into the same problem here.
Running composer require drupal/embedded_content_examples only alters my composer.json and .lock, but does not actually add the code to the contrib module directory.
Instead, running composer require 'drupal/embedded_content_examples-embedded_content_examples:^2.0' does install the examples module properly. But the namespace looks like it needs to be fixed.
Marking this as a duplicate of [3362224].
Here's the preview for "core-commerce-3" (#31)
Thank you @itamair for the new release(s)!
P.S. Would you mind granting credits to those who contributed to solving this issue? Thank you!
Thanks again for the swift response guys!
I agree with #14. There are valid points in #13, but considering this is a security issue, I think for now it's best to limit the scope (and time needed) and simply replace the malicious/untrustworthy url.
Removing the polyfill library altogether warrants a separate issue IMO.
Reuploading the patch, in case anyone needs it. It seems #3 was deleted by mistake. :)
The webform module has the exact same issue 🐛 polyfill.io Library is no longer considered safe to use Fixed . They're solving it by replacing the suspicious url.
Here's a patch.
I've tried (again) to isolate/reproduce the problem on a clean Drupal (9.5.11) install with only the Antibot and Cookiebot modules enabled, but I was unsuccessful.
The issue does still persist in several different client sites, but I cannot figure out what combination of modules and settings is causing this. In my case(s) it seems Cookiebot is blocking the Antibot script that should replace action="/antibot" with action="/user/login" in the form element, until the user agrees to all cookies and reloads the page. I'm seeing the problem in all forms that have Antibot protection applied.
Question to others who see this issue: does this problem still persist when you disable Automatically block all cookies in /admin/config/cookiebot?
I was seeing the same problem as #12, running test on my local machine with Drupal 11.x-dev.
I fixed it by implementing the workaround posted in #13 - I simply replaced line 15 in config.selenium-standalone-chrome.yaml to this:
- MINK_DRIVER_ARGS_WEBDRIVER=[\"chrome\", {\"browserName\":\"chrome\",\"w3c\":false,\"goog:chromeOptions\":{\"args\":[\"--disable-gpu\",\"--headless\", \"--no-sandbox\", \"--disable-dev-shm-usage\"]}}, \"http://selenium-chrome:4444/wd/hub\"]
Thank you @AndyF!
There are no errors in my console:
I only see blocked cookies, which makes sense because Cookiebot is doing what it's supposed to do.
Not sure oif this problem is Gin-related. We don't use any Gin-related themes or modules but are still experiencing this issue on multiple websites.
We're experiencing similar problems in several sites here (D9.5.11). We've pinned it down to a combination Antibot → and Cookiebot → . We've been using Antibot without any problems for years, but recently replaced EU Cookie Compliance → banner with Cookiebot and that's when we started having problems logging in.
The problem disappears when we remove the user/login form from the Antibot protection settings, but that is obviously not an ideal workaround.
If a user accepts all cookies (in the Cookiebot banner), logging in is not a problem. If the user denies or does not click anything in the Cookiebot banner, the login form submission fails with the error stated in #35.
Thanks for the patch, Juanjol. However, this issue was marked Closed (duplicate).
I suggest we continue to discuss/work in [1388926], starting with the discussion about how we can improve the issue by dividing the work needed into seperate issues with a smaller scope.
I wasn't aware there was already an issue covering this. Thank you for bringing it to our attention, #8.
I will go ahead and mark this issue as duplicate of 🐛 Change to use Config Translation for More label Postponed .
Thanks everyone!
I've seen this problem on one of our client sites too. Perhaps @Mschudders and I could compare a list of contrib modules installed so we can cross-check?
Same (or similar) problem here, although the results on D10 and D9.5 differ.
Steps to recreate:
- Install Drupal, webform and config_view
- Enable only webform in /admin/structure/views/settings/config_view
- Create a new view of type 'webforms'
On Drupal 10.1.0-dev with config_view 9.0.2:
Internal server error (500) WSOD
On Drupal 9.5.2-dev with config_view 9.0.2:
Warning: Undefined array key "entity revision" in Drupal\views\Plugin\views\query\QueryPluginBase->getEntityTableInfo() (line 288 of core/modules/views/src/Plugin/views/query/QueryPluginBase.php).
The view is created, but every time I save the view, this warning is triggered.
Super minor, but here's a patch.
Copying my two logo proposals for this module here - previously uploaded them in a duplicate issue: [3298507]
Thanks for noticing that, @lostcarpark. I guess I missed the other issue.
I will go ahead and mark this one as duplicate and copy my work over to the other issue so nothing is lost.
Oops, I uploaded the non-compressed version of the second option in #5. Here's the correct file.
Here are two alternative options:
Thank you for the quick review, @lostcarpark. I've applied your feedback and created an improved version:
PNG (optimized with tinypng.com), 7.06KB, 512x512px, transparency preserved
I like this, but I would prefer to keep it simple and only feature the word "Slick", without the arrows and dots.
I agree with #2 that it's usually best to use the actual logo from the module if it already exists.
Having said that, I like #3 (second image) better and it looks great in the preview in #7. However, it looks very similar to the search results on Flaticon.com when searching "image crop". Can we confirm that it has been created from scratch? If not, are we sure we are allowed to use it without getting into any legal trouble?
I like the second one from #1, but not too sure if the logo should include "SVG".
#4 would have my preference, but I would love to see it in action in James' famous PB preview templates first.
Here's a logo proposal for Views Bulk Operations:
PNG, 7.44KB, 512x512px, transparency preserved
Moving this one to RTBC
I think I still like #11 the most, as it shares a similar style with the logo proposals for the other Commerce-related modules by @dandolorian.
Thanks for the great work everyone!
I like #5, because I prefer to see all the Commerce-related (sub)modules have logos in similar style. Great work @dandolorian!
#3 for me too. Thanks everyone!
Another vote for #6 from me. Let's move this one to RTBC. Great work everyone!
Great work on #4. Moving this to RTBC.
#10 looks great!
Is the background color the same as the darkest blue of the official Drupal logo? If so, very nice touch! :)
Thanks for the quick review @smustgrave!
Can verify it now says "undo", maybe should be "Undo removal"
I briefly discussed this with @lendude and @laurii during DrupalDevDays last week. Possible candidates were: "Undo", "Undo remove", "Restore", "Cancel", "Undelete" or possible even remove the link altogether, forcing users to cancel the form to undo their changes. We agreed that "Undo" was the best option for now, as it was short and concise, with the assumption that "users would understand". But this is definitely up for debate afaik.
Also the css opacity doesn't seem to take affect
The opacity change is part of views_ui.admin.css (part of the core views_ui module), but Claro does not load it and instead applies its own specific styling for Views UI. So I reckoned that the changes for Claro warrant a separate follow-up issue once the work in this one passes all the quality checks.
For now, the changes in #21 are best tested with Stark enabled as backend theme. I will add this info the IS.
Fixing for a new test that snuck in while I wasn't paying attention:
1) Drupal\Tests\views_ui\FunctionalJavascript\FieldDialogsTest::testRemoveFieldHandler
Failed asserting that true is false.
Test expects the Remove link to disappear after clicking it, which is no longer true.
- Altering the CSS somewhat so that it also applies to the Views UI rearrange filters dialog
- Removing the last 2 steps of
testOperatorLabels()inFilterCriteriaTest.php, because they expected the last row to disappear, which is no longer the case.
Removing a weird whitespace caused by a seemingly accidental </p><p> in the middle of a sentence.
Oops, forgot to include the changes in the accompanying .pcss.
Tests fail, because in the filter rearrange dialog screen, a removed filter now no longer completely disappears, but instead it is (visually) marked for removal. Hence, JS tests checking the last or penultimate row no longer give the same results and should be altered.
Also, the changes in CSS do not apply to the filter rearrange dialog rows, as it has its own css class.
I'd be happy to (co)review them. Feel free to ping me (@Tinto) in the #project-browser channel on Drupal Slack if you need an extra pair if eyes.
#21 (and #22) looks fine to me. Moving this to rtbc!
Thank you @dandolorian! I think that looks great.
Dimensions and file size also in accordance with requirements, so that's a double thumbs up from me.
Fix for mistake in css comment in #17
Some JS refactoring
Here's a first attempt at a patch. Probably won't pass the tests, but it seems to work fine (with Stark enabled as backend theme).
Claro doesn't load views_ui.admin.css so styling will not be visible there. We probably need a follow-up issue there to achieve what is depicted in #14.
Briefly discussed this with @longwave and @laurii during Drupal Dev Days 2023 and decided to mark 📌 Remove trailing slashes on void elements Closed: duplicate as duplicate. I'm copying the work that I did there over to this issue.
It's probably still worth waiting for 🐛 Upgrade filter system to HTML5 Fixed to get in first.
I was about to reroll #6, but after discussing briefly with @laurii and @longwave, I've decided to mark this issue as duplicate of 📌 Remove all references to "self-closing" void elements in core Needs work . The work done in that issue probably covers all void elements everywhere, including the code covered here.
Let's continue the work there!
🐛 Wrong path alias (for Views pages) with case-sensitve (system) paths Closed: outdated
Triaging this issue as part of the Bug Smash Initiaitive during Drupal Developer Days 2023 in Vienna.
Thanks to the clear steps to reproduce this issue, I managed to test this on a fresh install of Drupal 11.x-dev and can confirm that this is no longer an issue.
I've created a new view with two page displays, with paths /test and /Test. After creating a path alias for each (/my-test-view and /my-Test-view, I checked the views overview page and the "View page" links on both page displays. All links are using the path alias urls.
My guess is that this has been fixed in another issue, so I am marking this one as Closed (outdated).
Good point @johnpicozzi!
I think this one looks great:
Question: should the logo feature this version of the druplicon or a more generic/simple drop? Not sure whether this version is associated with a specific version of Drupal or not.
Here's a patch that adds a few lines to core/themes/claro/css/components/views-ui.css.
Applying the patch posted here seems to create another issue: the "Remove" links no longer properly align with the table column header.
This is because the patch hides the input element, but not the wrapper div.
I think this can only be fixed in the (admin) theme, so I will open a separate follow-up issue that addresses this.
Thanks for the review!
It's important to take into account when reviewing is that when you disable JavaScript in your browser, the checkboxes should be visible. When JS is enabled, they should be (visually) hidden.
Hi everyone, thanks for the patches and proposed solutions! Great to see so many people working on this.
I've reviewed and discussed this with @lendude and @finne and we've found a few issues with #6 and #9. I think a better way to solve this is to simply add a js-hide class to the input element by the views ui module. This way it works in all themes and the checkboxes are only hidden when JavaScript is enabled.
Please review the patch attached. Thanks again!
Applying Claro's styling from disabled blocks to Views UI would look like this:
Sorry to dig up this very old feature request, but this issue came up when discussing another Views UI issue during Drupal Developer Days 2023 in Vienna. And I (still) agree with the OP in that this would be a very nice enhancement of the Views UI.
1. Similar to what happens when you rearrange a field, a removed field should be highlighted in yellow
I'm not sure if I'm a huge fan of this. I would opt for a bit more distinction between rearranged and deleted items.
Taking a queue from Claro in the blocks layout screen, when you disable a block, a class is applied that subtly changes the row's background color and decreases the opacity:
.block-disabled:not(:hover) {
opacity: 0.675;
background: #fcfcfa;
}
This seems to do the trick visually already.
I'm wondering how to implement this though. Perhaps Views UI could provide a marked-for-removal class, but it would be up to the (admin) themes to attach the styling rules. So it sounds like this feature could need some coordination between views ui and theme maintainers.
smustgrave → credited tinto → .
Removing a few empty table rows and changing status (no review needed).