Problem/Motivation

While working on #3465295: Integrate Top Bar Navigation with Contextual editing it was discovered that the way Navigation handles the Top Bar visibility could be improved since any html markup inside it, even just a simple comment makes it visible.

As part of the work in that issue, that logic was improved. Once the issue was closed, those improvements were lost.

The aim of this issue is to recover those improvements introduced in https://git.drupalcode.org/project/drupal/-/merge_requests/11036/diffs?c... and add them for the future.

Steps to reproduce

Proposed resolution

Improve logic to manage the Navigation Top Bar visibility

Remaining tasks

Create MR bringing those improvements that were lost when the original issue was closed.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is extracted from #2910353: Prevent saving config entities when configuration overrides are applied where it was discovered that using loadOverrideFree() resulted in bugs due to config entities still being statically cached.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

ShortcutCacheTagsTest::testEntityCreation() check for cache entries in the render cache even though nothing was cached. This needlessly complicates things as any refactoring of the render cache might inadvertently make these tests fail as shown in #2551419-158: Abstract RenderCache into a separate service that is capable of cache redirects in a non-render array-specific way

Steps to reproduce

NA

Proposed resolution

Add a new method to the base class that allows you to run a slimmed down version of verifyRenderCache that only runs the basic checks, does not check for redirects and, most importantly, uses the default cache backend.

Remaining tasks

• Fix. Done

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

None

Original report by @kristiaanvandeneynde

ItemCacheTagsTest::testEntityCreation() and ShortcutCacheTagsTest::testEntityCreation() check for cache entries in the render cache even though nothing was cached. This needlessly complicates things as any refactoring of the render cache might inadvertently make these tests fail as shown in #2551419-158: Abstract RenderCache into a separate service that is capable of cache redirects in a non-render array-specific way

The easy fix is to add a new method to the base class that allows you to run a slimmed down version of verifyRenderCache that only runs the basic checks, does not check for redirects and, most importantly, uses the default cache backend.

Problem/Motivation

https://www.drupal.org/sa-core-2024-007 was released in November 2024.

This is a public issue to add the tests that were used in the development of the fix in a private issue, as several weeks have now passed to allow sites to update.

Steps to reproduce

Run tests in an MR.

Proposed resolution

MR / test / commit.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Hello, i recently migrated from a docker image bitnami/drupal:10.1.6 to bitnami/drupal:10.3.6 and the automatic upgrade of the database apparently broke my Drupal.

I am now unable to deploy my website, i get a 500 error :

error Failed to fetch http://velwatest.azurewebsites.net/jsonapi/block/block Response code 500 (Internal Server Error)
HTTPError: Response code 500 (Internal Server Error)

or

error Failed to fetch https://velwatest.azurewebsites.net/jsonapi/search_page/search_page Response code 500 (Internal Server Error)
HTTPError: Response code 500 (Internal Server Error)

When checking my drupal logs, i see a warning :

Deprecated function: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 207 of /opt/bitnami/drupal/core/lib/Drupal/Core/Routing/UrlGenerator.php)

As well as this error :

Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "entity" for route "jsonapi.search_page--search_page.individual" must match "[^/]++" ("" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 209 of /opt/bitnami/drupal/core/lib/Drupal/Core/Routing/UrlGenerator.php).

If i import back my database backup from before the migration to 10.3.6, the problem disappears.
Do you know why the database upgrade might break my data, or how to fix it ?

What i have tested is : upgrading all modules as well as drupal core to 10.4.3 with composer, it did not help.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

https://www.drupal.org/sa-core-2024-008 was released in November 2024.

This is a public issue to add the tests that were used in the development of the fix in a private issue, as several weeks have now passed to allow sites to update.

Steps to reproduce

Run tests in an MR.

Proposed resolution

MR / test / commit.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

On Drupal CMS I see many instances of this message in my logs:
The following paths in /var/www/html aren't recognized as part of your Drupal site, so to be safe, Package Manager is excluding them from all stage operations. If these files are not needed for Composer to work properly in your site, no action is needed. Otherwise, you can disable this behavior by setting the package_manager.settings:include_unknown_files_in_project_root config setting to TRUE. README.md launch-drupal-cms.sh

Given only 1000 messages are retained by default, these are just noise. As a "marketeer" I can't do anything about them.

Steps to reproduce

Base Drupal CMS installation on local.
I've done a few module updates through the UI... awesome work people.

Proposed resolution

As we know these two files will always exist for a Drupal CMS installation, can they be excluded from the test in some way to avoid this message appearing in the logs?

Problem/Motivation

In all browsers, when editing a node that uses a select and that select has long options, the responsive layout does not work, and the right column is hidden in narrower browser widths.

Steps to reproduce

1. Create a taxonomy list, add a term that will create a select option that is wider then the claro left column. The local example we had as 112 characters long!
2. Add the taxonomy list to the content type
3. Create / Edit a new of that content type
4. Above 976px [the two column layout], Left column width is fixed by the width of the select input. resize the browser to see the right column fall out of the right side of the browser, until the

If I try limiting the select width using the browser console, it does not fix the layout. If I delete the select in the console, it does.

I am not sure how to make the select fluid width as it is in the browser widths < 976px [the single column layout], but this may not be a problem with the select, but with the grid?

After further research, this looks like the browser's regular behavior with a specific combination of display:grid and long select options that we can address with the specific code.

Proposed resolution

Select tag has been given a max-width 100%. Add the max-width: 60rem; to the form-element--type-select in the node form.

Remaining tasks

Review

User interface changes

Before

After

API changes

NA

Data model changes

NA

Release notes snippet

Problem/Motivation

MessageCommand and the associated JavaScript API was added to Drupal core in 2019/Drupal 8.8.0, but was not used widely in Drupal core until 10.3.0, when the bigpipe module began using it to render messages created within bigpipe placeholders.

Because MessageCommand has not been used widely, many custom themes have not themed custom JavaScript messages.

For examples of how to override message theming, see:

core/themes/olivero/js/message.theme.js

and

core/themes/claro/js/messages.js

And the associated libraries-extend entries in those themes' .info.yml files.

Steps to reproduce

Original report:

Upgraded to 10.3 and status-message.html.twig is missing as a theme suggestion, breaking my custom theme. See screenshots.

Copied git bisect result from #24

2172d1009cec0e8f908a51fb2c99a1eb06b8b6da is the first bad commit
commit 2172d1009cec0e8f908a51fb2c99a1eb06b8b6da
Author: Alex Pott <alex.a.pott@googlemail.com>
Date:   Thu Feb 22 08:52:28 2024 +0000

    Issue #3379885 by catch, Wim Leers: Use MessagesCommand in BigPipe to remove special casing of the messages placeholder
    
    (cherry picked from commit 44c345dd9b8e2e1fb7131868a5d8b27c57e5b8e3)

 core/modules/big_pipe/big_pipe.services.yml        |  2 +-
 core/modules/big_pipe/src/Render/BigPipe.php       | 79 +++++-----------------
 .../big_pipe/tests/src/Functional/BigPipeTest.php  |  8 +--
 .../FunctionalJavascript/BigPipeRegressionTest.php |  9 ++-
 .../tests/src/Unit/Render/FiberPlaceholderTest.php |  4 +-
 .../tests/src/Unit/Render/ManyPlaceholderTest.php  |  4 +-
 6 files changed, 32 insertions(+), 74 deletions(-)

Issue: #3379885: Use MessagesCommand in BigPipe to remove special casing of the messages placeholder

First bad commit: 2172d1009cec0e8f908a51fb2c99a1eb06b8b6da

Bad commit at the relevant file: core/modules/big_pipe/src/Render/BigPipe.php

Proposed resolution

Problem/Motivation

I am reviewing Drupal CMS with my marketeer hat on.

Under the "Extend" menu, the sub-menu page titles do not match the tab labels. There is also one duplicate page title.

There are six tabs displayed:

1. List tab - page title "Extend". This is the default tab, so understood this might not match.
2. Recommended tab - page title "Browse projects". This is a duplicate of the next tab's page title and doesn't reflect the page's content, which is a list of Recipes. Perhaps change both to "Browse recipes".
3. Browse modules tab - page title "Browse projects". Change so they match.
4. Update tab - page title "Update". These match.
5. Update Extensions tab - page title "Automatic Updates Form". This page doesn't perform automatic updates; I need to perform these manually, so it is poorly named. Change page title to match the tab label.
6. Uninstall tab - page title "Uninstall". These match.

There is inconsistent capitalisation between "Browse modules" and "Update Extensions".

What's the difference between a project, module and extension in this context? All three terms are used within just the tab labels and page titles under the Extend menu? Will our marketeer persona understand the difference or just get confused?

Steps to reproduce

Drupal CMS base install on local. No additional content types or recipes installed.

Proposed resolution

Change the tab labels and/or page titles as suggested above, with consistent capitalisation and nomenclature.

Problem/Motivation

It is pretty common to want to use a token for a URL when editing text. For instance, you might want something like:

<a href="[my:token:here]">link text here</a>

However, if you try to do this in a body field that is using CKEditor, with a text format that uses the "Limit allowed HTML tags and correct faulty HTML" filter, if you enter a token like that in the field, and then later edit the content that contains that field and either look at the HTML source or save the content, the token is corrupted. This seems to be independent of which CKEditor buttons you have configured, so it isn't a problem (apparently) with a particular button plugin.

Additionally, some (but not all) other attributes in HTML get corrupted in the same way, if your text format allows these attributes. Some examples that were tested:

Tokens in the text that are outside of HTML attributes do not get corrupted.

Steps to reproduce:
a) In a content item with a field that has a text format that is configured to use CKEditor for editing, and which contains the "Limit allowed HTML tags and correct faulty HTML" filter, and allows the A tag, type some link text in the editor.
b) Highlight to select the link text.
c) Click the Link button (chains) in the editor toolbar, and enter [my:token:here] as the URL in the popup.
d) Click Save in the popup. Verify that the HTML source looks like

<a href="[my:token:here]">link text here</a>

e) Save the content item you are editing.
f) Test -- the link works fine (assuming you are running a token replace so it gets replaced by the right URL).
g) Edit the content item again.
h) When you get back to the editor, look at the HTML source. Instead of seeing what was there before, you will see something like this:

<a href="en:here]">link text here</a>

So that's the bug: if you re-edit some HTML text using CKEditor and the "Limit allowed HTML tags and correct faulty HTML" filter, and there is an A tag with a token in the URL (or tokens in various other attributes, but not all attributes), CKEditor truncates and mangles the token, leading to data loss. According to Priority Levels of Issues, this means it is a Critical bug (or at least Major?) because it leads to data loss.

Note: We are specifically seeing this in the proposed Help Topics module (see related issue #2943974: Work-around for route tokens in Help text format getting truncated after editing a help topic).

Proposed resolution

Fix Drupal so that CKEditor doesn't mangle tokens in URLs in A tags.

The problem was traced down to a bug in \Drupal\Component\Utility\Xss::attributes(). If you pass in an attribute string like href="[something:something:config_basic]" to this function, you get out something that looks like href="config_basic]".

Remaining tasks

Fix the bug in Xss::attributes().

User interface changes

CKEditor will not mangle HTML containing tokens for URLs in A tags, or other HTML tag attributes.

API changes

None.

Data model changes

None.

Problem/Motivation

Sibling issue for simple config: #2952037: [meta] Add constraints to all simple configuration.

Now that we have the possibilities to validate configuration we should do that.
This meta issue is about adding constrains to all config entities, so we can use that in JSON:API as well as in configuration entity forms.

The current list of config entity types in core:

1. core.base_field_override.*.*.*: #3324140: Convert field_storage_config and field_config's form validation logic to validation constraints
2. field.field.*.*.*: #3324140: Convert field_storage_config and field_config's form validation logic to validation constraints
3. ✅ core.date_format.*: #3397491: Add validation constraints to core.date_format.*
4. core.entity_view_mode.*.*: #3445150: Add validation constraints to core.entity_view_mode.*.*
5. core.entity_view_display.*.*.*
6. core.entity_form_mode.*.*:#3448457: Add validation constraints to core.entity_form_mode.*.*
7. core.entity_form_display.*.*.*
8. ✅ block.block.*: #3379725: Make Block config entities fully validatable
9. ✅block_content.type.*: #3397493: Add validation constraints to block_content.type.*
10. comment.type.*: #3455066: Add validation constraints to comment.type.*
11. contact.form.*: #3445976: Add validation constraints to contact.form.*
12. ✅ editor.editor.*: #3412361: Mark Editor config schema as fully validatable
13. field.storage.*.*: #3324140: Convert field_storage_config and field_config's form validation logic to validation constraints
14. filter.format.*: #3421946: [PP-2] Make FilterFormat config entities fully validatable
15. ✅ image.style.*: #3447286: Add validation constraints to image.style.*
16. ✅ language.entity.*#3457766: Add validation constraints to language.entity.*^{Not in Standard}
17. ✅ language.content_settings.*.*#3458321: Add validation constraints to language.content_settings.*.*^{Not in Standard}
18. ✅ node.type.*: #3379091: Make NodeType config entities fully validatable
19. responsive_image.styles.*^{Not in Standard}
20. rest.resource.*^{Not in Standard}
21. ✅ search.page.*: #3456133: Add validation constraints to search.page.*
22. ✅ shortcut.set.*— see #3324984-35: Create test that reports % of config entity types (and config schema types) that is validatable
23. ✅ system.menu.*— see #3324984-35: Create test that reports % of config entity types (and config schema types) that is validatable
24. ✅ system.action.*:#3449259: Add validation constraints to system.action.*
25. ✅ taxonomy.vocabulary.*: #2002174: Allow vocabularies to be validated via the API, not just during form submissions
26. ✅ user.role.*: #3445215: Add validation constraints to user.role.*
27. views.view.*
28. workflows.workflow.*: #2920441: Add config validation for workflow entities^{Not in Standard}

Total: 13/28=46%
Standard: 11/23=48%

Last updated: July 23, 2024.

Related issues

• For all config entity types: UUID: #2870878: Add config validation for UUIDs
• For all config entity types: machine_name: #2920678: Add config validation for the allowed characters of machine names
• For all config entity types: plugin IDs: #2920682: Add config validation for plugin IDs

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

New documentation standards for form elements are being discussed at #1617948: [policy for now] New standard for documenting form/render elements and properties. Whereas there is still some debate as to how to document common elements. There has been consensus that code examples and properties specific to the form should be documented with the classes that implement them. This issue serves as a meta-issue to track the work required to move code examples and property documentation into those classes.

Proposed resolution

Create child issues for each of the "similar" elements (e.g. those that use #options). Create form element documentation for each class containing:

• A description of what the element does.
• Documentation for properties that are integral to using the element.
• A simple render array example illustrating its usage or an @see link to a concise example.

Problem/Motivation

Contact form entity is not yet fully validatable:

.vendor/bin/drush config:inspect --filter-keys=contact.form.feedback --detail --list-constraints
➜  🤖 Analyzing…

 Legend for Data: 
  ✅❓  → Correct primitive type, detailed validation impossible.
  ✅✅  → Correct primitive type, passed all validation constraints.
 -------------------------------------------------- --------- ------------- ------ --------------------------------------------------------------------------------------------- 
  Key                                                Status    Validatable   Data   Validation constraints                                                                       
 -------------------------------------------------- --------- ------------- ------ --------------------------------------------------------------------------------------------- 
  contact.form.feedback                              Correct   87%           ✅❓   ValidKeys: '<infer>'                                                                         
   contact.form.feedback:                            Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   contact.form.feedback:_core                       Correct   Validatable   ✅✅   ValidKeys:                                                                                   
                                                                                      - default_config_hash                                                                      
   contact.form.feedback:_core.default_config_hash   Correct   Validatable   ✅✅   NotNull: {  }                                                                                
                                                                                    Regex: '/^[a-zA-Z0-9\-_]+$/'                                                                 
                                                                                    Length: 43                                                                                   
                                                                                    ↣ PrimitiveType: {  }                                                                        
   contact.form.feedback:dependencies                Correct   Validatable   ✅✅   ValidKeys: '<infer>'                                                                         
   contact.form.feedback:id                          Correct   Validatable   ✅✅   Length:                                                                                      
                                                                                      max: 32                                                                                    
                                                                                    ↣ PrimitiveType: {  }                                                                        
                                                                                    ↣ Regex:                                                                                     
                                                                                      pattern: '/^[a-z0-9_]+$/'                                                                  
                                                                                      message: 'The %value machine name is not valid.'                                           
   contact.form.feedback:label                       Correct   Validatable   ✅✅   Regex:                                                                                       
                                                                                      pattern: '/([^\PC])/u'                                                                     
                                                                                      match: false                                                                               
                                                                                      message: 'Labels are not allowed to span multiple lines or contain control characters.'    
                                                                                    NotBlank: {  }                                                                               
                                                                                    ↣ PrimitiveType: {  }                                                                        
   contact.form.feedback:langcode                    Correct   Validatable   ✅✅   NotNull: {  }                                                                                
                                                                                    Choice:                                                                                      
                                                                                      callback: 'Drupal\Core\TypedData\Plugin\DataType\LanguageReference::getAllValidLangcodes'↣ PrimitiveType: {  }                                                                        
   contact.form.feedback:message                     Correct   Validatable   ✅✅   Regex:                                                                                       
                                                                                      pattern: '/([^\PC\x09\x0a\x0d])/u'                                                         
                                                                                      match: false                                                                               
                                                                                      message: 'Text is not allowed to contain control characters, only visible characters.'↣ PrimitiveType: {  }                                                                        
   contact.form.feedback:recipients                  Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: contact.form.*                   
   contact.form.feedback:recipients.0                Correct   Validatable   ✅✅   Email:                                                                                       
                                                                                      message: '%value is not a valid email address.'↣ PrimitiveType: {  }                                                                        
   contact.form.feedback:redirect                    Correct   NOT           ✅❓   ⚠️  @todo Add validation constraints to config entity type: contact.form.*                   
   contact.form.feedback:reply                       Correct   Validatable   ✅✅   Regex:                                                                                       
                                                                                      pattern: '/([^\PC\x09\x0a\x0d])/u'                                                         
                                                                                      match: false                                                                               
                                                                                      message: 'Text is not allowed to contain control characters, only visible characters.'↣ PrimitiveType: {  }                                                                        
   contact.form.feedback:status                      Correct   Validatable   ✅✅   ↣ PrimitiveType: {  }                                                                        
   contact.form.feedback:uuid                        Correct   Validatable   ✅✅   Uuid: {  }                                                                                   
                                                                                    ↣ PrimitiveType: {  }                                                                        
   contact.form.feedback:weight                      Correct   Validatable   ✅✅   Range:                                                                                       
                                                                                      min: -2147483648                                                                           
                                                                                      max: 2147483647                                                                            
                                                                                    FullyValidatable: null                                                                       
                                                                                    ↣ PrimitiveType: {  }                                                                        
 -------------------------------------------------- --------- ------------- ------ --------------------------------------------------------------------------------------------- 

Steps to reproduce

1. Get a local git clone of Drupal core 11.x.
2. composer require drupal/config_inspector— or manually install https://www.drupal.org/project/config_inspector/releases/2.1.5 or newer (which supports Drupal 11!)
3. composer require drush/drush
4. vendor/bin/drush config:inspect --filter-keys=contact.form.feedback --detail --list-constraints

Proposed resolution

Add validation constraints to missing properties.

This requires looking at the existing code and admin UI (if any) to understand which values could be considered valid. Eventually this needs to be reviewed by the relevant subsystem maintainer.

For examples, search *.schema.yml files for the string constraints:😊

Reach out to @borisson_ or @wimleers in the #distributions-and-recipes.

Remaining tasks

MR

User interface changes

None.

API changes

None.

Data model changes

More validation 🚀

Release notes snippet

None.

Problem/Motivation

@xjm, from #2486177-132: Deleting an entity translation from the UI deletes the whole entity:

I'm in the process of reviewing this and I must admit the sorta-crazy around EntityDeleteFormTrait is snarling my brain. I read over #1728804: Introduce (Content)EntityDeleteForm and children to handle entity deletions for some background on why things are the way they are, but I'm still unclear on why, for example, ContentEntityConfirmFormBase is a thing (it seems only used for deletions), and why we don't just do away with EntityDeleteFormTrait at this point (when we're overriding it so much) and just put the respective versions of the methods in ContentEntityDeleteForm and EntityDeleteForm (which are the only usages). (For others' reference, ContentEntityDeleteForm does not extend EntityDeleteForm; and EntityDeleteForm has only config-specific stuff, which also confused me quite a bit.) Is there a reason to keep the trait other than for BC? Because then we could do away with the trait overriding cleverness.

Proposed resolution

Fold ContentEntityConfirmFormBase into EntityConfirmFormBase and move all the methods from EntityDeleteFormTrait to EntityDeleteForm.

Remaining tasks

• Propose a solution
• Write a patch
• Review it

User interface changes

Nope.

API changes

Drupal\Core\Entity\ContentEntityConfirmFormBase and Drupal\Core\Entity\EntityDeleteFormTrait will be removed.

Beta phase evaluation

Problem/Motivation

The messages block/element always uses a placeholder, this is because the messages to be rendered can be unique.

However, checking whether there are any messages at all is very cheap. If there are no messages, there's nothing to render, and we can render exactly the same HTML every time, and avoid loading big pipe/AJAX/jQuery.

This wasn't possible before #3493911: Add a CachedPlaceholderStrategy to optimize render cache hits and reduce layout shift from big pipe but now is.

Steps to reproduce

Install the standard profile, create an authenticated user, log in as that user, visit the front page - note that ajax.js and big_pipe.js are loaded.

Then apply the MR, clear caches and refresh - big_pipe.js and ajax.js should no longer be loaded.

Proposed resolution

Add a new 'messages' cache context which checks if there are any messages to be rendered and allow caching if there aren't.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

This issue surfaced because of a hook implementation in the coi module, but is actually a core issue. I have a website with both the pathauto and pathauto_update modules installed. Pathauto contains a pathauto_update_8001() update hook in its pathauto.install file. This update hook is incorrectly being registered as a hook implementation of a non-existent hook_8001 of the pathauto_update module. This triggers the following error, since coi_module_implements_alter() has a string typehint on the $hook argument:

TypeError: coi_module_implements_alter(): Argument #2 ($hook) must be of type string, int given, called in /[..]/web/core/lib/Drupal/Core/Hook/HookCollectorPass.php on line 94 in coi_module_implements_alter() (line 16 of /[..]/web/modules/contrib/coi/coi.module).

Proposed resolution

Maybe allowlist what kind of hooks can be registered in a .install file? In case this is considered a non-issue, we should probably document the argument type of $hook in hook_module_implements_alter() to prevent any future issues.

This meeting takes place every Friday at 14:00 UTC (currently 6:00am PT, 9:00am ET). See Time.is to see what that is in your timezone.

The meetings are held using Zoom, and a link is posted in the #ux Slack channel 10 minutes before the meeting. Agenda is first come, first serve and set by attendees. Use the Needs usability review issue tag for issues that need review and/or suggest issues in comments here.

List of Slack users to ping 10 minutes before the meeting:
@worldlinemine, @lauriii, @AaronMcHale, @anmolgoyal74, @Ravi, @shaal, @ckrina, @simohell, @gauravvv, @Quynh, @yoroy, @andrei.zvonkov, @Regu.pl, @amazingrando

This list gets copied to the issue for the next meeting. If that has already happened, then go to that issue to add/remove yourself to/from the list.

Recording of this week's meeting: TODO

Rough transcript of this week's meeting: Drupal Usability Meeting - 2025-02-21.txt

We discussed the following issue:

• #3370326: Refine field descriptions

NR and RTBC issues marked Needs usability review.

The group is actively tracking progress on these issues:

• #3318110: [meta] Reorganize Block items in the administration menu
• #2860419: [Meta] Appearance page is too long and confusing
• #2985168: [PP-1] Allow media items to be edited in a modal when using the field widget with notes:
  • @AaronMcHale: Issue could use some guidance.
    In comment #109 the issue was marked as postponed for needing input from UX, accessibility and media initiative. Apparently there are some outstanding UX/accessibility questions (but I'm not sure what they are). This was echoed in comment #111.
    Comment #144 is asking what is needed to move the issue along (the postponed state seems to be causing some delays/confusion as to how to proceed).
    Perhaps we can at least take a look at what the issue is doing and provide some recommendations/guidance on how it could be implemented.
• #2704931: Provide Drupal root path on file system admin form
• #3163197: Allow hiding configured blocks in layout builder
• #2916876: Add visibility control conditions to blocks within Layout Builder
• #3247064: Error message presented when a BrokenPostRequestException is fired on AJAX submission can be misleading
• #3262935: Link field validation constraints don't give enough detail
• #3386762: Use modals in field creation and field edit flow

Remaining tasks

1. Add issue credits for the participants.
2. Add the issue(s) we discussed to the issue summary and as related issues.
3. Add a rough transcript.
4. Add a link to the recording on YouTube.
5. Comment on the issue(s) we discussed.

Problem/Motivation

This issue is a follow-up for #3356894: Make field selection less overwhelming by introducing groups to refine the newly added field descriptions if wanted.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Ran into the issue that there was no validation on some of the plugins. Starting somewhere random i thought i should bbuild a RoleExists constraint to use in the config validation. Also to start learning how to do this.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet