Problem/Motivation

Drupal is automatically installable if there is a $databases definition and hash_salt.

We should provide default getenv calls that allow reading from environment variables. This allows bypassing needing sites/default/settings.php. Here's my normal pattern, which I'm sure many already have. The only quirk is defining SQLite or anything.

$settings['hash_salt'] = getenv('DRUPAL_HASH_SALT') ?: NULL;

$settings['deployment_identifier'] = getenv('DEPLOYMENT_IDENTIFIER')?: NULL;

if (getenv('DRUPAL_DB_DRIVER') !== 'sqlite') {
  $databases['default']['default'] = [
    'driver' => getenv('DRUPAL_DB_DRIVER'),
    'database' => getenv('DRUPAL_DATABASE_NAME'),
    'username' => getenv('DRUPAL_DATABASE_USERNAME'),
    'password' => getenv('DRUPAL_DATABASE_PASSWORD'),
    'host' => getenv('DRUPAL_DATABASE_HOST'),
    'port' => getenv('DRUPAL_DATABASE_PORT'),
  ];
}
else {
  $databases['default']['default'] = [
   // turn this to env
    'database' => '../private/db.sqlite',
    'prefix' => '',
    'namespace' => 'Drupal\\Core\\Database\\Driver\\sqlite',
    'driver' => 'sqlite',
  ];
}

Then we document that if you set these on your VM, k8s manifest, whatever, it "just works"

I'm not proposing we add vlucas/phpdotenv, we just provide support for default environment variables. Other frameworks do this and allow customizing them anyway. If the environment variables are not present, the system works as if there is nothing configured.

Steps to reproduce

Proposed resolution

TBD

Drupal assumes the $databases array will be populated by \Drupal\Core\DrupalKernel::initializeSettings.

This calls \Drupal\Core\Site\Settings::initialize which sets the database connection information:

    // Initialize databases.
    Database::setMultipleConnectionInfo($databases, $class_loader, $app_root);

Maybe in \Drupal\Core\Site\Settings::initialize or \Drupal\Core\Database\Database has a static method that the settings initialization uses.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In Claro, a visual hover state (blue background) is assigned to table rows and provides a visual cue for which row is active. This feature is only available when navigating by mouse/pointer and should be updated to inform keyboard users.

Steps to reproduce

Set admin theme to Claro and visit an admin page with a table, such as: admin/people

Screenshot of hover state on active row, I placed the cursor (not visible in screenshot) over the row which turns light blue:

Focusing on row with keyboard, the light blue background is missing:

Proposed resolution

Suggested fix: add a selector to the hover style for keyboard users (:focus-within will apply the background color to the row whenever a child link, button, or form element has focus)

Problem/Motivation

While working on tests in #3393400: Implement Nightwatch tests. I could not click any links inside of the admin toolbar. It turns out it is due to .admin-toolbar__scroll-wrapper having display: contents;

I went to Can I Use and found there are problems with display: contents; in all major browsers: https://caniuse.com/?search=display%3A%20contents

Buttons are not accessible with display: contents applied. See issues for Chromium, Firefox, and WebKit

Steps to reproduce

I haven't manually reproduced by trying to tab and focus on buttons.

See https://issues.chromium.org/issues/40866683 with a non-Drupal example.

Proposed resolution

Remove display: contents;

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

By @finnsky in #3391723: [PLAN] Accessibility review for new Navigation bar:

We could add Nightwatch tests because we have automated Nightwatch a11y tests in core: #3293469: Automated A11y tests in Nightwatch. Added simple tests using it.

How to start with Nightwatch testing can be found in `core/tests/README.md` file from Drupal core.

This issue should be focused on implementing a first simple test, like "(If logo) it takes you to the homepage" and define the structure the rest of the tests will follow.

Problem/Motivation

This started for me because I had duplicated plugin definitions in code but it may be a serious issue for someone and believe me, debugging it was a little nightmare.

Basically we have those new object oriented plugin definitions so a definition doesn't have to be an array anymore. Unfortunately core lacks full support of the feature: Drupal\Component\Plugin\Derivative\DeriverInterface::getDerivativeDefinitions and Drupal\Component\Plugin\Derivative\DeriverInterface::getDerivativeDefinition clearly say those should be arrays and not objects.
Objects are not supported at all by Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator, for example mergeDerivativeDefinition() that uses array_filter on derivatives.

The case of having to merge derivative definition with base plugin definition may be very rare since this hasn't surfaced yet (ok, my searching skills may not be good enough as well) but if anyone encounters it, the project is completely broken after introducing such config.

Problem/Motivation

I've read this 4 times and I don't get it:

   * @param $graph
   *   A three dimensional associated array, with the first keys being the names
   *   of the vertices, these can be strings or numbers. The second key is
   *   'edges' and the third one are again vertices, each such key representing
   *   an edge. Values of array elements are copied over.
   *
   *   Example:
   *   @code
   *     $graph[1]['edges'][2] = 1;
   *     $graph[2]['edges'][3] = 1;
   *     $graph[2]['edges'][4] = 1;
   *     $graph[3]['edges'][4] = 1;
   *   @endcode
   *
   *   On return you will also have:
   *   @code
   *     $graph[1]['paths'][2] = 1;
   *     $graph[1]['paths'][3] = 1;
   *     $graph[2]['reverse_paths'][1] = 1;
   *     $graph[3]['reverse_paths'][1] = 1;
   *   @endcode

* A three dimensional associated array, with the first keys being the names
* of the vertices, these can be strings or numbers.

This sentence isn't grammatical.

The second key is
* 'edges' and the third one are again vertices

I wasn't sure if this was a typo and it should be quoted as 'vertices', a literal string. But looking at the example, it's not.

each such key representing
* an edge.

Does that mean that each key of the 'edges' array is the name of a vertex, that is, matches a key in the main array?

> Values of array elements are copied over

I have no idea what that means.

Copied over -- does that mean copied from one place to another? In which case, from where to where? Or does it mean overwritten?

Is it trying to say that the values don't mean anything? They are all 1 in the example code, so I suspect that might be the case.

> * On return you will also have:

Return? This is a constructor. It doesn't return anything. What does this mean?

Remaining tasks

• Convert the latest patch to a merge request.
• Update the docblock as per #16.

Problem/Motivation

When no summary is specified, token [node:summary] uses formatter settings of teaser view mode in order to generate trimmed version of body field. If 'teaser' view mode is not configured, default text_summary_or_trimmed trim lengths will be used (600 characters atm)

However, existing code does not check what formatter is being used. Instead, it checks for trim_length setting only.

When some other field formatter (like Smart trim) is being used for teasers, summary is being generated incorrectly. This happens because Smart trim uses exactly the same trim_length setting, but it can be words, not characters.

In particular case, smart trim is configured to use 30 words. Token [node:summary] gives 30 characters, instead of default 600.

Proposed resolution

Add extra check for the formatter that is being used for teaser view mode for body field.

Remaining tasks

• Review patch

User interface changes

No

API changes

No

Data model changes

No

SEE COMMENT #3 https://www.drupal.org/project/drupal/issues/3447170#comment-15596991 for steps to reproduce.

When adding new fields to user accounts via /admin/config/people/accounts/fields and then editing the user account and setting a value for the new fields so they can be pulled into a view block does not display in the view unless the user account has at least 1 published or unpublished node content. Very...strange!

For about 3 days I went round and round thinking I had some kind of permission problem, removing contrib modules that handle extra permissions or events like ECA, Content Access, ACL and eliminating any other possibilities I could think of that could be causing this issue. After reading through probably 50 different posts on similar events occuring.

I couldn't understand why some accounts would display the new view blocks (being displayed on user/* account pages with the new fields data) showing the complete view block with the correct data and other accounts would only show partial data and not the new fields data (even when those fields have value) especially since I have the fields in the view set to display even when empty including display rewrite if empty. I used the rewrite output to display the field but with some added html, ID's and classes - so even if the field had no data it should still display but that didn't even happen. Thus why I thought I had a permission problem somewhere!

By the time I was done with all that, basically stripped all permissions between fields and the view and view blocks themselves "and the same thing was/is happening" (getting overly frustrated at this point I started digging further into it.) The entire time no errors, warning or issues reported anywhere, not in dblog or onscreen or browser console, nothing...

Roles, permissions, etc., all set the same between all accounts (this should not be happening). The only difference I could find between any accounts was the fact that some accounts have published and unpublished node content while others did not. The ones that in the past had/have at least one published or unpublished node (did not matter what the content type was/is) their account view blocks were working as expected displaying the new field data from the user account (which to note, those fields are in NO WAY attached to any content type). Now on the other side any account that has never published a node and does not have any unpublished nodes as well are the accounts not displaying the view blocks with the new fields data.

OK, found a difference I can test...

Using the masquerade module I switched to a user account without any published node type content and add a new node of any content type the user account can access. Once completed I go back to the users account page and "waahhhh'laaa" the view block now showed properly. I switched accounts back to administrator account and then to make sure it still works, I check the users account page and all is good and then I unpublish that users node content to make sure it still shows and it does for both admin and user accounts.

Now before just posting this here, the field I initially added to the user accounts was actually a paragraph with 2 number fields so to rule out the paragraph module as causing this issue I created a new "test number field" again at /admin/config/people/accounts/fields then duplicated my view block removed the original field and added the new one and placed the block on the same user account pages and got the same exact issue in my results.

I'll include some sample images showing the issue before and after the user has a published node. I also tested to see if a user without a published or unpublished node could trigger the view to work properly by another published entity like comments which did not work!

That said I'm not entirely sure why not having a published or unpublished node content type that isn't related to the user account fields display through a view. It just doesn't make sense.

You'll see on the example images the before image looking at /user/4 (I have the field themselves displayed just as the fields as per user display of fields and then the view blocks in the right sidebar which should also have the data and does not. When all is said and done the fields themselves won't be displayed there just the view blocks with the fields data will because of what and how they are being used all around.

It's also worth mentioning using "preview" in views using user id's to preview with contextual filters also produces the same results. If user has a published or unpublished node everything displays properly. If the user does not have a published or unpublished node the view does not display properly.

Regarding the view there is no default filter criteria or sort criteria for the view and it uses relationships "User" and Contextual filter "(User) User: User ID" -> set to Provide default value: Type "User ID from route context".

For good measure:
Drupal: 10.2.6
PHP: 8.1.13
Apache: 2.4.38 (Debian)
Database: MySQL 5.7.40

Problem/Motivation

Per agreement with @ckrine this meta issue is a collection of potential problems on the new navigation layout page moving from the block UI towards a layout builder based solution. The problems were raised in one part during #3441951: Drupal Usability Meeting 2024-04-26 (attendees were: @benjifisher, @BlackBamboo, @rkoller, @SKAUGHT, @worldlinemine, recording: https://youtu.be/RlVJilPxNUA) and subsequently supplemented by my additional explorations and testing. The potential issues in the problem section are numbered; those raised during the usability meeting are labeled because they have already received a broader consensus. There are corresponding numbers in the proposed resolution section in case there is an already-existing issue or if there is an idea or suggestion how to tackle the problem. The whole meta issue is supposed to be mainly for evaluation purposes. As soon as there is an agreement on a problem a dedicated child issue should be created:

1. GENERAL
1.1 Lock-in on the Navigation blocks page (usability meeting)
By clicking the Navigation blocks menu item, you get right into an edit mode without any warning. The navigation is gone, replaced by a dysfunctional preview, a placeholder of the navigation sidebar, and the only regular way left exiting the page is the breadcrumb navigation. That way, the page is breaking with many expectations and assumptions by the user navigation-wise.

1.2 The site icon is hidden (usability meeting)
While being in edit mode on the navigation layout page the site icon gets hidden in case it is set and used. In addition, the icon functions as part of the navigation; hiding it is not an exact preview.

1.3 Discard changes
Clicking the Discard changes button breaks the "lock-in" on the confirmation step. The functional navigation sidebar is available to the user. Instead of confirming or canceling the user is able to use the navigation sidebar without limitations - all changes are getting discarded without confirmation. In case you click Save or Discard changes instead, you return to the lock-in state with the dysfunctional preview of the navigation sidebar.
The micro copy on the page of the confirmation step is suboptimal. It is wordy; it doesn't matter what tool, in the form of layout builder, the user is using here, nor is it necessary to explain at this point. The copy is talking about forms and links, in the context of the layout builder tool on this page these are abstract terms, which is sort of confusing. Technically speaking these forms and links are not even disabled when a user is reading this description, as mentioned before, the navigation sidebar is fully functional on the confirmation step.

1.4 A lot of screen real estate on the navigation blocks page stays unused
The layout and presentation is not ideal in the current form. There is a huge gap between the areas of attention on both ends of the screen; the bigger the display the more apparent and pressing this issue becomes. Out of the box you have the main content area with a help text and the preview of the navigation sidebar on the left end of the screen. It is not directly apparent that this is a dysfunctional preview instead of the previously functional navigational sidebar. If you try to add a block or click a contextual link for any of the added navigational blocks, the off-screen tray is shown on the other end of the screen on the right:

• If you resize the window width around in the limits of the desktop viewport with the off-screen tray open, the tray isn't sticking to the right end of the screen, sometimes it even moves outside the visible viewport.
• On smaller viewports (tested on an iPhone) the preview is collapsed per default and the "top bar" with the Expand sidebar button is underneath the Show content preview checkbox. If you click the Expand sidebar button the preview opens for a second or two and then immediately auto-collapses again. During the expanded state the menu item labels are not shown and only the icons are being displayed. It is not enough of time to either click the Add block button or any other contextual link. When testing on the desktop by narrowing down the browser window the expanded off-screen tray is right underneath the Expand sidebar button.
• One of the most significant problems becomes apparent if you open the navigation layout page on a widescreen monitor (a 36" display in my case), you then have the preview on the left end of the screen and the off-screen tray on the right end of the screen. In between those two regions of interest you have the main "content" area containing help text, two buttons and a checkbox. A lot of screen real estate stays unused with not much functionality while the two sidebars, the areas of interest where all the "action" happens, are pushed to the margins. If you are applying the straw test (https://scottvinkle.me/blogs/work/proximity-and-zoom) these two areas of attention with the sidebars are not anywhere near in close-proximity, and it is nearly impossible for people with the condition simulated by the straw test to visually jump in between the two sidebars. For anyone else, it is a challenging task, manageable but still challenging.

1.5 [Regression] Impossible to set block visibility settings with Layout Builder
With the block UI the user had the ability to set block visibility settings for the different menu and navigation blocks. With the move to Layout Builder that option dropped out. But even with the “block UI”-based interface it would have been challenging to create different layouts for different sets of navigation and menu blocks per user roles.

1.6 Visual representation of draggable regions
For dragging a menu or navigation block you don't have to activate the Move option for a block in the context menu. You are able to directly drag and drop a block, but the visual affordance is not available, the only visual feedback is that the mouse cursor changes to the horizontal/vertical drag icon even though you are solely able to drag and drop vertically. Plus if the changing mouse cursor on hover is the only visual indication for the “movability” that could easily be missed by the user.

1.7 Drag and Drop of menu/navigation blocks is not working across browsers
Firefox works, while Safari and Edge are not working.

1.8 Region labels are only shown when the move mode is active for a block (usability meeting)
At the moment region labels are solely shown when the Move mode for a menu or navigation block gets activated. The rest of the time the user only sees the blueish dotted lines. It is not necessarily clear what those blueish dotted lines stand for.

1.9 Redundant and verbose micro copy for the h1 inconsistent with the menu item (usability meeting)
The h1 contains the term layout twice, which is sort of redundant. On the other hand the menu item for the page as well as its description refer to Navigation blocks instead of Navigation layout.

2. ADDING
2.1 Add button (usability meeting)
Currently there is a single Add block button within the content region. There are three different perspectives to mind.
First you have the sighted user using the mouse. Based on the location one might assume that adding a block is exclusive for the content region.
When a keyboard user gets to the page, they first tab by the Skip to main content link, past the breadcrumb, then the Add default shortcut, then the Save button, then the Discard changes button, then the Show content preview checkbox, then the three context icons for each navigation block in the sidebar and then they finally reach the Add block button. Same as sighted mouse users they might be under the impression a block can only be added to the content region on top.
A screenreader user can confirm that assumption, the aural interface announces a link called Add block in section 1, content region. That information is only communicated implicitly visually and it is not clear what Section 1 refers to or what it actually implies? It looks like all default regions belong to the same Section 1. To add a block to the footer region a sighted or screenreader keyboard user first has to add a block to the content region, activate the block's Move action and finally change the region in the select field - a cumbersome process overall.

2.2 No indication how many times a nav/menu block was already being added
If you are adding a new block there is no indication in the off-screen tray if and in case how many times a block was already being added to the navigation layout.

2.3 Group labels (usability meeting)
The group labels are single words and missing sort of a context. In case someone with a small working forgets the off-screen tray title or someone else barley scanning, the context might be either missed or one has to recheck the title for reassurance, instead of having the context (blocks) in place. In addition the form of the two group labels is inconsistent, menus is in a plural form while navigation is in the singular form.

2.4 Group label rows are missing toggle icons
Currently the toggle icons signifying that block groups can be collapsed and expanded in the off-screen tray are missing. That way the block group bars are in lack of affordance. This fact is even more relevant on the configuration step when a block is being added, where the Menu levels group is collapsed by default and the available settings are hidden.

2.5 Difference between User and User account menu is unclear
You have the User block in the Navigation group and the User account menu block within the Menus group. Based on the labels it is not clear what their difference is and why there are two different blocks in two different categories with similar names. In addition it is not self explanatory what the difference between navigation blocks and menu blocks actually is and in case that difference matters to a certain degree.

2.6 Adding a second shortcuts block has different title
The title of the Navigation shortcuts navigation block added per default is Shortcuts. The title when another Navigation shortcuts navigation block is added, is Navigation shortcuts. So one block is called Shortcuts the other Navigation shortcuts, even though they are identical which might potentially confuse people.

2.7 Create content block (usability meeting)
The Create content block button is completely misplaced in the off-screen tray. It is creating an actual content block, the purpose of this step is about adding one of the already existing menu or navigation blocks instead.

3. CONFIGURING
3.1 There are two competing titles
First you have the total unspecific title Configure block in the headline and then another title Block description Main navigation where the information, the user is most interest in, is appended at the end. The user has to scan both lines to get and process all the necessary information, the cognitive load is high.

3.2 Description for menu levels is hard to understand
The point of reference for the menu levels is hard to comprehend. It is referred to that the menu is only visible if the menu link for the current page is at this level or below it. With a numeric scale in place my first association for "below 2" would be 1, 0, -1 or -2, but below means into the opposite direction by counting up.

4. MOVE
4.1 Remove "the" from the title

4.2 Clarify the purpose of the region select list
It might make sense to clarify the purpose of the region select list with a short description. Otherwise it might be potentially confusing in terms of point 4.3

4.3 Section 1 is redundant and front loaded
Section 1 is the label of the optgroup within the region select list and in addition for each available option Section 1 is front loaded. That is redundant and as already mentioned in 2.1 it is not clear what Section 1 refers and stands for. Does a Section 2 exist at all?

4.4 Section title Block label seems unspecific and imprecise
This setting is about the order of navigation and menu blocks within a certain region instead of the order of block labels.

4.5 Drag icon not inline and horizontal/vertical drag icons
The drag icons are horizontal/vertical drag icons even though the use is solely able to sort blocks vertically but not horizontally. The mouse cursor sticks to the pointer on hover instead of switching to the drag icon (ref #3389317: Differentiate visually dragging with and without hierarchy). And the drag icons are stacked onto the block labels instead of being displayed inline.

4.6 How to recognize the current block
In the off-screen tray, to recognize the current block you have to read/scan until (current) which is appended at the end of one of the block labels. There are no additional visual cues helping to distinguish the current block. The users only chance is to read/scan the list of all available labels. Plus the corresponding preview in the navigation sidebar has a way too strong black rectangle which is sort of an attention magnet.

5. REMOVE
The confirmation dialog might even go unnoticed. The user is triggering the removal of a navigation block in the contextual menu of one navigation block and has then to look across the entire screen to first notice and then reach the upper right corner of the window (also see point 1.4). The confirmation is not even in close spatial proximity nor would me as a user expect a confirmation dialog within the off-screen tray.

6. ACCESSIBILITY IN GENERAL
6.1 Quick edit buttons have a too low color contrast
Quick edit buttons are failing WCAG SC1.4.11. Hovering the block, the circle and the pencil both failing to reach a color contrast of 3:1, hovering the quick edit button itself, fails to reach the color contrast of 3:1 for the circle but the pencil reaches the required contrast. But that is a problem for core in general.

6.2

Add block/code> button has too low color contrast
The blueish background of the <code>Add block

button fails WCAG SC1.4.11. The button background is EEF6FC against FFFFFF which leads to a color contrast of 1.1:1. And the button itself is missing a change of color on hover and when active aka with a pressed mouse button.

6.3 Show content preview checkbox redundant and too verbose
Ticking or unticking the Show content preview button repeats "block previews are hidden block labels are visible" x number of times in a row in voiceover in macOS.

6.4 Aural interface for the navigation sidebar is challenging depending on if the preview is active or not.

6.4.1 Show content preview unticked
The only elements available in the AOM and the tabindex are the four quick edit buttons and the Add block button. Problem is that out of the box the output for the four quick edit buttons is for example:

open shortcuts configuration options, toggle button
open configuration option toggle button
open configuration option toggle button
open configuration option toggle button

The Add block“button” on the other hand is just a link.

6.4.2 Show content preview ticked
Same as 6.4.1 the four quick edit buttons and the Add block button are available in the tab-index, but with the preview of the navigation sidebar active all the top level menu items are available in the AOM alongside. In consequence if you open the rotor in VoiceOver you are able to go to the form control of for example Extend structure collapsed button, pressing the return button and you are able to expand the drawer for a second (but it collapses immediately right after). So technically all the top level menu items are available to a certain degree to screenreader users in the preview mode.

6.5 Landmark region labels are not necessarily clear
You have two complementary regions, one for the help text within the main landmark and the other wrapping the navigation sidebar, no matter if preview is active or not. The off-screen tray has no landmark region at all.

Steps to reproduce

Proposed resolution

1.1: @SKAUGHT is actively working on #3443556: Enhance Navigation admin workflow with Managed Tabs.

1.2: Not being hidden, the logo might function as another loophole to escape the lock-in alongside being a more exact preview of the navigation sidebar. Problem is that all links within the preview are disabled and the logo belongs to the preview.

1.3: The micro copy should be about informing the user that one is in the process of discarding recent changes to the set of navigation and menu blocks, not about the "layout builder tool" itself. The sidebar shouldn’t switch back to the full functional version.

1.4 & 1.5: One rough idea might be the following, when #2916876: Add visibility control conditions to blocks within Layout Builder gets in have a list table on the navigation layout page listing the different navigation layouts, for example one for administration roles and one for content editors. The navigation sidebar would be fully functional on that page. When you add or edit a layout the sidebar switches into the preview mode. That way it would be clear that the sidebar would be a preview then and on save the user would return onto the layout overview page with the full functional navigation sidebar. While editing or adding a layout one idea might be to move the off-screen tray right next to preview (not sure if that is possible or intended but it would avoid the huge cognitively challenging gap in-between the two sidebars).

1.6: Add styling for a navigation block on hover and use the vertical drag icon instead of the vertical/horizontal drag (see #3389317: Differentiate visually dragging with and without hierarchy)

1.8: Having the region labels shown all the time, the inherent structure within the sidebar would be clear and no matter if the content preview option is active it would be clear that the sidebar is a dysfunctional preview.

1.9: The suggestion here depends on the outcomes on #3443556: Enhance Navigation admin workflow with Managed Tabs.

2.1: During the usability meeting we’ve thought it would be a good idea to add an add button for every navigation region. But the probably cleaner approach might be to move the Add block outside the sidebar preview into the main content area. On the first step of adding a new block, add a select field to the off-screen tray letting the user select the region the block is being added to.

2.2: One approach might be adding a confirmation step asking the user something like are you sure you want to add the content block another time. The block is already used x number of times.

2.3: Change the group labels to Menu blocks and Navigation blocks

2.4: Display the toggle icons again

2.6: Rename the default title for the second added block from Navigation shortcuts to Shortcuts

2.7: Remove the Create content block button from the Add block flow in the off-screen tray

3.1: Remove the "sub title"Block description Main navigation and move it to the top bar front-loading the title changing it from Configure block to Configure administration block description

4.1: Strike "the" and simply use Move [title] block

4.5: Use the new icon for vertical dragging instead of the horizontal/vertical currently used (see #3389317: Differentiate visually dragging with and without hierarchy) and make the icon inline instead of block display. Plus change the mouse cursor on hover to it as well.

5: I wonder if the confirmation step for removing a block should be displayed in the main content area instead of displaying it inside the off-screen tray?

6.1: Increase the color contrast for the circle as well as the button to 3:1 for when a block is hovered and when then quick edit button is hovered.

6.2: Increase the background color of the button in contrast to the white background to at least 3:1 as well as add color variations on hover and when active that satisfies at least a color contrast of 3:1.

6.3: Avoid the repetitive announcement of "block previews are hidden block labels are visible" x-number of times.

6.4: In each case either with the preview hidden or the preview shown it would be important to add a context aka adding the title of the block to the quick edit toggle button. For screenreader users there is also the question if the preview functionality brings any additional benefit. Would a screenreader user inspect all the available top level menu items or not? In case they would it might be an idea to add something like the aria-disabled attribute to every top level menu item?

6.5: The landmark region for the help text might be dropped since that help text is contained within the main content area already. The complementary role might be considered to be added for the off-screen tray. To the aside element the preview is wrapped in an aria-label or aria-labeledby could be added with the label Navigation preview that is getting announced as Navigation preview complementary.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

If you have a token other than [node:summary] e.g. [node:field_name:summary] it does not seem to output anything.

Expected: [node:field_name:summary] outputs trimmed or summary of field (similar to [node:summary])

In contextual filters, with

• validator = taxonomy term
• Filter value type = term ids separated by , or +
• allow multiple values = true

Giving argument "1+2" works as expected: OR operator
Giving argument "1,2" works as "1+2": OR operator instead of expected AND operator

In both cases, conditions uses operator "IN"
WHERE (( (field_data_field_tags.field_tags_tid IN('1', '2') ) )AND(( (node.status = '1') AND (node.type IN ('flickr_photo')) )))

This is the contextual filter part of my view:

/* Contextual filter: Content: Tags (field_tags) */
$handler->display->display_options['arguments']['field_tags_tid']['id'] = 'field_tags_tid';
$handler->display->display_options['arguments']['field_tags_tid']['table'] = 'field_data_field_tags';
$handler->display->display_options['arguments']['field_tags_tid']['field'] = 'field_tags_tid';
$handler->display->display_options['arguments']['field_tags_tid']['default_action'] = 'empty';
$handler->display->display_options['arguments']['field_tags_tid']['default_argument_type'] = 'fixed';
$handler->display->display_options['arguments']['field_tags_tid']['default_argument_skip_url'] = 0;
$handler->display->display_options['arguments']['field_tags_tid']['summary']['number_of_records'] = '0';
$handler->display->display_options['arguments']['field_tags_tid']['summary']['format'] = 'default_summary';
$handler->display->display_options['arguments']['field_tags_tid']['summary_options']['items_per_page'] = '25';
$handler->display->display_options['arguments']['field_tags_tid']['specify_validation'] = 1;
$handler->display->display_options['arguments']['field_tags_tid']['validate']['type'] = 'taxonomy_term';
$handler->display->display_options['arguments']['field_tags_tid']['validate_options']['vocabularies'] = array(
  'tags' => 'tags',
);
$handler->display->display_options['arguments']['field_tags_tid']['validate_options']['type'] = 'tids';
$handler->display->display_options['arguments']['field_tags_tid']['validate_options']['transform'] = 0;
$handler->display->display_options['arguments']['field_tags_tid']['validate']['fail'] = 'empty';
$handler->display->display_options['arguments']['field_tags_tid']['break_phrase'] = 1;
$handler->display->display_options['arguments']['field_tags_tid']['not'] = 0;

Original summary
---

Title says it all, and per this ticket for Drupal 7:

https://www.drupal.org/project/views/issues/1433622

Problem/Motivation

The JSON:API spec states

A link object MAY also contain any of the following members:

• rel: a string indicating the link’s relation type. The string MUST be a valid link relation type.

The linked RFC 8288 describes a valid extension link relation type:

Applications that don't wish to register a relation type can use an
extension relation type, which is a URI [RFC3986] that uniquely
identifies the relation type.

However, LinkCollection::validKey() validates link relation types using a custom-ish(?) method which disallows colons. Colons are valid in URIs, including URNs.

Steps to reproduce

Attempt to utilize a link relation type with a colon, e.g. urn:kinksters-link:cancel.

Proposed resolution

Validate the link relation type per the ABNF in the HTTP linking RFC.

Remaining tasks

Do the thing, add test coverage for this.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Not necessary?

Problem/Motivation

I'm trying to import my configuration into a new project.

When I try to import the configuration via "drush cim" I get the following error. Then the import cannot be completed.
Any idea ,please.. Thanks

[warning] Undefined array key "moderation_state" BaseFieldOverride.php:180
 [error]  Error: Call to a member function getFieldStorageDefinition() on null in Drupal\Core\Field\Entity\BaseFieldOverride->getFieldStorageDefinition() (line 120 of /var/www/html/mysite/web/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php) #0 /var/www/html/mysite/web/core/lib/Drupal/Core/Field/FieldConfigBase.php(373): Drupal\Core\Field\Entity\BaseFieldOverride->getFieldStorageDefinition()

#1 /var/www/html/mysite/web/core/lib/Drupal/Core/Field/FieldConfigBase.php(289): Drupal\Core\Field\FieldConfigBase->getSettings()
#2 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(430): Drupal\Core\Field\FieldConfigBase->postCreate()
#3 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(357): Drupal\Core\Config\Entity\ConfigEntityStorage->_doCreateFromStorageRecord()
#4 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/ConfigImporter.php(1068): Drupal\Core\Config\Entity\ConfigEntityStorage->importCreate()
#5 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/ConfigImporter.php(851): Drupal\Core\Config\ConfigImporter->importInvokeOwner()
#6 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/ConfigImporter.php(672): Drupal\Core\Config\ConfigImporter->processConfiguration()
#7 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/ConfigImporter.php(570): Drupal\Core\Config\ConfigImporter->processConfigurations()
#8 /var/www/html/mysite/vendor/drush/drush/src/Commands/config/ConfigImportCommands.php(259): Drupal\Core\Config\ConfigImporter->doSyncStep()
#9 /var/www/html/mysite/vendor/drush/drush/includes/drush.inc(62): Drush\Commands\config\ConfigImportCommands->doImport()
#10 /var/www/html/mysite/vendor/drush/drush/includes/drush.inc(53): drush_call_user_func_array()
#11 /var/www/html/mysite/vendor/drush/drush/src/Commands/config/ConfigImportCommands.php(230): drush_op()
#12 [internal function]: Drush\Commands\config\ConfigImportCommands->import()
#13 /var/www/html/mysite/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#14 /var/www/html/mysite/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#15 /var/www/html/mysite/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#16 /var/www/html/mysite/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#17 /var/www/html/mysite/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#18 /var/www/html/mysite/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#19 /var/www/html/mysite/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#20 /var/www/html/mysite/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#21 /var/www/html/mysite/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#22 /var/www/html/mysite/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#23 /var/www/html/mysite/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#24 /var/www/html/mysite/vendor/drush/drush/drush(4): require('...')
#25 /var/www/html/mysite/vendor/bin/drush(119): include('...')
#26 {main}. 
Error: Call to a member function getFieldStorageDefinition() on null in /var/www/html/mysite/web/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php on line 120 #0 /var/www/html/mysite/web/core/lib/Drupal/Core/Field/FieldConfigBase.php(373): Drupal\Core\Field\Entity\BaseFieldOverride->getFieldStorageDefinition()
#1 /var/www/html/mysite/web/core/lib/Drupal/Core/Field/FieldConfigBase.php(289): Drupal\Core\Field\FieldConfigBase->getSettings()
#2 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(430): Drupal\Core\Field\FieldConfigBase->postCreate()
#3 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityStorage.php(357): Drupal\Core\Config\Entity\ConfigEntityStorage->_doCreateFromStorageRecord()
#4 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/ConfigImporter.php(1068): Drupal\Core\Config\Entity\ConfigEntityStorage->importCreate()
#5 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/ConfigImporter.php(851): Drupal\Core\Config\ConfigImporter->importInvokeOwner()
#6 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/ConfigImporter.php(672): Drupal\Core\Config\ConfigImporter->processConfiguration()
#7 /var/www/html/mysite/web/core/lib/Drupal/Core/Config/ConfigImporter.php(570): Drupal\Core\Config\ConfigImporter->processConfigurations()
#8 /var/www/html/mysite/vendor/drush/drush/src/Commands/config/ConfigImportCommands.php(259): Drupal\Core\Config\ConfigImporter->doSyncStep()
#9 /var/www/html/mysite/vendor/drush/drush/includes/drush.inc(62): Drush\Commands\config\ConfigImportCommands->doImport()
#10 /var/www/html/mysite/vendor/drush/drush/includes/drush.inc(53): drush_call_user_func_array()
#11 /var/www/html/mysite/vendor/drush/drush/src/Commands/config/ConfigImportCommands.php(230): drush_op()
#12 [internal function]: Drush\Commands\config\ConfigImportCommands->import()
#13 /var/www/html/mysite/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#14 /var/www/html/mysite/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#15 /var/www/html/mysite/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#16 /var/www/html/mysite/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#17 /var/www/html/mysite/vendor/symfony/console/Command/Command.php(326): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#18 /var/www/html/mysite/vendor/symfony/console/Application.php(1096): Symfony\Component\Console\Command\Command->run()
#19 /var/www/html/mysite/vendor/symfony/console/Application.php(324): Symfony\Component\Console\Application->doRunCommand()
#20 /var/www/html/mysite/vendor/symfony/console/Application.php(175): Symfony\Component\Console\Application->doRun()
#21 /var/www/html/mysite/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#22 /var/www/html/mysite/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#23 /var/www/html/mysite/vendor/drush/drush/drush.php(139): Drush\Runtime\Runtime->run()
#24 /var/www/html/mysite/vendor/drush/drush/drush(4): require('...')
#25 /var/www/html/mysite/vendor/bin/drush(119): include('...')
#26 {main}

Error: Call to a member function getFieldStorageDefinition() on null in Drupal\Core\Field\Entity\BaseFieldOverride->getFieldStorageDefinition() (line 120 of /var/www/html/mysite/web/core/lib/Drupal/Core/Field/Entity/BaseFieldOverride.php).
 [warning] Drush command terminated abnormally.

If you try to use #ajax on a Views exposed filter form element, the callback is never invoked. This was discussed at length in the Views issue queue here:

#1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback

The same bug exists in the version of Views in Drupal 8 core. As merlinofchaos wrote:

Views are $_GET forms and they specifically remove the form_id and form_build_id and form_token because they are 'submitted' even when they aren't submitted. That means the standard #ajax tools don't work with them, since those rely on being able to cache the form in core's form cache. That system is to naive to work with core's filters. I've never really tried to do anything like this in D7 yet, so I don't know what the solutions might be, but I can say that it's going to provide very ugly URLs if you hack the form id back in.

The proposed solution is to add a little custom JS magic so that we identify all the form info via after_build callbacks, stash those in JS settings, and then inside the JS, we reattach the relevant form info to the #ajax-enabled form elements so that their callbacks can be properly invoked.

When you add a datelist field, the Years available range from 1900 to 2050.

For many uses, that's unnecessarily broad.

It'd be good to be able to configure the range in the manage form display interface.

E.g. to +/- 3 years, or min 2010 and max 2020, etc.

I think Drupal 7 had this feature.

API page: https://api.drupal.org/api/drupal/modules!node!node.pages.inc/function/n...

Enter a descriptive title (above), then describe the problem you have found:

As noted by the title, I discovered today that there are no longer any legacy comments on Drupal 7.X API documentation. As you know, there are still a very large amount of organizations that still use Drupal 7. To lose the historical context of these comments is a large detriment to institutions/companies that still rely on it.

Can you please revert that change in your database to include those comments? Example:

https://web.archive.org/web/20210506192654/https://api.drupal.org/api/dr...

Thank you for your consideration.
Juan

Problem/Motivation

Whenever a new revision is created from Published (to Draft), a private files field we have on the node loses the reference to the file. This happens on all users EXCEPT user 1.

The private file system is set up correctly and all users with access are able to view the files when a node is published.

We also have the group module installed which handles permissions in addition to Core on this content type. We believe that this problem might be a permissions issue since user 1 does not have the problem?

Additionally, we are using content moderation for this node type and have workflow buttons set up as well to handle the transitions between content moderation states.

We do have ECA running some tasks in the background depending on the different states in content moderation for this content type but didn't think that was causing this issue.

To be honest, we are not sure where to start to find out where this problem is originating from. It seems like a content moderation issue due to the nature of the problem, but it could be something unrelated and tied to something else like revisions. How do we start to determine the cause of the problem?

Steps to reproduce

We have a content type Article that has a private files field set up. Go into any node that has an attachment in that field and is published. Create a new draft. The new revision has no attachments in the field now.

Proposed resolution

We found that a record was not being inserted into the table for the node revision for that field, and that's why the field loses reference to the file. The file still remains in the private files folder as well. However, we do not know why the record is not being added to that table.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

If you visit a D8 site as an authenticated user and add a query string parameter which includes a quotation mark, then a JavaScript error will be thrown.

E.g. go to /search?keywords=it's

Error:
Uncaught DOMException: Failed to execute 'querySelectorAll' on 'Document': '[data-drupal-link-system-path="search"]:not([hreflang])[data-drupal-link-query='{"keywords":"it's"}'],[data-drupal-link-system-path="search"][hreflang="en"][data-drupal-link-query='{"keywords":"it's"}']' is not a valid selector.

This does not effect anonymous users as the core/drupal.active-link library is only attached if the current user is authenticated.

If you make a link with an apostrophe-including query like this

Then these are the attributes that the JS in active-link.js need to find

The above can be used as the basis for tests, too.

Problem/Motivation

After updating Drupal 10 site from version 10.0.11 to 10.2.1 , getting drupal ajax error on adding media, blocks from layout builder. Also quick edit links are disappeared from blocks ,menus etc

Steps to reproduce

I checked on Drupal 10.2.2

• Open layout builder page (as /node/xxxx/layout)
• Enabled browsder debug tool
• When mouse-over to block, pencil icon is showed at right
• Click the pencil icon, click the delete option, then check the console, below error occured

An error occurred during the execution of the Ajax response: TypeError: Cannot read properties of undefined (reading 'style')

• And right pane showed the opition button about `delete` or `cancel`, push the `cancel` button
• After that, then check the console, below error occured

Uncaught TypeError: Cannot read properties of undefined (reading `style`)

• And click the pencil icon click the delete option again, the right pane is not showed unless you reload the page

Proposed resolution

The reason why this error is in off-canvas.js, because the style property is not exsisted in jQuery type.

https://git.drupalcode.org/project/drupal/-/blob/6a43b511df9e26aa5abf0d1...

• To change the type of $mainCanvasWrapper to NodeListOf and handle when the element is undefined. (I understand the refactor of jQuery css() to use Vanilla (native) that is good things.)
• Or Revert https://git.drupalcode.org/project/drupal/-/commit/6a43b511df9e26aa5abf0...

Remaining tasks

Nothing

User interface changes

Nothing

API changes

Nothing

Data model changes

Nothing

Release notes snippet

Problem/Motivation

Follow-up to #2673980: RSS view with fields give wrong URL from path field

If you have a view providing an RSS feed and you configure it to display fields, you must specify the field you want to use for the item links. The most obvious choice is the 'Link to content' field (plugin ID: view_node).

The description of the link field says

The field that is going to be used as the RSS item link for each row. This must be a drupal relative path.

Nevertheless the 'Use absolute link' option is tempting as it seems like a reasonable choice for an RSS feed), and if you select it then your feed will be broken:

If you revert commit 69e0b9feb, your site blows up with an uncaught exception:

[25-Oct-2019 23:57:47 UTC] Uncaught PHP Exception InvalidArgumentException: "The internal path component 'http://localhost/drupal-8_9/pt-br/node/2' is external. You are not allowed to specify an external URL together with internal:/." at /Applications/MAMP-common/htdocs/drupal-8_9/core/lib/Drupal/Core/Url.php line 411

If you leave commit 69e0b9feb in (from #2673980) then your feed gets links like so:

http://localhost/http://localhost/drupal-8_9/pt-br/node/2

Broken in both cases. Needs a fix.

Proposed resolution

First we need to understand why this description was put in - maybe there is a good reason.

Option A: Remove the description requiring an relative URL and fix the logic to handle absolute URLs.
Option B: Print a clearer warning if absolute URLs are enabled and explain it's not allowed.

Remaining tasks

1. Decide what to do
2. Write tests
3. Write code
4. Review
5. RTBC
6. Commit

User interface changes

TBD.

API changes

None.

Data model changes

None.

Release notes snippet

TBD.