Use case: image field set to unlimited, but you only want to show the first on a teaser view. Inspired by http://realize.be/limit-number-fields-display-field-ui-display-suite and #1234618: Limit the number of fields to display. Patch forthcoming for Drupal core.

Problem/Motivation

Our tests use things that are deprecated in Twig 2.x or that we discourage people in contrib and so on from doing.

Why this is RC eligible

It only changes tests.

Proposed resolution

Fix them.

Remaining tasks

Patch
Review

User interface changes

n/a

API changes

None

Data model changes

None

Pages are not shwoing up with the follwoing error:

InvalidArgumentException: Cannot redirect to an empty URL. in Symfony\Component\HttpFoundation\RedirectResponse->setTargetUrl() (line 86 of /home/progonat/public_html/domain.com/vendor/symfony/http-foundation/RedirectResponse.php).

On page:
The website encountered an unexpected error. Please try again later.InvalidArgumentException: Cannot redirect to an empty URL. in Symfony\Component\HttpFoundation\RedirectResponse->setTargetUrl() (line 86 of vendor/symfony/http-foundation/RedirectResponse.php).

I also noticed that the LOGO and HOME in the main menu do not redirect to the front page but instead they redirect to the current page, which is not correct.

Any help or insight will be greatly appreciated.

Problem/Motivation

Steps to reproduce:

Add an entity reference field for nodes (Content) on a Custom Block type
Add an entity reference field for Custom Blocks on a node type
Enable Layout Builder
Go to the "Manage Layout" UI for the node's content type

Expected:

The Layout Builder UI

Actual:

Fatal error: Maximum function nesting level of '256' reached, aborting!

This is reproducible in more complex ways without Layout Builder, but it's usage of sample entities is the easiest approach.

The generateSampleValue() method for entity reference creates new sample entities if none are available.
It has rudimentary recursion protection in place by not allowing one entity type to reference itself.
It does not have any protection against circular references.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

I had File Types, before starting to use 8.5.1 Media module.

I was using these contrib mod, then wanted to start using Media module in core. I updated db before enabling media module.

• "drupal/file_browser": "dev-1.x",
• "drupal/entity_embed": "dev-1.x",
• "drupal/entity_browser": "dev-1.x",
• "drupal/file_entity": "^2.0@beta",

When I go to /admin/structure/media/add to add a new image type (there are none currently), on submit I get this error.

The website encountered an unexpected error. Please try again later.

Error: Call to a member function getName() on null in Drupal\media\MediaSourceBase->prepareFormDisplay() (line 350 of core/modules/media/src/MediaSourceBase.php).
Drupal\media\MediaSourceBase->prepareFormDisplay(Object, Object) (Line: 362)
Drupal\media\MediaTypeForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 585)
Drupal\Core\Form\FormBuilder->processForm('media_type_add_form', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm('media_type_add_form', Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 664)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Then, when I go to the media type page, I can see my new type. If I click edit I get:

The website encountered an unexpected error. Please try again later.
Error: Call to a member function getLabel() on null in Drupal\media\MediaSourceBase->buildConfigurationForm() (line 199 of core/modules/media/src/MediaSourceBase.php).
Drupal\media\MediaSourceBase->buildConfigurationForm(Array, Object) (Line: 159)
Drupal\media\MediaTypeForm->form(Array, Object) (Line: 117)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 514)
Drupal\Core\Form\FormBuilder->retrieveForm('media_type_edit_form', Object) (Line: 271)
Drupal\Core\Form\FormBuilder->buildForm('media_type_edit_form', Object) (Line: 74)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 664)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Then, If I rather click Manage Fields, I am able see the field Image (field_media_image) and can edit this.

Not sure what to do about these errors?

It's possible to get into a situation in which a content type with a content moderation workflow is not set to allow new revisions and cannot be changed in the UI.

To reproduce:

Create a content type and do not set it to Create new revision.
Now add a workflow that applies to the content type with content moderation.
Now edit the content type again and see that 'Create new revision' is now checked and disabled.
Save the content type again, to make sure that the 'create new revision' setting is applied.
Export your config.
Your node.type config will say 'new_revision: false'

I ran into this because I was trying to figure out why users who did not have permission to administer content did not get the revision log field when editing a node. It was because the content type was set to new_revision: FALSE, and there was no way for me to change it in the UI.

I believe the solution would be that when you enable moderation for a content type that the configuration for that content type needs to be updated to turn on revisions. The disabling and checking of the field in NodeModerationHandler::enforceRevisionsBundleFormAlter is cosmetic only.

(I'm just going to update my config manually to resolve, but it's clearly a bug)

Problem/Motivation

When using the form element checkbox, it is possible to disable the element but having its value remain checked. This is used, for example, on the module overview page, where it is possible to check more modules, but impossible to uncheck already enabled modules:

The same functionality is needed when using the form element "checkboxes". Currently, when an option of the checkboxes is disabled, it is saved as unchecked, even when it was set as default value as checked

Steps to reproduce

Case 1

This case is covered by the test added in #7 and is fixed by the patch added in #26.

• Configure a block to be only visible on articles
• Add this hook to block.module
  

  function block_form_block_form_alter(&$form, \Drupal\Core\Form\FormStateInterface $form_state, $form_id) {
    $form['visibility']['node_type']['bundles']['article']['#disabled'] = TRUE;
  }
     

• Go back to the block configuration form -- see that article is disabled but selected
• Save the block configuration again, without any changes
• Go back to the block configuration form -- see that article is disabled but NOT selected

Case 2

This case is not yet covered by tests and is not yet fixed.

1. Add a field to article, as follows:
   • Field type: boolean
   • Field label: My Field
   • Save and continue
   • Set number of values to unlimited
   • Save field settings
   • Leave all settings, and click Save settings
2. Configure the Manage form display
   • to use the widget "Checkboxes/radio buttons".
3. Add this line of code as the last line in book_form_node_form_alter
   

      $form['field_my_field']['widget'][0]['#disabled'] = TRUE;
      

4. Enable the book module
5. Add an article, view the form -- see that the first option is disabled but selected
6. Submit the node form.
7. Edit the new article node -- see that the first option is disabled but NOT selected

Proposed resolution

Ensure that disabled checkboxes values are not saved or their values persist.

Remaining tasks

1. Manually test to confirm
2. Write Tests to reproduce
3. Fix bug

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

When using the timeago formatters on datatime fields, the setting summary does not display properly on the Manage Display page. This was likely a side effect of #2500525: Time ago/hence date/time formatting breaks caching; needs appropriate max age. The setting summary also does not with the timeago formatters on timestamps.

Proposed resolution

- Refactor DateTimeTimeAgoFormatter to extend TimestampAgoFormatter
- Fix settings bug with TimestampAgoFormatter
- Fix settings summary for TimestampAgoFormatter and DateTimeTimeAgoFormatter

Remaining tasks

Finish it.

User interface changes

None.

API changes

None.

Data model changes

None.

Credits

#2867248: Timestamp Ago Formatter: Future and past format not selectable due to incorrect variable name... was closed as a dup of this. Please also credit @xSDx, @JaceRider for patches and @jhedstrom for a review from that issue.

Follow-up to #2638140: Error logging should log a backtrace consistently

Problem/Motivation

Software has bugs, so errors are there and will be logged.
Sadly by default Drupal just puts the line of the broken code, which is already helpful, but on the other hand often now really helpful, because you need a full backtrace to figure something out.

Proposed resolution

Log a backtrace on top of the actual error message.
This will just make the backtrace available in the variables section, but won't be displayed as part of the watchdog site.

D7: Make the new setting opt-in and provide a way to get the value.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

There's a set of checkboxes from Content moderation module which have no programatically-determinable name, which is an accessibility problem.

The checkboxes are for selecting which content entity bundles get workflow behaviour. They're found in a table, in a dialog, in the workflow config section called "This workflow applies to".

Unlabelled form inputs are a WCAG failure at level A. A person using assistive technology like a screen reader may have considerable difficulty understanding whether they have selected the correct checkboxes. See F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name.

Steps to reproduce

1. Install standard profile.
2. Enable the Content moderation module.
3. Visit admin/config/workflow/workflows/manage/editorial?destination=/admin/config/workflow/workflows
4. In the last table ("This workflow applies to:"), press the Select button for Content types.
5. The dialog which appears("Select the content types for the Editorial workflow") has a table of Content type bundles: basic page, article, etc.. The corresponding checkboxes in each row have no associated label element.
6. If using a screen reader, these checkboxes will both be announced as "checkbox, not checked", with no accessible name for the checkbox.

Proposed resolution

Add an accessible name to these checkboxes, which can be conveyed to assistive technology. A screen reader ought to announce the checkbox as "basic page, checkbox, not checked".

Any of the following approaches will work. These are in order of preference - only use ARIA attributes if the HTML label element is too hard to achieve.

1. Make the visible bundle name in the second column into a the checkbox in column one. Like the pattern on admin/modules. This has the advantage of being clickable itself, so it's an improvement for mouse + touchscreen users too.
2. A <label for> in the first column, with a .visuallyhidden class.
3. An aria-labelledby attribute on the checkbox, with and ID reference pointing to the visible content type bundle name in the 2nd column
4. An aria-label="Basic page" on the checkbox input element, with the right bundle name,
5. A title attribute on the checkbox, with the name of hte content type bundle.

(Note: the phrasing varies between screen readers, operating systems, and locales. For example some say tickbox instead of checkbox. Don't worry about these differences, they're not up to us. The important thing is that each checkbox you can understand what each checkbox is for.)

Remaining tasks

Patch.
Tests, to ensure the checkbox abel is present.

User interface changes

Fixes an accessibility problem with unlabelled form elements.
No changes to visual design.

API changes

None.

Data model changes

None.

Problem/Motivation

As part of the system.performance config, Drupal currently includes the cache.page.max_age property that provides the max-age value in Cache-Control header on cacheable responses. There are many scenarios where it is desirable to have an independent max-age for 4xx responses.

Proposed resolution

In addition to invalidating the Drupal cache ( #2472281: 404/403 responses for non-existing nodes are cached in Page Cache/reverse proxy, are not invalidated when the node is created), make the emitted max-age for 4xx responses independent of the standard max-age.

This new config should still be part of the system.performance and named cache.page.4xx_max_age and be nullable. The value of this new config should beset to null initially and fallback to the standard cache.page.max_age if not set to an integer value.

Remaining tasks

Create change record. Stub: #2972025

User interface changes

No changes (per discussion in comments below).

API changes

New config to provide the max-age value in Cache-Control header on 4xx responses.

Discovered by pwolanin & klausi.

Problem/Motivation

The inactive tabs in the Seven theme do not meet WCAG AA section 1.4.3 requirements for text contrast.

To reproduce,
1. Login to drupal 8
2. Navigate to /admin/content
3. Run DAP Chrome plugin or other WCAG compliance checker on page
4. See a message similar to the following.

"Minimum contrast of 4.21 with its background is not sufficient to meet WCAG AA requirements for text of size 13.008px and weight of 400."

See attached screenshots for details.

Proposed resolution

Review current colors and backgrounds for inactive tabs and determine a suitable change that is in line with the Seven theme styles that also passes WCAG AA.

Remaining tasks

User interface changes

Update Seven tabs styles to increase contrast for inactive tabs.

API changes

None

Data model changes

None

This is a sub-issue of #1800046: [META] Add missing type hinting to core docblocks, fix Drupal.Commenting.FunctionComment.Missing* focused on correctly adding @param and @return type hinting to the Node module.

Documentation patches that include type hinting are time consuming to both review and commit because one must dig into the actual code to confirm that the type hints are both correct and complete. Hence, please be patient and try to limit type hint patches to covering only a limited number of docblocks (20-25 as a guess).

How To Review This Issue

1. Attempt to apply the patch to see if it needs a reroll.
2. Use the phpcs one-liner to evaluate whether all the relevant standards errors have been resolved: https://gist.github.com/paul-m/227822ac7723b0e90647
3. Look at each change and determine whether the type hint is correct.

Related sprint issues:

Placing a block on block structure page (Zurb Foundation OR Bartik) causes the following error:

RuntimeException: The subform and parent form must contain the #parents property, which must be an array. Try calling this method from a #process callback instead. in Drupal\Core\Form\SubformState->getParents() (line 76 of /Users/maria.mcdowell/Sites/devdesktop/eemmcdowell-test/docroot/core/lib/Drupal/Core/Form/SubformState.php).

[EDITED]
I tested against multiple blocks. Any block in the category "content" fails to load, as does "user" blocks. My initial test was against what I thought was a view block, but it turns out that it was the content block created by a module, probably CTools, of the same name.

Note that the Entity (user and content) blocks work without error, so it is not all things created by CTools.

Problem/Motivation

The help text for the "Alternative Text" input in Image Field Widgets suggests that it can be used for SEO (emphasis mine):

This text will be used by screen readers, search engines, or when the image cannot be loaded

While it's certainly true that search engines like Google appear to make use of image text alternatives, they are not the intended audience. It's quite common to find images where an author has used the ALT attribute for SEO keyword stuffing, and it's very unhelpful for any of the intended scenarios. I don't want to encourage that in Drupal's UI.

The W3C HTML 5.1 recommendation does not list SEO as a benefit of ALT. See 4.7.5.1. Requirements for providing text to act as an alternative for image.

In fact neither the HTML 5 / 5.1 recommendations nor the Understanding WCAG 2.0 working group note make any mention of search engines in relation to Alternative text for images.

Proposed resolution

Remove the suggestion that this should be used for SEO.
Suggestion from comment #4 is:

Replacement text for use when images are not available. Important for screen readers.

Update the description for "text alternative" in ImageWidget.
The ImageWidget settings form also needs updating.

Remaining tasks

Write a patch.

User interface changes

Minor change to the description of the "text alternative" field in ImageWidget.

API changes

None.

Data model changes

None.

I have the following menu tree:

- item 1
-- item 1a
-- item 1b
- item 2

I want to get a tree like this:

- item 1
-- item 1a
-- item 1b

When I do this:

// $this->menuTree is a MenuLinkTreeInterface
$show_parent_params = $this->menuTree->getCurrentRouteMenuTreeParameters($menu_name);
$show_parent_params->expandedParents = []
$show_parent_params->addExpandedParents(['item 1 uuid']);

I get this tree:
- item 1a
-- item 1b

Which doesn't make sense. I would expect this:
- item 1
-- item 1a
-- item 1b

I thought I would use setRoot, which I assume would include the root item unless excludeRoot is set.

$show_parent_params = $this->menuTree->getCurrentRouteMenuTreeParameters($menu_name);
$show_parent_params->setRoot('item 1 uuid');
$tree = $this->menuTree->load($menu_name, $show_parent_params);

And this loads a tree like this:
- item 1a
- item 1b

Setting $this->excludeRoot(); does not affect anything.

It seems there's code in, for instance menu_block which depends on this functionality.

Perhaps it would be possible to add an excludeRoot() function to MenuTreeParameter?

Or...?

Problem/Motivation

WAI-ARIA 1.1 introduces a useful new property: aria-current.

One place where we can use this is on pagination links. Currently, the pager styles in Seven and Bartik have a visual indication of the current page, together with a .visually-hidden span to say it is the current page (which screen readers announce). It's working fine at the moment, but we can modernize this.

The idea behind the aria-current="page" is to indicate this in a machine-readable way that can be conveyed to assistive technology though the platform-level accessibility APIs. The advantage is that screen readers, etc., can present the information in a way that is more consistent with native applications on host platform, such as:

• Announce it with a platform-localized string (from assistive tech on the host OS), instead of an author-localized string (from Drupal translations).
• Decide how/when to announce the fact, possibly based on user preferences in the host OS or assistive tech (e.g. screen reader verbosity prefs).

Demo page:http://design-patterns.tink.uk/aria-current/ (includes test results for various devices)

Proposed resolution

• Add aria-current="page" to the current page link in the pager.
  Important: this should go on the <a> element, not the <li>wrapper.
• Remove the visually-hidden phrase "current page" from inside the current-page link. Just use<span class="visually-hidden">Page: </span> like all the other numbered links.

Remaining tasks

• Assess: is there sufficient support for aria-current="page" across various browsers, assistive tech, and OS? Ask around the wider accessibility community. In particular, we'd like to know where it isn't supported yet, to assess the regression risk.
  • DONE: support looks good in general (comment #3). iOS + macOS Safari work, and there are several browser/screen-reader combinations working on Windows.
  • DONE: ChromeVox + desktop Chrome Browser. Not currently working, see comment #7.
  • TODO: monitor Android Talkback, not working yet (comment #6).
  • TODO: monitor support with MS Edge + JAWS. Watch this bug report: No support for aria-current in Edge.
  • TODO: Monitor support for MS Edge + Narrator. WAI-ARIA 1.1 is support is "in development" according to MS Edge Platform Status
  • TODO: Test in ChromeVox on ChromeOS, unknown. See comment #7
  • TODO: test macOS Voiceover with Chrome.
• Assess: does this impact on a template in the Stable and Classy themes?
• Write a patch.
• Tests?

Sign-offs needed

IMPORTANT: Possible regression risk - get sign-off from an accessibility maintainer, @andrewmacpherson or @mgifford.
Don't commit this until we're confident there's enough support across various OS, browsers, and assistive tech. It can wait until the time is right, and go in any minor release.

User interface changes

• Improved semantics for assisitive technology. Replace an invisible text span with machine readable attribute.
• No changes to visual design, or CSS.

API changes

None.

Data model changes

None.

Commit Credits needed

@rolivero_nfb - researched Android Talkback support, see comment #6.

Custom block types don't yet have a "status" field, which causes content translation to fail.

To reproduce:

1. Install TMGMT
2. Create a Custom Block Type
3. Create a custom block of your custom block type
4. Enable translations for your custom block type
5. Attempt to translate your block

Problem/Motivation

This issue was originally discovered by the revision log message field not showing when content moderation is enabled.

The issue stems from if a content type is created without revisions enabled, then content moderation is added, content moderation assumed revisions are enabled, and prevents enabling/disabling revisions, however it doesn't actually enable revisions.

Proposed resolution

Enable Node revisions when enabling moderation on nodes.

Remaining tasks

User interface changes

API changes

Data model changes

This is a sub-issue of #1800046: [META] Add missing type hinting to core docblocks, fix Drupal.Commenting.FunctionComment.Missing* focused on correctly adding @param and @return type hinting to the Taxonomy module.

Documentation patches that include type hinting are time consuming to both review and commit because one must dig into the actual code to confirm that the type hints are both correct and complete. Hence, please be patient and try to limit type hint patches to covering only a limited number of docblocks (20-25 as a guess).

How To Review This Issue

1. Attempt to apply the patch to see if it needs a reroll.
2. Use the phpcs one-liner to evaluate whether all the relevant standards errors have been resolved: https://gist.github.com/paul-m/227822ac7723b0e90647
3. Look at each change and determine whether the type hint is correct.

Related sprint issues: