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).
Thanks for creating this issue and providing a patch, @landsman.
The patch provided in #3 may well solve the requirement in your particular case, but I don't think it would be appropriate to add a target="_blank" to all file links for all Drupal users.
To answer the question posed in this issue title, my guess is that there are several ways to achieve the required functionality. For example, you could copy file-link.html.twig to your custom theme and add a link attribute as follows:
<span{{ attributes }}>{{ icon }} {{ link|merge({'#attributes': {'target': '_blank'}}) }}</span>
This should open all file links in your frontend theme in a new tab. Hope this helps.
I'm changing the category for this issue to support request and marking it as closed for now. If anyone wants to discuss further, or knows a better/different approach to achieve the OP's objective, feel free to add your comments below.
Thank you for everything you've done for Drupal and the community, Angie!
Don't be a stranger!
The Commerce Core project page features the Centarro logo, as they are the supporting organisation:
I guess we could use it for project Browser too if we can get a hold of a slightly larger PNG (max 512x512 and 10KB).
Adding credit to the designer of the original logo (@lostcarpark).
Here's a logo proposal:
PNG of 512x512 pixels at 80% quality (~7KB)
The logo shown on the Upgrade Status project page looks great.
Here's an optimized PNG of 512x512 pixels at 70% (~8KB):
(Adding this to the issue summary as a proposal too.)
Amber Himes Matz → credited tinto → .
Interesting! The only related chromium bug I could find is this one: https://bugs.chromium.org/p/chromium/issues/detail?id=1090500. It was fixed almost three years ago and does not seem to cover our issue 100%.
One of the comments suggests limiting the whitespace by using margin-inline-start: 0 on the calendar picker pseudo element. Setting this value to zero does not fix our issue, but setting a negative value does. It renders pretty much the same result as #29.
My proposal is to set a negative margin of 0.875em (14/16), so that it plays well in case the font-size is overridden for some reason. So looking at the current code, I would add this to /core/themes/claro/css/components/form--text.css:
.form-element--type-date::-webkit-calendar-picker-indicator {
margin-inline-start: -0.875em;
}
If we can get consensus that this is the best possible fix, I can write a small patch.
@bnjmnm: should we still open up a new issue for Chromium and add a comment in the patch that refers to that issue?
Applying a negative margin proposed in #29 does seem to do the trick. And I agree it's a better solution than increasing the min-width to an arbitrary value.
Either way, I'm not really sure how I feel about having to solve what is basically a bug/quirk in Chrome. Are we okay with solving it this way - and perhaps having to roll back this styling if one day Chromium does fix this on their end?
P.S. Here's a codepen to test this outside of Drupal: https://codepen.io/Tinto/pen/XWxZGOx.
Re #29: I do see the problem in Firefox (v112 on MacOS) too, albeit slightly more subtle. See the screenshot comparison in #34 and the issue summary.
Cleaning up the issue summary by removing some irrelevant info and adding steps to reproduce, proposed solutions and other relevant info.
Hope this makes it somewhat easier for others/maintainers to review this issue.
Thank you @apaderno!
Despite RSS already validating (#1), we fixed the remaining recommendations (except one, which is caused by this open Drupal core issue 🐛 Views RSS feeds have validation issues Needs work ).
Are there any remaining actions needed from our end?
fathima.asmat → credited tinto → .
I agree: #7 may be somewhat unrelated (and might merit a separate issue). Sorry for the confusion.
@msn5158, the trouble here is to determine if this is a core bug or if it is caused by one of the 4 contrib modules needed to reproduce this. In order to move forward here, we need to find the culprit so we can pinpoint which part of the code is causing this. At this point I have no clue where to even start looking.
Do you see any possibility of somehow reproducing this issue without the contrib modules - or perhaps with different contrib modules? Perhaps output the view block directly in a twig template to see if that works?
Thank you for looking into this, @BhumikaVarshney! For the record, this is not "my" issue, but I am merely trying to determine if this is really a bug by trying to reproduce what @StryKaizer described in the original issue summary. I can confirm that I have the same outcome, so I posted clear(er) steps to reproduce this behavior.
The issue is not because menus have parent items have the same link the parent link is not visible because the "Initial visibility level" is set to 3 as per your steps.
If we set the initial visibility to the 3rd level the menu will automatically render the 3rd child directly.
In an attempt to further illustrate the concern of the OP, I just extended my test menu so it looks as follows:
- Link to Node 1
- - Another link to Node 1
- - - Link to Node 2
- - - Link to Node 3
- Link to Node 4
- - Link to Node 5
- - - Link to Node 6
With the settings described above, the menu block does appear when you visit any link on level 2 or level 3 except for /node/1. I believe the OP expects to see the menu appear when visiting /node/1 too.
The next step is to determine if this is actually a bug, or if this is intended behavior. In case of the latter, this issue can be marked as "works as designed". If it turns out to be a bug, we need a patch to resolve it.
P.S. The issue status Needs review → is used when a patch has been created that needs review and testing.
P.S. The steps to reproduce could do with some improvements.
Step 3 mentions "duplicate the view", but it should duplicate the view display. Also, when duplicating the view display, I get Error message: Display "Entity Reference" needs a selected search fields to work properly. See the settings for the Entity Reference list format.. This seems like a crucial step to add IMO.
I tried to reproduce this issue on a fresh install of Drupal 9.5.8-dev, but cannot seem to get the same results in the frontend.
However, I do see this issue appearing in the preview section of the Views UI. The block display of my "test" view has a pager, whereas the entity reference display does not:
You do not need to install any contrib modules to reproduce this outcome.
We have a few more articles ready to be published, but we would like this issue to be resolved first so that we are sure they'll get picked up by the Planet feed.
Article was not tagged correctly. Should appear in the feed now.
Thanks for reviewing!
In the meantime, we'll take a look at the validator warnings mentioned in #2.
That's odd. Latest article is from March 10, but is somehow not showing up in the RSS feed.
I will look into it and report back here when we fix it.
I no longer see that deprecation error when I upgrade to 6.0.x-dev, so I'm assuming you've already fixed it in this branch? :)
Wow, that's fast! Thanks @nathaniel!
I've tested patch #2 on a fresh Drupal install - both on my local machine and on a new Pantheon site - and it seems to work like a charm on both sites. Here's the combination of modules/versions that I used:
- Drupal 9.5.4
- Album Photos 6.0.x-dev
- Plupload 2.0@beta
- Patch from #2 →
- (our custom workaround module for the plupload file extension error)
The file-mapping setting is missing from your code.
Try this:
"drupal-scaffold": {
"locations": {
"web-root": "web/"
},
"file-mapping": {
"[web-root]/robots.txt": {
"append": "assets/my-robots-additions.txt"
}
}
}Some code refactoring in core/lib/Drupal/Core/Render/Element/HtmlTag.php and fixing automated test fails.
This patch simply changes the closing tag for void elements from /> to > on line 91 of core/lib/Drupal/Core/Render/Element/HtmlTag.php.
Updating the issue summary with steps to reproduce, including a screenshot of the menu settings.
Triaging this issue as part of the Bug Smash Initiative → .
I've tested this on a fresh install of Drupal 9.5.x-dev and can confirm that the behavior described in the issue summary still occurs.
🐛 There is a shift in the views grid Closed: works as designed
Thank you @Kristen Pol for triaging this one earlier!
I think the OP expects the (frontpage) view to take up more width. Instead, the first child div of div.view-id-frontpage has grid-column: 1 / 9; applied to it, so it takes up only 9 grid columns instead of the expected 12.
The cause is that there are layout helper classes applied to the view (and region) template, that manipulate the width of child elements.
@zenimagine, have a look at views-view--frontpage.html.twig for example, where you can see that the class layout--pass--content-narrow is applied.
I'm gonna go ahead and close this issue, as it works as intended. Thank you all for contributing!
larowlan → credited tinto → .
Triaging this issue as part of the Bug Smash Initiative.
I've tried to reproduce the issue as described in the issue summary on a fresh install of Drupal 10.1.x-dev and Claro enabled as backend theme as default. When I install the module mentioned above, enable it, add a user (with a very long username) and go to /node/add/article, I do not experience this issue:
Is this still an issue for anyone? This was posted almost a year ago, so the cause might have been solved in the meantime. Or perhaps there are additional steps needed for this issue to occur. If so, please update the issue summary with the necessary steps to reproduce this behavior so we can try to find a fix.
If no additional information is added in the next 3 to 6 months, this issue may be closed. Thank you!
Thanks for reporting this issue! I'm triaging this issue as part of the Bug Smash Initiative → .
I've installed a fresh install of Drupal 10.1.0-dev on my local machine. With Claro enabled as the backend theme by default, I've tried to reproduce the issue as described in the title and shown in the attached video. However, when I visit /admin/modules and hover any of the many disabled checkboxes there, they seem to work fine.
Are there any additional steps needed for this issue to occur? If so, please update the issue summary with some clear steps to reproduce → (starting with "Install Drupal version 10.x.x") so we can examine this behaviour further in order to find a fix.
If no additional information is added in the next 3 to 6 months, this issue may be closed. Thank you!