#Usability

Thank you @dev.drupal.ln & @batigolix for picking up and working on the issue, and apologies for the late reply, i am quite behind on going through all the a11y issues across issue queues that received attention recently. :( Todays a11y meeting was a timely and necessary reminder. So I went ahead and have taken a look at MR93 - a few observations:

1) The styling of the filter field needs some work - in general for Claro the design should orient to the Drupal Design System, for Gin I am not aware of any Figma file. Problem with the current state of the MR, the border has a color contrast of 1.2:1 rgb(235, 235, 235)/rgb(255, 255, 255) in Claro and Gin which is not in line with WCAG 2.2 SC1.4.11.
claro

gin

For Claro the border color should be var(--input-border-color) and on hover var(--input--hover-border-color), the border should be solid and the size var(--input-border-size). The filter field in Claro has a height of 48px (the min-height property for that is calc(((var(--input-padding-vertical) + var(--input-border-size)) * 2) + var(--input-line-height))).
For Gin the border color should be var(--gin-border-color-form-element) and on hover var(--gin-color-text) (checked the filter field on admin/content for the variable on hover), the border should be solid, the size is 1px, and the corners should be rounded.
The filter field in Gin has a height of 40px (the min-height property has calc(var(--input-padding-vertical) * 2 + var(--input-line-height)). There might be more styling details for Claro and Gin to mind, the variables provided for Gin are only for the light mode, they might vary for the dark mode.

2) The input field is missing a label (WCAG 2.2 SC 3.3.2)

3) The filter field is missing an outline when being in focus (WCAG 2.2. SC 2.4.7 & SC 1.4.11)

4) If you are entering a term to filter for into the filter field the list underneath is immediately updated accordingly. This would happen to non-sighted users unexpectedly, which is not in line with WCAG 2.2. 3.2.2. In project browser ( 🐛 Improve the accessibility of the search field Active ) we’ve applied the following approach, we’ve added a search button (for the token module the button could be labeled Filter analogous), and the user can either press enter within the filter field or tab to the filter button and then filter. That way the user is in control.

5) If a user wants to clear the input of the filter field they have to use the back space button. If someone assumes pressing the ESC key would clear the field that closes the token dialog instead. It might be worth to consider to again apply the same approach that is used for project browser and currently proposed for the field ui ✨ Add a clear button to the fields ui Active , that way the behavior would become consistent across Core.

6)

If you click on a token in the list, it will populate the last field that had focus. With this change, the last field will become the new token filter field.

this behavior is problematic. That way a keyboard user has no way to accomplish their key task, inserting a token into a field in the background of the token dialog.

7) the hierarchical list becomes hard to read after you have filtered for a string. the treetable is already hard to comprehend in the unfiltered form, but if you enter something into the filter field (for example user), you dont have a top level element as the first element but one that is from the second or third level (the exact level is impossible to assess)

8) Looking at the treeTable problem, that reminds me to the more fundamental question, about how to proceed - there is 📌 Token UI 2.0 Active about Token UI 2.0. It is the question what would be the best approach for the Token UI going forward.

• Should there be a fundamentally different UI and all other issues postponed until a consensus is reached on Token UI 2.0?
• Should there be a fundamentally different UI but until a consensus is reached there should be smaller issues like this one improving the status quo.
• Or should we proceed in the current direction and iterate in small steps with issues like this?

Uncertain what the best approach might be. In regard of the ideation for Token UI 2.0, I’ve suggested in today’s a11y meeting to raise the topic in one of the future weekly UX meeting on friday.

Alright, unpostponing, but reflecting the lower urgency for this by reducing priority to .

Thanks, @lauriii!

I don't think this is either a beta or a stable blocker. 👍 We could potentially remove later phase in case someone wants to contribute to this since it would be a nice UX/DX improvement.

I mean you had to alter tests for this to pass, which could break contrib modules.
Sure a lot of drupal docs, user manuals, and training will have to be written with these changes.

Dev tested on local dev enviornment with branch 'layers-dndkit' of issue https://www.drupal.org/project/experience_builder/issues/3520438 ✨ Refactor Layers UI to use DnDKit Active . Issue is not reproducible on firefox

Hello, i have tested this and have few observations as below.
I added a menu item with and set to expanded and added a sub item below it - After applying the MR the expand collapse functionality worked fine.
The patch 26 fails to apply so styling could not be checked.

Next, I also checked by adding menu item with a normal link, and set to expanded and added a sub item below it and checked, the menu item is not correctly show.

Added screenshots for reference.

wim leers → credited longwave → .

wim leers → credited mherchel → .

Marked 🐛 Error Active as a duplicate. This is very low-hanging fruit.

Note that this is far less likely to occur, hence marking this for a later phase.

Added a first pass, seems to work from rudimentary testing. Needs test coverage.

The blocker went in but I don't think we should try combining the screens, there's a push to decouple block_content from block at the moment so we don't want to tie them together any more (see 📌 Why block_content depends on block? Active )

There is also ✨ Link block to content_block Active for adding a link so maybe we close this one in favour of that?

We already have \Drupal\Core\Config\Entity\ConfigDependencyDeleteFormTrait::addDependencyListsToForm. We need to add the confirm form step as per \Drupal\system\Form\ModulesUninstallForm::submitForm and \Drupal\system\Form\ModulesUninstallConfirmForm::buildForm.

Updated the IS with issue template and added steps to reproduce.

Here's the explain on the query from loading the view and clicking the tablesort.

MySQL [local]> explain SELECT node_field_data.nid AS nid, users_field_data_node_field_data.uid AS users_field_data_node_field_data_uid
    -> FROM
    -> node_field_data node_field_data
    -> INNER JOIN users_field_data users_field_data_node_field_data ON node_field_data.uid = users_field_data_node_field_data.uid
    -> WHERE (node_field_data.status = 1 OR (node_field_data.uid = 1 AND 1 <> 0 AND 1 = 1) OR 1 = 1)
    -> ORDER BY users_field_data_node_field_data.name ASC
    -> LIMIT 50 OFFSET 0
    -> ;
+----+-------------+----------------------------------+------------+------+----------------------------------------------+---------+---------+---------------------------+------+----------+---------------------------------+
| id | select_type | table                            | partitions | type | possible_keys                                | key     | key_len | ref                       | rows | filtered | Extra                           |
+----+-------------+----------------------------------+------------+------+----------------------------------------------+---------+---------+---------------------------+------+----------+---------------------------------+
|  1 | SIMPLE      | node_field_data                  | NULL       | ALL  | node_field__uid__target_id                   | NULL    | NULL    | NULL                      |    1 |   100.00 | Using temporary; Using filesort |
|  1 | SIMPLE      | users_field_data_node_field_data | NULL       | ref  | PRIMARY,user__id__default_langcode__langcode | PRIMARY | 4       | local.node_field_data.uid |    1 |   100.00 | NULL                            |
+----+-------------+----------------------------------+------------+------+----------------------------------------------+---------+---------+---------------------------+------+----------+---------------------------------+
2 rows in set, 1 warning (0.000 sec)

So yeah we're using temp tables.

Setting to PMNMI for the decision on whether we want to do this. Personally I'm happy to close.

As far as I can see this should have been closed as a duplicate in August 2013 as per #6

#1355292: Come up with better alternatives for groupings on the modules page →
📌 Introduce tags[] in module.info.yml file to categorize modules by provided functionality. Postponed: needs info

Now that 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active and child issues are done, all this code is deprecated and will be removed in D12.

Now that 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active and child issues are done, all this code is deprecated and will be removed in D12.

Well, "autoupdates" still isn't "done", but we moved forward, anyway. Now that 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active and child issues are done, this code is all deprecated and will be removed in D12.

With 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active and child issues complete, we're back to a single "Available updates" report, so closing this as "outdated".

This is now green

The last outstanding thread is https://git.drupalcode.org/project/drupal/-/merge_requests/10036#note_40...

Not sure how to handle BC for this.

Added https://www.drupal.org/node/3524296 → and linked to it from the other CR.

I don't think we need a CR for the MediaSourceInterface::METADATA_ATTRIBUTE_LINK_TARGET, happy to be told otherwise though :)

Will try to get this green today

Hmmm... can you elaborate? Not sure what you're getting at specifically.

This wouldn't get backported to Drupal 10. If the MR was rebased and test failures fixed, and it was reviewed/RTBCd in the next ten days it might be able to land in 11.2.0 still, more likely early in 11.3. That would be a much better use of time than creating 10.x versions of the patch if someone has time to take a look. This has been quite close to being committable for a while now I think.

@dbielke1986, I believe @andrew.wang is responding to #254 and pointing out that creating a patch for Drupal 10.3 - which isn't even the latest release in the Drupal 10 series - is not better than using the Linkit module. I agree, since this functionality likely won't be merged into any Drupal 10 version (or will it?). This assuming there's a solid migration path from the Linkit module.

+/**
+ * Provides the Entity Links filter.
+ */
+#[Filter(
+  id: 'entity_links',
+  title: new TranslatableMarkup('Entity links'),
+  description: new TranslatableMarkup('Updates entity links with <code>data-entity-type

and data-entity-type-uuid attributes to point to the latest entity URL aliases.'),

I believe the second one is supposed to say data-entity-uuid instead.

As much of some of these would make sense I may be a -1 for such as change as it would be very disruptive

Since there's been no follow up in 3 months going to close out, if still a valid task though we can always re-open.

Thanks!

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Updating proposed resolution

Still needs @lauriii per #11.

@andrew.wang

Of course, but that's exactly what this post is about: implementing a nice link experience, like LinkIt has.
This is certainly an enrichment of the core and should therefore also go into it, without the need for a Contrib module.

Updated patch in #54 to be compatible with Drupal 10.4.6.
I might take a stab at D11 soon.

I'm not sure this is as relevant anymore since #2401035: items_per_page in node.settings is no longer used → . There is no longer an option for "Number of posts on front page" and the current help text is just "Specify a relative URL to display as the front page."

I can't think of any site I've ever worked on that has used the promoted to front page feature, and it seems it's falling out of favour. There are some related issues below:

#29338: Hide Promoted/Sticky fields by default in Form display →
📌 "Promoted to front page" for new content types should default to Un-Checked Needs work
#2514794: Frontpage view is confusing when only one node is promoted to the default front page →
#2029199: Rename the 'Frontpage' view to 'Latest content' or 'Featured content'. →

I think instead of adjusting help text on the site information settings page we could shift focus on the welcome to Drupal block you get on the default front page instead. Setting to PMNMI in case anyone has different ideas.

Closing (outdated) - DrupalPod may no longer exist! Happy to re-open if there's a good solution that comes up.

penyaskito → closed merge request !1014

Wim prefers we do Js too in 📌 Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active

We'll work on JsComponents here.

#140 does not apply to 11.1.7 so uploaded a new diff of the MR.

ARIA Implementation:

// Example of potential ARIA announcement approach
const announce = (message) => {
  const polite = document.getElementById('tabledrag-aria-live');
  polite.textContent = message;
};
announce(Drupal.t('Row moved to new position'));

Weight Input Replacement:

<!-- Current -->
<select class="tabledrag-weight">
  <option value="-15">-15</option>
  <!-- ... -->
  <option value="15">15</option>
</select>

<!-- Proposed -->
<input type="number" class="tabledrag-weight" min="-50" max="50" step="1">

Would an option to disable the "Show row weights" / "Hide row weights" toggle button, either completely or on a role-basis via Permissions fit in this issue as well, or maybe it is already handled in another issue, or need a new issue?

May be the right status?

There has been no reply to the question asked over a year ago to confirm that this is still a problem. Therefor, closing.

If there is work to do here, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment change make sure to change the issue status to 'Active'.

carrying over from last week: 📌 Disallow dangerous filenames e.g. command injection characters Active
and this one came up in the contribute channel: ✨ Add next and previous buttons to database log entry pages Active

Rebased

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Since there has not been a follow up going to close out, but don't worry we can always re-open if valid still!

Thanks all!

Thanks for the work on this issue. There has been no work on this task for 12 years, except to ask if this issue is still relevant. It is likely that it is no longer needed or has been implemented. Therefor, closing.

If there is work to do here, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment change make sure to change the issue status to 'Active'.

Thanks for the work on this issue. There has been no work on this task for 11 years, except to ask if this issue is still relevant. It is likely that it is no longer needed or has been implemented. Therefor, closing.

If there is work to do here, then either re-open the issue and add a comment or open a new issue and reference this one.

There has been no activity here for 12 years except to ask if this is still valid. There has been no answer so I am closing this.

If there is work to do here, then either re-open the issue and add a comment or open a new issue and reference this one.

This was committed to Drupal 8. I am restoring the meta data to that time.

left a comment on #3223022-40: Open the "discard changes" dialog in the off-canvas tray → , feel free to add any detail i might have missed.

I think this is ready if we split the code components part, which I moved to 📌 JsComponents `enum` props should have human-readable labels: use `meta:enum` Active

Automatically closed - issue fixed for 2 weeks with no activity.

benjifisher → credited simohell → .

benjifisher → credited worldlinemine → .

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

i guess @benjifisher might be familiar with it from discussions in the security team?

I can neither confirm nor deny.

It took me a while to figure out why we need any change at all for JS Component.
So documenting it step by step.

Right now, the site builder will generate their prop, and select "List: string".
They see a single textfield, named "Value", with placeholder "Enter a text value", where they input their values one by one, and select the default one.

That generates:

js_component.enumcodecomponent.yml
[...]
props:
  color:
    title: Color
    type: string
    examples:
      - green
    enum:
      - blue
      - green
      - red
      - Orange
      - 'Another weird color'

One we enable the component, that transforms to:

experience_builder.component.js.enumcodecomponent.yml
[...]
        allowed_values:
          -
            value: blue
            label: blue
          -
            value: green
            label: green
          -
            value: red
            label: red
          -
            value: Orange
            label: Orange
          -
            value: 'Another weird color'
            label: 'Another weird color'

So if they input a friendly label, that's what they get. For translation, we need to translate that config entity.
There's no way we can do this right without having some value - label pair on the client, or document how their values will be generated (potentially like prop names already are). In that case we might indicate in the UI that we expect labels, not values, and ideally print the value so they can copypaste that into the code editor.

If we do that in the client, they will post the pairs (or the value can be easily calculated from the label, as prop names do). For simplicity, we use the same format than SDC (see props in js_component above).

And when we have that, it's the client who would send the enum and the meta:enum (optionally we might want a x-translation-context, or generate one server side, but that's definitely for another follow-up), and we will have the same info than a "meta:enum" complete component (or an easy way to generate it server-side), which will generate the right config entity allowed_values pairs for e.g. translation.

+1 for the follow-ups mentioned in #12 📌 Leap ahead of #3493070 in core: SDC `enum` props should have human-readable labels: use `meta:enum` Active .

@robertom Thanks a lot for improving this patch.

It's now working perfectly for my needs and my request, which was taxonomy only. I didn't try another bundle indeed.

Hey! I just want to mention that I have suggested using the new Icon API → for managing paragraph icons over in 2854585#24 ✨ Improve icon selection in paragraphs type form. Needs review , that could bring this here to another level 🚀

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Regarding sections, it looks like you are able to create sections with the same name. Don't know if this is expected behavior or a bug, but would like someone on the backend to confirm that. If it is a bug, then the error message for that should be user-friendly too.

True, their ids are autogenerated from the label and in case of collision we append a random string.
This was definitely intentional when implemented, but kinda weird and inconsistent. We might want to revisit this. For archeology, it happened in ✨ [PP-1] Integrate saving sections with the backend Postponed

Got this green, it would be great for people to test this on 11.x with the latest changes in the MR.

God help the next person that has to deal with SmartDefaultSettingsTest 💀

a third issue got put on the list 📌 Disallow dangerous filenames e.g. command injection characters Active (i guess @benjifisher might be familiar with it from discussions in the security team)

✨ Show human readable error messages when creating component fails Active displays errors for code component creation so renaming the title here

Re-reading IS I think Wim expected to implement the Code Components here too? 🤔🤔

This works and has good test coverage.

• We need a follow-up for when the core issue lands.
• We might want a follow-up to change the Code Components UI for having 2 fields and store option lists as "value => Human-friendly label" instead of having only the value as of now.

It might be easier to simply install the Linkit → module on Drupal 10.3?

I think #14 is correct, so I am closing this issue as outdated.

If there is work to do here, then either re-open the issue and add a comment or open a new issue and reference this one.

Updated the MR with latest 11.x: solving conflicts and Fix test according with field ui API updates - issue #3386762 ✨ Use modal in add new field flow Active .

Updated the MR with latest 11.x: solving conflicts and Fix test according with field ui API updates - issue #3386762 ✨ Use modal in add new field flow Active .

I was needed changes from MR!10036 for customers project but for Drupal 10.3.14. So I created a patch for D10.3.14. I post it just in case someone needs it same as me.

ps: Note, it doesn't have tests updates.

I accidentally rebased onto the closed branch so I've toggled MRs since the latest one had other issues.

Please, if you want to contribute to this issue do not upload more patches or open more MRs, instead get push access via the button under the issue summary and contribute directly to this MR

https://git.drupalcode.org/project/drupal/-/merge_requests/11100

acbramley → reopened merge request !11100

acbramley → changed the visibility of the branch 3274635-upstream-use-ckeditor-11.x-2 to hidden.

acbramley → closed merge request !11915

acbramley → changed the visibility of the branch 3274635-upstream-use-ckeditor-11.x to active.