Adding media field on entity and marking it as required does not show proper validation message.

1. Steps to reproduce the bug

• Add media field in page content type, and mark this as required.
• Try creating page content, fill title & body and leave media as blank.
• Click Save button.
• It will give you message "This value should not be null"

• It should give proper message like "Media field is required."
• It should also highlight the field which has error.

• It gives message "This value should not be null".
• It does not highlight the field with error.

I have a Field API field and I have attached it to an entity. This field has multiple fields in it. When I submit the form without all fields filled I get the "This value should be of the correct primitive type." error.

Is this a bug or am I doing something wrong? I was having trouble with serialized field for storing metadata but I've been able to get around it by setting it to computed field. But I cannot do that in this case.

Steps to Reproduce
I found this bug in branch 8.0.x and 8.1.x
PHP 5.6.14

Follow these steps to reproduce the problem.

1. Applying actual patch from #1014816: Allow image fields to use any extensions the current image toolkit supports (instead of hard-coding jpg, png and gif only)
2. Install and enable ImageMagick
3. Go to configuration module and set enable svg
4. Go to modification any image field, add svg to allow extension
5. Try add svg image to any node

Hi ,

I am facing below issue on REST POST node create on multi-domain site with single database, I have 3 sites in one setup, the REST POST API working for only one site in multi-site, for other two sites its giving below error, kindly please help on the same.

Client error: `POST http://example.com/entity/node?_format=hal_json` resulted in a `422 Unprocessable Entity` response: {"message":"Type http:\/\/example.com\/rest\/type\/node\/article does not correspond to an entity on this sit (truncated...)

Problem/Motivation

We need to have all configuration that a user can define, which has translatable information on it, to be translatable in the Configuration Translation module's user interface.

There are several pieces of information from the Entity/Field system, which may include translatable strings, but which are not translatable using the Config Translation UI:

a) Field settings. For instance, on a Number field, there are translatable settings for the Prefix and Suffix in the settings config. But if you go to the Translate page for the field, all you can translate is the Label and Help for the field, not the prefix/suffix.

===> This is because the schema is wrong. See #2546356: Numeric field prefix/suffix settings should be translatable. Fields are translatable along with their settings, supposedly anyway.

b) Entity view displays - field formatter settings. For instance, on #2449597: Number formatters: Make it possible to configure format_plural on the formatter level we are adding the ability to numbers to have formatPlural() type formatting, but there is no way to translate the "1 item/@count items" strings. These are stored on the entity view display config items.

c) Entity form displays - widget settings. For instance, many text fields have widget options to enter Placeholder text, and obviously this would need to be translated. These are stored on the entity form display config items.

d) Base field overrides, which seem to include labels.
==> will do this on a separate issue

The technical reason is, at least for the entity view/form display formatter/widget settings, that there is not an edit form for these things -- the config schema indicates they should be translatable, but there's no way to edit them so config translation module doesn't put up a UI for translating them either. They are settings that appear as part of the Manage Form or Manage Display pages in Field UI, but the individual fields do not have their own settings forms.

Comment #5 also looked at other config items to see if they were translatable and #8 discussed them; more issues will be open.

How to test

1. Use core version applicable to the patch and apply the patch
2. Configure Article node type with a boolean field, displayed in Default view mode using custom texts
3. Enable Configuration Translation module (/admin/modules)
4. Add at least one language (/admin/config/regional/language)
5. Go to configuration translation page (/admin/config/regional/config-translation)
6. Click on List button for Content view display
7. Click on Translate button for Default view mode for Articlecontent type
8. See what is on the configuration translation form for the ArticleDefaultview mode
9. @todo - Add more steps for translating specific configuration

Proposed resolution

Make sure that these items have a translation UI.

Remaining tasks

Figure out how to make them translatable. Maybe add tests too?

User interface changes

You'll be able to translate your site. Can't now.

API changes

Probably not, but we'll have to see what the patch entails.

Data model changes

I wouldn't think so.

Problem/Motivation

We still have a few references to XCache in the codebase. XCache seems dead; the website http://xcache.lighttpd.net/ no longer works and https://en.wikipedia.org/wiki/List_of_PHP_accelerators reports that it was only compatible up to PHP 5.6, which we no longer support.

Steps to reproduce

Proposed resolution

Remove all references to XCache.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

At the moment, Content Moderation and Quick Edit are incompatible. Quick edit is not integrated into revisions of entities that are the latest revision.

For example, enable moderation on an entity bundle, publish a draft, then create a new draft of that entity, visit the latest version tab witness the lack of quickedit options.

You can view a screencast showcasing the current problems here: https://www.youtube.com/watch?v=gvnXaT7HCeU

Proposed resolution

There are a number of steps that need to happen to make these modules work together:

1. Load the latest revision of an entity for routes that deliver quickedit form components.
2. Ensure that Contextual Links display on the latest revision of a Node. Otherwise Quick Edit will be inaccessible to users.

Latest patch in action:

Remaining tasks

Review the provided patch.

1. Create a follow up to add configuration form to Quick Edit or Content Moderation that restricts user's ability to edit content in certain states. (I think the existing permissions already cover this?)

User interface changes

Additional edit and quick edit contextual links rendered on the latest version of an entity.

API changes

An additional contextual link "group" exclusively for the latest version of an entity.

Data model changes

None.

Problem/Motivation

BlockPluginInterface::build() is documented as always returning an array.
When implementations do not return an array, the resulting bugs range from subtle errors to fatal whitescreens

Proposed resolution

Add return types to core block ::build() methods, add a deprecation warning to ::build() methods discovered without a return type, enforce the return type in Drupal 10.

Remaining tasks

None

User interface changes

N/A

API changes

BlockPluginInterface::build() will require an array return type from Drupal 10.

Data model changes

N/A

Release notes snippet

Custom block plugins should now add the "array" return type to the ::build method.

Problem/Motivation

The ::build() method has always been documented as returning an array.
#3164389: Enforce block plugins returning an array added deprecation warnings for code that doesn't return an array.
This issue should add the actual return type.

Proposed resolution

Add : array to ::build()
Remove the trigger_error from BlockManager::processDefinition()

Remaining tasks

TBD

User interface changes

N/A

API changes

Enforcing the change documented in https://www.drupal.org/node/3164649

Data model changes

N/A

Release notes snippet

TBD

Problem/Motivation

In Claro, the autocomplete field throbber is showed based on a fixed timeout currently set at 400ms. This doesn't correspond to the actual length of the ajax request, which could lead into either loading animation not being visible when the autocomplete widget is still waiting for the ajax response, or the loading animation being visible when the autocomplete widget already got a response.

Steps to reproduce

1. Navigate to a page with autocomplete, for example /admin/structure/views/add
2. Enable network rule with a high latency to ensure that the ajax request takes longer than 400ms
3. Confirm that the throbber is not visible after 400ms, even though the ajax request isn't complete

Proposed resolution

Make the autocomplete field throbber and loading text correspond to the ajax request length.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Some buttons pushed to the right side of the toolbar, such as edit and tour, are positioned there in a manner that results in their appearance differing from the DOM order.

Steps to reproduce

Enable several modules that add toolbar buttons. Include tour and quickedit. Tab through the toolbar and notice how focus does not occur in the order the buttons appear.

Proposed resolution

Set the toolbar-bar to display: flex so floats are not necessary.
Add a property to '#type' => 'toolbar_item' that provides the option of placing the item on the right side of the toolbar.
In a preprocessor (or somewhere else suitable), sort the array of toolbar items and place the ones with that new property on the end.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Toolbar module has a number of accessibility issues. Some of these may be addressed individually in child issues, but it will be a good idea to consider them holistically.

Known problems

Visual design

• #3097907: Active toolbar tray has weak affordance and fails WCAG colour criteria
• #3097905: Add visual indicator to show which toolbar buttons have trays associated with them
• Confusing visual focus order. MAJOR. Visually, the top level toolbar has some buttons which appear on the right hand side (e.g. edit, tour). The DOM order differs from the visual presentation, so focus order jumps around in a way that's confusing for sighted users. Effectively a failure of WCAG success criterion 2.4.3 Focus Order (level A). Aim to find an order which is usable by screen reader users and sighted users. #3167438: Presentation of some toolbar buttons differs from DOM order
• Missing icons in Windows high-contrast mode. The icons are CSS background images, which don't work when a Windows' high-contrast theme is enabled. Internet Explorer and Firefox both strip CSS background images out, but Edge displays them. (Other browsers don't respect Windows high-contrast mode at all, which is something beyond our control). This issue can be addressed by using an alternative technique such as inline <img>/ <svg>, or the CSS content property.

  However some buttons are badly broken, because visually they are just an icon. When the icon is missing users can't perceive or understand the button:

  • Many cases are OK, because the icon is accompanied by a visible text label. When the icon is missing, the link or button is still perceivable because the text label remains. It would be better if the icons weren't missing.
  • Switch toolbar orientation. Visually this is just an icon. In high-contrast mode, when the icon is missing, users may be completely unaware that the toolbar orientation can be changed, or can't find how to do it. MAJOR, fails WCAG SC 1.1.1 Non-text Content (level A) for the high-contrast scenario.
  • Sub-menu buttons in vertically-orientated trays. Visually this is just an icon. In high-contrast mode, when the icon is missing, users may not understand the hierarchy of an open menu, and may be completely unaware that more links can be disclosed. MAJOR, fails WCAG SC 1.1.1 Non-text Content (level A) for the high-contrast scenario.

Assisitive technology and Semantics

• #3066954: Admin toolbar not usable with latest versions of JAWS due to mis-use of aria-owns. CRITICAL. Fixed in 8.7.9.
• #3085781: aria-pressed attribute isn't updated correctly.. MAJOR.
• #3085811: Toolbar buttons should respond to spacebar key. These are <a href="" role="button"> which only responds to the return key. It needs an extra keyboard handler. Spotted in #3066954: Admin toolbar not usable with latest versions of JAWS due to mis-use of aria-owns.
• #3090120: Use ARIA disclosure pattern for Toolbar buttons with trays
• #3093378: Use ARIA disclosure pattern for submenu buttons in vertical toolbar orientation
• Too many ARIA group/landmark roles. The toolbar uses lots of ARIA navigation landmarks. In general, it's a good idea to avoid using to many landmark regions because it reduces their usefulness. They are used to quickly navigate between major regions of the page, and too many of them can make it tedious to cycle among them.
  • Consider just using a single navigation landmark for the entire toolbar, and eliminate the nested ones. Possibly use another non-landmark grouping role inside the toolbar. The nested menus already have
  • The toolbar is wrapped by an ARIA group (not a landmark) and a navigation role, each with their own label. This double wrapper doesn't serve much purpose, it merely increases verbosity.
• Navigation landmark regions without accessible names. When a page has multiple landmark regions of the same kind, they should be distinguishable by name.
  • Toolbar has some navigation landmarks with accessible names. For example, in the second-level toolbar "trays" with menus: manage, shortcuts, and user.
  • However is also has unlabelled navigation landmarks too. For example there the home, "back to site", tour, and edit items.
• Empty navigation regions. Some navigation landmark regions are present, but are empty. This is pointless, and may be confusing because they appear in a screen reader's list of landmarks. They are associated with top-level toolbar items which don't have a second-level tray.

Problem/Motivation

The order of the media items is messed up when using Media Library widget in a particular use-case (when arranging the media items and after that inserting a new media).

Steps to reproduce:
1. Create a Content Type with an unlimited media reference field.
2. In form display for that field chose the Media library widget.
3. Add new content of that Content Type.
4. In the media field add more than 3 media items.
5. Save the node.
6. Go to the edit page of that node.
7. Re-arrange the media by drag and drop.
8. Press the "Add Media" button.
9. Select a new image to insert and press the "Insert Selected" button.
10. The media items will be ordered correctly but their weights will be messed up. You can look at them by pressing "Show media item weights".
11. Save node.

Expected behavior:
The order of the media should remain the way it was arranged before inserting a new image and the new image should be the last one.

Current behavior:
The media items order is not the way it was arranged.

Proposed resolution

I didn't find what was the cause of this problem but one of the solutions/workarounds will be to get the weights from the $field_state (which are the correct ones) and put them in the $element in the updateWidget memthod.

Remaining tasks

Add tests.

Postponed on #1899236: Add new Splitbutton render element to eventually replace Dropbutton

Problem/Motivation

The splitbutton render element, added in #1899236: Add new Splitbutton render element to eventually replace Dropbutton, can be easily configured to function as a dropdown, by adding a #title property. This is probably not besomething that would be immediately apparent, so it would benefit DX to create a 'dropdown' render element that extends splitbutton and always uses the #title property. This new render element could also provide classes so it is not styled like a standard button, which is how splitbuttons are styled.

As a clarification the difference between dropdown and a select input is that the items within 'dropdown' would not be a list of values to select from, but a combination of links, inputs, and buttons.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The render system has \Drupal\Core\Render\RenderCache(Interface). This is capable of doing cache redirects, based on bubbled cache contexts. I.e. compare the originally known cache contexts with those that the final-to-be-cached data depends upon, and if that set is different, cache it as a cache redirect. (See RenderCache's docs for details.)

This is useful outside of the render system too.

Proposed resolution

Abstract RenderCache into a service (name TBD, initial quick thought: RedirectingCache) that RenderCache can use, so that RenderCache is just one of many things able to use this generic concept.

Remaining tasks

TBD

User interface changes

None.

API changes

None, pure API addition.

Data model changes

None.

Problem/Motivation

In #3020422: Toolbar style update, it was observed that the workspace button has a less-than-appealing focus effect

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

(Originally submitted by saschaeggi on Github)

Problem/Motivation

Recent interviews and research exposed pain points around Drupal's admin experience of looking and feeling dated.

Proposed resolution

Implement new Toolbar design to create a favorable first impression of Drupal for evaluators and a better user experience for site authors. No functional differences.

Specification

Quick overview

This image is just a quick overview for Navigation list specs. Please use the Figma link to full specification as the main resource for specs.

Full specification

FIGMA: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Design-system?node-id=3324%3A0

This link is anchored to the board with the full specification. As an anonymous user you can see the design, but to actually be able to pick colors and sizes please login on Figma.

Remaining tasks

• Update patch styling to include time inputs
• Accessibility review
• RTL review (Right to Left)

User interface changes

No functional differences.

Test Pages

/admin/

Problem/Motivation

There is no need to use t() in tests, unless we're testing translations, however in core we do not follow this consistently, which does not set a good example for new contributions.

In #3133726: [meta] Remove usage of t() in tests not testing translation we identified there are severals of calls to t() in calls to linkExists() and linkNotExists() and that removing all these in one go seems to be a suitable way of attacking this problem.

Proposed resolution

Identify and remove all calls to t() wrapped in calls to linkExists() and linkNotExists(), except those used by translation-related code (if any).

Create a list of Test files using t() by find core -type f -iname '*Test.php' | xargs grep '[^a-zA-Z]t('> remove_t_list.txt, then search that list for linkExists and linkNotExists.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the action module(s).

The topics to cover:
- Configuring actions using the action module -- see #2811663: Rename Action module to Actions UI in the UI and in comments -- this module may be renamed to Action UI
- What actions are used for: They can be triggered by other modules. Also when you create a View the actions that are configured for the base table can be configured as a Bulk Operations "field". This needs to be explained. So we need a topic about adding bulk operations to a view, linked to the actions topic.

This was spun off from #3041926: Convert automated_cron, ban, dblog, syslog, system, update, and user module hook_help() to topic(s) and should wait until #3047723: Convert views, views_ui module hook_help() to topic(s) is done.

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

If you visit /index.php.php path, the PHP warning occurs and a log record is created:

Notice: Undefined offset: 1 in template_preprocess_html() (line 1343 of core/includes/theme.inc).
template_preprocess_html(Array, 'html', Array) (Line: 287)
Drupal\Core\Theme\ThemeManager->render('html', Array) (Line: 431)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 200)
Drupal\Core\Render\Renderer->render(Array) (Line: 147)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 573)

Steps to reproduce

1) First case: Visit your.site/index.php. or your.site/index.php.php

2) Second case:

1. Clean Drupal installation
2. Go to admin/structure/block, edit any (for example: Search) block that appears on the frontpage
3. Go to pages tab and set /user/* and click "Show for the listed pages"
4. Go to your.site/index.php.php
5. There is an exception: InvalidArgumentException: Source path .php has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 229 of core/lib/Drupal/Core/Path/AliasManager.php).

Proposed resolution

1) Adjust Drupal\system\Plugin\Condition\RequestPath to request a path with a slash.
2) Fix template_preprocess_html() so it doesn't show a warning if there is an extra dot when resolving route path.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Let's say we have CT with several fields. These fields are shown. Then on display settings we enable Layout Builder and manage display via its functionality. But formatters for our fields are executed anyway, because we haven't moved our fields to Disabled section. Because buildMultiple() function calls parent's one and then generates sections. Then it removes fields from build list, if sections are generated. If we have many fields, this results into performance hit, because first we build all enabled fields and then, in case layout builder is used, we remove these fields. Of course, this problem can be solved by disabling layout builder, moving all fields to Disabled section, save configuration, then enable layout builder again. But this is not user friendly and content manager can easily miss this step.

Steps to reproduce

Create CT and add some fields. Make sure these fields are enabled in default display. Check, if Layout builder is enabled and go to display settings. Check option for using layout builder and save configuration.

Proposed resolution

Change code of buildMultiple() function to not call parent's one in all cases, but only, if necessary.