This has not been implemented. In 11.1-dev, the steps still produce the result that I documented.
That said, this is no longer an issue for us as we no longer give editors the ability to set a page language, and we automatically set all new pages to English.
charles belov → created an issue.
I like Page Actions, as that most closely describes what the menu contains and will allow editors to accomplish. It says that the menu pertains to the current page and will allow you to do things with that page.
Page Tools would be my second choice.
"Quick Actions" and "Actions" don't work for me because it is not clear that they apply to the current page.
10.4.4 is available but the current version is 11.1.4 which isn't.
charles belov → created an issue.
charles belov → created an issue.
charles belov → created an issue.
charles belov → created an issue.
I can't seem to discuss the Drupal Accessibility Statement → at that page, so I'll post my comment here. I believe some of us legally need to follow WCAG 2.1. WCAG 2.2 drops Parsing, so we might need to support WCAG 2.2 plus Parsing. At the very least, I would expect Drupal and modules to not intentionally introduce parsing errors.
I am not an attorney and this is not legal advice.
charles belov → created an issue.
The search button does meet contrast on hover, but hover is not easy on mobile (I've never figured out how to do it), and requires action on the part of the site visitor. It needs to meet contrast when simply viewing the page without taking any action.
It is especially potentially annoying on Save/Preview/View Changes as they will potentially need to hover over three buttons to find the button they want or even know it exists, since it doesn't even meet 3:1 contrast. But it really needs to meet 4.5:1 contrast, since it's text.
charles belov → created an issue.
And after a meeting and then stepping away from the computer for a few minutes it hit me. "Hey, those banners for DDEV and DrupalCon probably had differently styled links below them, didn't they?" Went back, and yep, they do. So I had originally looked at three different banners which had action links and totally missed that they had links. Even the DDEV icon bleeding into the link div wasn't enough to get me to see that there was a link and not just promotional text.
Please consider changing your banner design to make it visually clear that the banner text and link are related to each other and are not unrelated pieces of content. The link as currently styledf looks more related to the breadcrumb trail, which I tend to tune out unless I need it, than to the banner text.
As a side note, it's odd that a banner about Drupal 7 end of life has a class dc-singapore-registration.
Hmmm, I find the HTML strange. The DOM copy contains:
<div class="region region-banner">
<div id="block-drupalorg-announcements" class="block block-drupalorg">
<div class="block-inner">
<div class="content">
<div class="announcement"><img class="photo" src="https://www.drupal.org/files/styles/grid-2-2x-square/public/announcements/drupal-evergreen-logo-280X280px%20%281%29_0.jpg?itok=PHpn6rCb" width="280" height="280" alt="Announcement icon" title="Announcement icon">Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our Drupal 7 End of Life resources page to review all of your options.</div>
<div class="cta"><a href="https://www.drupal.org/about/drupal-7/d7eol/migration-resource-center/enterprise" class="global-announce-banner dc-singapore-registration">Migration Resource Center</a></div> </div>
</div>
</div>
</div>where I would expect something like:
<div class="region region-banner">
<div id="block-drupalorg-announcements" class="block block-drupalorg">
<div class="block-inner">
<div class="content">
<div class="announcement"><img class="photo" src="https://www.drupal.org/files/styles/grid-2-2x-square/public/announcements/drupal-evergreen-logo-280X280px%20%281%29_0.jpg?itok=PHpn6rCb" width="280" height="280" alt="Announcement icon" title="Announcement icon">Still on Drupal 7? Security support for Drupal 7 ended on 5 January 2025. Please visit our <a href="https://www.drupal.org/about/drupal-7/d7eol/migration-resource-center/enterprise">Drupal 7 End of Life resources page</a> to review all of your options.</div>
</div>
</div>
</div>
</div>I am using Firefox on Mac with quite a few preferences overridden in both Settings and about:config. I went to Safari, Chrome, and a factory-settings Firefox to test, but I'm not getting the Drupal 7 end-of-life banner on those browsers - either getting a banner about DDEV or DrupalCon or getting redirected to new.drupal.org - so have no way to test if it's something about my Firefox installations.
(Added after previewing my post)
Oooooh! I see it. It's a usability issue for the link. I was examining the code and wondering why I wasn't seeing a link for "Migration Resource Center" on the banner.
- The link to Migration Resource Center doesn't look like a link, it looks like page content, so I tuned it out because I was trying to use the link I expected
- The words "Migration Resource Center" doesn't match the words "Drupal 7 End of Life resources page," so I didn't make the association that they were related
- It would be much more obvious and easier to succeed at if "Migration Resource Center" were removed and "Drupal 7 End of Life resources page" in context was the link, or if the link to "Migration Resource Center" appeared as a button within the white area banner area rather than as a separate div with separate styling.
So the page isn't broken, it was just too hard for me to use. (Fortunately, we're already on modern Drupal, so I didn't need the info; I was just trying to be helpful by reporting the issue.)
charles belov → created an issue.
charles belov → created an issue.
charles belov → created an issue.
charles belov → created an issue.
Would this issue properly be Closed (Won't Fix) given that Drupal 7 is end of life?
@arijit acharya Thank you for your suggestion. Again, "Contextual" strikes me a jargony and not meaningful to the average content editor. The simpler, yet meaningful, language the better. I don't think of pages as being a "context", I think of it as being the current page. I don't think of users as being a context, I think of it as being a user.
I'd really like to see something simple and straightforward like:
This page
This user
I also don't think of the various actions available as "tools."
Thank you for that suggestion. However, as with "Local Tasks," "Quick Links" does not imply it relates to the currently-displayed node.
What about "This Node"?
Although "node" is also jargony.
"This Page" if it's content?
"This User" if it's a user page?
I am QA, not a developer, so I am not able to comment on the relevance of the other issue.
I disagree that just not showing the module is an appropriate result of the version being missing from the info.yaml file for the module. I believe the correct behavior would be to show the module in the report; wherever version info was missing, the report would show "Missing" rather than a version number.
Just not showing the module at all makes the report look broken. In a long report, it could lead to incorrect assumptions about the current website.
Updating the issue description to show a new expected result.
charles belov → created an issue.
Confirmed it works, including testing adding a redirect.
I'm not sure my review is sufficient, so leaving in Needs Review.
charles belov → created an issue. See original summary → .
charles belov → created an issue.
I've reviewed the patch and the code looks good. I am running into problems figuring out how to run it in Simplytest.me, and will need to request help separately. I'll come back to this issue when I've resolved that.
Did some HTML in that last comment get rendered as HTML instead? There appears to be blank space between "necessary to add" and the period.
charles belov → created an issue.
I'll note "Suggest the minimum font size for Admin UI." might be too small for some people to read if they haven't set it. Although I realize they can use browser zoom to read it, make the setting, then reset browser zoom to actual size once they've set it.
@nayana_mvr That mock-up is exactly what I have in mind, thank you. I would be likely to use the Unreduced setting.
Actually it could be a drop-down for minimum font size:
Extra Extra Small (default)
Extra Small
Small
Unreduced
Then could the separate window could be generated from the database? The source doesn't matter; what matters is that it be the same source.
+1 for parsing the yaml tour as it ensures the steps and labels are in sync and no duplicate effort.
Hmmm, if the behavior of whether or not a new content type is automatically enabled is dependent on whether or not all existing content types are enabled...
Then is there any feedback to the administrator that this logic decision has taken place? While this may be the expected behavior, it is still easy to overlook if it is not the desired behavior for a particular content type. I recognize that the change in configuration may have occurred in code rather than through interaction with the administrative user interface. Just trying to avoid surprises.
Another use case is accessibility. Words in all caps can be misread by screen readers. Sentences in all caps also present cognitive load to some - myself included - and are also harder for people with low vision to read. Therefore, we want to be able to review all content in all caps to ensure that they are acronyms/initialisms and not words in all caps. Definitely two consecutive word units in all caps would be highly suspicious as being words in all caps.
Adding accessibility tag. While it doesn't affect Drupal's accessibility, it is a blocker to monitoring for accessibility in editor content.
I'm not sure why it would be harmful if something has been specified twice to only do it once. That said, I guess if one removes something, then one would expect it to go away, which wouldn't happen if it were specified twice.
Then I would suggest the following wording for Source editing:
This plugin adds a list of HTML tags that can be used while editing source. Remove or do not add tags that are already supported by other enabled plugins. For example, if "Bold" is enabled in the toolbar, do not add the tag. If another plugin requires a tag but does not supply it, you will need to add that tag here.
Reviewed and tested in simplytest.me, thank you!
I didn't change the status because I don't know whether my test is sufficient to be considered Reviewed and Tested by the Community.
The part above about adding "other" to the Source Editing instructions is out of date because that change has already been made to core code. It is correctly not part of the current MR.
Ah, if that comment was directed at me then I'm not going to be able to test it. I'm QA not a developer.
Agreed. This is dependent on 🐛 Add an "alt text" to tour tips describing the situation and the highlighted element Active and I'm adding it as a related issue.
charles belov → created an issue.
It would also need to be possible to add language spans if one of the accordion titles is in a different language.
charles belov → created an issue.
I am unable to test this code due to existing issues
🐛
Adding accordion to CKEditor toolbar gets error
Active
and
✨
Make CKEditor be forgiving of enabling something that's already enabled
Active
. But it seems this patch has not fully shed the <dl> tag.
Details follow:
I added CKEditor Accordion module to Drupal core in SimplyTest.me and applied this patch.
- Drupal 10.3.2
- CKEditor Accordion 2.2.0
- plus patch https://www.drupal.org/files/issues/2024-08-27/2024-08-27-ckeditor_accor... →
I believe this patch has been applied, as when I go to /admin/config/content/ckeditor-accordion I see the following setting:
Variant
Default: Default HTML structure which uses<div> <h2> <div>style tags.
Select the variant to be used.
and that is the only selection available. (Is this correct? Would I expect to see the original <dl> option? Perhaps not if it doesn't meet WCAG.)
However, when I go to /admin/config/content/formats/manage/basic_html and drag the accordion icon from Available Buttons to Active Toolbar, I get the following error:
The following tag(s) are already supported by enabled plugins and should not be added to the Source Editing "Manually editable HTML tags" field: accordion (
<dl>).
So, even though with this patch we are no longer using the <dl> tag, the CKEditor 5 module still "thinks" we are trying to use that tag.
@rkoller @smustgrave I concur. I would be unable to reproduce the issue, so I am not that one to file the second issue if there's not an easy way to reproduce on the Mac.
charles belov → created an issue. See original summary → .
Thank you.
I've viewed the reduced motion video. It went by a little fast (I wound up watching it at half speed) but I'm able to suss out some comments.
The question with reduced motion can sometimes be that there was some advantage with the motion that needs to be replaced in a safe way. Here, the point would be that with long pages, it may be hard to tell where you are on the page, and whether you went up or down to get there. This is relevant to a tour, because the visitor needs to be able to replicate the action.
While your demo video has scroll bars, and I have my scroll bars set to always on, some operating systems (in my case macOS) allow setting the scroll bars to only display when you need them. So people who have that setting may not be able to tell where the particular tour point of interest is on the page. So they trade information for safety.
I don't want to over-engineer this, but such people might need a brief arrow cue that we are going down the page. Maybe even one arrow for a short distance or three for a long distance. Maybe the arrow would fade in and out.
Please split the example video into two videos, one with motion and one with the reduce-motion setting. I didn't know what I was getting into and the motion part of the video made my eyes feel ill.
The non-motion part is likely what I'm seeking, but until my eyes calm down (and you provide a reduced-motion-only video that I can safely watch) I'm not in a position to judge.
Happy to test on simplytest.me if someone can point me to instrux and a sample tour. Not a developer here, I'm Quality Assurance.
If ability to set the link target is added, please make it configurable as to whether it is available or not, to allow setting a site policy, for example:
- Allow editors to set target
- Always set target _blank on external links
- Don't allow setting target
charles belov → created an issue.
charles belov → created an issue. See original summary → .
charles belov → created an issue.
charles belov → created an issue.
charles belov → created an issue.
Have these changes been pushed to the release version yet? I'm still getting the same results - no space between "to" and Contact even though the source code has a space between "to" and the emphasis tag - in simplytest.me using the (adjusted to reflect current behavior) steps above.