Steps to reproduce

1. Go to admin/config/people/accounts
2. Navigate to REGISTRATION AND CANCELLATION > When cancelling a user account
3. Inspect the radio buttons. Seeing that aria-describedby="edit-user-cancel-method--description" which edit-user-cancel-method--description doesn't exists.

Those 3 radio buttons don't have any description. So I think they don't need to have aria-describedby attribute.
For example, in REGISTRATION AND CANCELLATION > Who can register accounts?, the radio buttons don't have aria-describedby attribute since they don't have description.
However, the description below (Users with the Select method ...) is a description of the fieldset wrapper.

Problem/Motivation

At present we don't have a generic entity API for determining revision support for operations such as:

• view
• delete
• revert
• edit

Node module defines the following permissions:

• delete all revisions
• revert all revisions
• view all revisions

But these are silver-bullet permissions, they don't allow granular access (per node-type, per entity etc).

The test entities in core don't do anything with revision (their routing has access: TRUE)

These entities don't have any UI for viewing/reverting/deleting revisions:

• media
• block content
• taxonomy
• menu link content

This is now starting to be a hard blocker for further generic improvements in core including:

• #2350939: [PP-1] Implement a generic revision UI
• #2795279: [PP-4] [META] Revisions support
• #2925532: Provide bulk action to delete all old revisions of an entity

Proposed resolution

Add new operations to the existing ::access signature such as

• delete revision
• update revision
• view revision

Remaining tasks

• Change deprecation to target removal 10.x instead of 9.x.

User interface changes

API changes

Data model changes

Release notes snippet

The 8.x-2.1 version adds a feature: 'Add a version negotiation to revisionable resource types'. Due to no generic revision access checker in core, this feature currently only supports nodes and media entities.

Version negotiation for arbitrary entity types is blocked by #3043321: Use generic access API for node and media revision UI.

For context, see #2992833-151: Add a version negotiation to revisionable resource types and #2992833-153: Add a version negotiation to revisionable resource types.

This comment and commented out code is just weird...

  /**
   * Executes the aggregate query.
   *
   * @return array
   *   A list of result row arrays. Each result row contains the aggregate
   *   results as keys and also the groupBy columns as keys:
   * @code
   * $result = $query
   *   ->aggregate('nid', 'count')
   *   ->condition('status', 1)
   *   ->groupby('type')
   *   ->executeAggregate();
   * @endcode
   * Will return:
   * @code
   * $result[0] = array('count_nid' => 3, 'type' => 'page');
   * $result[1] = array('count_nid' => 1, 'type' => 'poll');
   * $result[2] = array('count_nid' => 4, 'type' => 'story');
   * @endcode
   */
  // public function execute();

Problem/Motivation

One major piece of functionality from the D7 Entity Reference module was left out entirely in #1801304: Add Entity reference field: the ability to render exposed views filters as a select list or autocomplete of available entities.

Proposed resolution

Create a new Views Entity Reference filter plugin to be available for all entity reference fields and migrate the existing taxonomy filters to be based on the new generic filter plugin.

How to use

1. Add on an entity type / bundle an entity reference field, ex field_test_reference.
2. Create a view displaying this entity type.
3. Add a filter on the view for field_test_reference.
4. Configure the entity selection mode and the widget display mode.
5. Configure the filter behavior (ex: required, multiple, etc.)
6. Finally use the filter field for filtering the results based on the selected entity from the autocomplete or select list.

Remaining tasks

• ☑ support for content entity reference
• ☑ support for configuration entity reference
• ☑ support for content with and without bundles
• ☑ taxonomy filter rebased on generic entity reference
• ☑ settings forms to configure the filter
• ☑ display widget in select or autocomplete
• ☑ filter values based on reference view
• ☑ filter values based on bundles
• ☑ maximum filter values in select list for performance concerns
• ☑ sort for filter values when in bundle selection handler mode
• ☑ argument support for when view selection handler is used
• ☑ views configuration schema update
• ☐ existing configuration migration (no longer needed if we create a new filter only)
• ☐ fix select option (#208, #215)
• ☑ tests
• ☐ get framework manager approval
• ☐ write change record

Post tasks

• ☐ follow-up task to have TaxonomyIndexTid use this entity reference plugin
• ☐ conversion of the "authored by" filter to use the entity reference filter
• ☐ extract selection handler form logic in separate plugins that will specialize for rendering and validating the filter selection config form
• ☐ caching of the value form?
• ☐ documentation updates

User interface

Known issues

• CANNOT REPRODUCE ATM sometimes when switching between widget it gets stuck on the previous selected one
• FIXED when switching between the widget types the previous value is left in the exposed form and it's incompatible with the other widget type
• FIXED triggering ajax requests on the extra options form right after adding the filter brings you back to the add handler form fixed

API changes

None.

Problem/Motivation

Text in the "Powered by Drupal" block doesn't satisfy WCAG SC 1.4.3 Contrast (Minimum).

The colour contrast ratio of the plain text is approx 3.9:1, but the required contrast is 4.5:1.

The text is small size and doesn't qualify for the 3:1 "large text" exemption.

Proposed resolution

Remove the colour from the .block-system-powered-by-block rule.

Instead, let it inherit the colour from .site-footer, which has a contrast ratio of 7.1:1

Remaining tasks

Patch

Problem/Motivation

The Summary part of the textfield should have a WYSIWYG Editor because the format applies to body and summary.

Proposed resolution

@todo
- Lock down the format for summary in the widget. (?)

Remaining tasks

1. Update this summary to accurately reflect the proposed change.
2. Fix the existing test failures.
3. Add new tests to cover the new functionality.
4. Move this back to 'Needs review'
5. Reviews/refinements.
6. RTBC.
7. Commit.

User interface changes

WYSIWYG editor available on the separate 'Summary' field on text areas that support them.

Before

@todo

After

API changes

TBD.

Data model changes

TBD, hopefully none.

#675446-238:
There appears to a major regression in the committed code: duplicates are suggested!

Steps to reproduce:

1. Make sure a free tagging field already has the "foo" and "bar" values. Assume these are the only two terms in the system.
2. Now go back to the node and edit, type a comma and "b".
3. Expected: nothing is suggested. Reality: "bar" is suggested again.

This problem was in fact implicitly being demonstrated in #230.

The page that looks visually closer to /admin/reports is /admin/structure which has menu items alphabetically sorted.

However, /admin/reports order is not making sense (at least to my eyes).

Maybe this is by design?

Problem/Motivation

Unpublished books appear in the default listing at /book.

Steps to reproduce:

1. Install Drupal
2. Enable book module
3. Create a book page that is unpublished
4. Visit /book as an anonymous user
5. Confirm the unpublished book appears in the list
6. Click the link and get access denied

Expected result: Unpublished books should not appear in the listing /book for users who do not have permission to view unpublished content.

Proposed resolution

Update this page to check permissions to ensure content displayed corresponds with user access.

Remaining tasks

1. Write a patch
2. Review

--

I created new drupal 8 site from drupal 6 (via Migrate module).
Unpublished books became available in books list.
There were only main pages unpublished of these books. I tried to unpublish all pages of these books but result is the same.
When I click on one of these books in the list, 404 is shown.

have a look http://русбой.рф/книга
for example the third book in the list is unpublished

module list:
bootstrap_layouts
captcha
colorbox
ctools
ds
google_analytics
pathauto
recaptcha
redirect
tagclouds
token
video

theme: bootstrap sub theme

Problem/Motivation

In D7, a manual created menu link pointing to "user/login" only showed up if I'm not already logged in.
In D8, the link shows up no matter whether I'm already logged in or not.
Guess that has something to do with the new routing system.

Steps to replicate this issue:
- Goto: /admin/structure/menu/manage/main
- Add a menu link "Login" to the path "user/login"
- Go to the home page, , whilst logged in, you should have 2 links "Home" and "Login"

On Drupal 7 you wouldn't see this link.

Proposed resolution

Before

After

Remaining tasks

User interface changes

Yes, login menu item will not display if one is already logged in

API changes

Data model changes

Release notes snippet

When Drupal displays a field, the template is field.html.twig, which generates block-level markup including optional labels, attributes, and supports multiple values.

For the node title, uid and created fields Drupal supplies an overridden template (e.g. field--node--title.html.twig) that generates simplified inline markup without label or title_attributes.

If the site owner has hooked the node title to setDisplayConfigurable(), then the inline display is incorrect. The label is missing, markup is inline, and the markup might not match normal CSS selectors for fields (for example if the CSS selector specifically matches on div). For the node created field, also the metadata rel="schema:author" is missing.

Solution

Add a '#inline_field' variable to the field templates so that they can distinguish whether they are called in a context where they should return block markup or inline markup.

The detailed rules for inline markup are as follows:

1. The page title is always inline.
2. The node title, uid and created fields are inline except if setDisplayConfigurable() has been called.
3. To preserve back-compatibility, rule 2) only applies if an additional entity type property has been set - reusing the mechanism from #2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI.

Workaround

/**
 * Implements hook_theme_registry_alter().
 */
function XXX_theme_registry_alter(&$theme_registry) {
  // Disable the 'inline' versions of node base field templates to workaround
  // https://www.drupal.org/node/2993647.
  unset($theme_registry['field__node__title']);
  unset($theme_registry['field__node__uid']);
  unset($theme_registry['field__node__created']);
}

#2353867: [META] Expose Title and other base fields in Manage Display will introduce the "normal" mechanism for managing display of title and other base fields then deprecate the old specialist non-standard way. With the major release of D10 we should remove the deprecated code.

Changes required have @todo markers linking to this issue, and are summarised below.

Node template

• Remove label, date, author_name - code can use elements[title] etc.
• Remove page, display_submitted - if title/submitted should not be displayed then the corresponding elements will be missing or generate no markup.
• Remove author_attributes, author_picture - instead the information will be part of the rendered formatter output of elements[uid].
• Remove all process code related to the variables removed from the node template, including template_preprocess_node and rdf_preprocess_node.

Field templates

• Remove all copies of field--node--title.html.twig, field--node--uid.html.twig, field--node--created.html.twig.
• In node_theme remove field__node__XXX.

Once we are using field formatters for the base-field output we don't need these special cases.

Node type

Remove $display_submitted, displaySubmitted(), setDisplaySubmitted(), related form/schema. It is controlled through manage display UI settings instead.

Theme setting

Remove the theme setting features.node_user_picture. Instead this is controlled by a setting on the formatter for the uid field.

Problem/Motivation

In \Drupal\Core\Mail\Plugin\Mail\PhpMail::format() there is a conversion from HTML to text which occurs without checking if the input is an instance of MarkupInterface. This causes corruption of a mail that was in fact plain text and containing text that resembles HTML entities.

E.g.

Today I learnt Greek letters alphaβ they are hard to write
In HTML, ampersand must be written as &

Steps to reproduce

Install a contrib module that allows sending of messages in mail text format. An example is simplenews. Type a message like the example above.

Proposed resolution

Only call htmlToText() if the input implements MarkupInterface.

Remaining tasks

Write a patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

Fairly often there is a need for some sort of contextual data when rendering an element, which parts of, ultimately needs to make its way down the theme system pipeline.

This is especially true when certain render elements or theme hooks, that are not normally aware of the context in which they'll be rendered, needs additional information to provide rendering variations (i.e. per type or identifier).

While it is possible to add any variable you want in preprocess functions, it is often too late in the process and the original data that usually contains the needed information has long since been lost.

This is, in part, due to arbitrary properties (not registered in the theme hook) from being automatically transferred from a renderable element's properties.

Example from the search module in core, where a 'context' variable was manually added to allow for this flexibility (#2495419: Move the 'search-results' class from the render array and into a Classy template):

$build['search_results'] = [
  '#theme' => ['item_list__search_results__' . $plugin->getPluginId(), 'item_list__search_results'],
  //...
  '#context' => ['plugin' => $plugin->getPluginId()],
];

Another example of use is for Views suggestions (which this issue is blocking): #2923634: [PP-1] Use hook_theme_suggestions in views.

Proposed resolution

Add a context variable as an empty array for all theme hooks, if one doesn't already exist.

Add a #context property as an empty array to all elements, if one doesn't already exist.

Remaining tasks

• Create test(s)
• Create patch

User interface changes

None

API changes

• The addition of a default #context property added to all elements
• The addition of a default context property added to all theme hooks (for preprocessing purposes only)
• The automatic mapping of a renderable element's #context property to the context variable
• Removal of the context variable immediately prior to rendering (for security concerns).

Data model changes

None

Problem/Motivation

In #3052002: [meta] Replace JQuery with vanilla Javascript in core and several other places, Tabledrag was mentioned as one of the larger obstacles to removing jQuery from core. An issue to work on that can help move the jQuery removal efforts forward, and it is a large enough task that it will likely surface many additional tasks needed for removing jQuery

Steps to reproduce

Proposed resolution

Remove all jQuery usage from Tabledrag other than once() and event handling, which have their own issues: #2402103: Rewrite jQuery.once [Remove dependency on jQuery]#3176441: Create vanilla events helper library to replace jQuery's.

Also refactor code that extends on Tabledrag as much as needed in order for it to work with no-jQuery tabledrag.

For the time being, suppress the tests in Claro as getting them to work would require extensive refactoring, yet that refactoring will be largely unnecessary when #3083051: Remove tabledrag.js replacement when core issues are resolved lands.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is almost a bug, but I'll call it a task.

run-tests.sh can run PHPUnit-based tests.

However, it can't reflect that a test was skipped.

This is due to two factors:

1) simpletest (and thus run-tests.sh) doesn't have a concept of a skipped test.

2) When a PHPUnit test (< v.5) is skipped, only junit reports will give a clue, which is that the test doesn't pass, fail, or error out. (PHPUnit v.6 junit will tells us that a skip occurred.)

What run-tests.sh does with this is turn it into a pass, because nothing failed or errored out.

Since functional-javascript tests are skipped when phantomJS is not available, this means that tests run using run-tests.sh could look like they're passing when in fact they did not run.

Unfortunately, there doesn't seem to be an easy way to turn skipped tests into fails, without adding a test listener.

Thus, we should modify run-tests.sh to look for the special case of skipped so that users will know that their phantomJS-based tests did not pass because they didn't run.

Since we're doing that, we should work on risky and incomplete status, as well.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

The current composer.json for the DevDependencies metapackage and the production dependency on composer/semver are not compatible with Composer 2.

Proposed resolution

• Loosen the constraints to allow installation with Composer 2.
• Keep locked dependencies the same.

Remaining tasks

Discuss. Do it.

User interface changes

N/A

API changes

Drupal 9.1 is installable with the Composer 2 alpha.

Data model changes

N/A

Release notes snippet

Drupal 9.0.0 was intended to be compatible with Composer 2; however, certain composer.json constraints in core were not compatible with Composer 2. Drupal 9.1 adjusts the production constraints for composer/semver and the dev dependency constraint for composer/composer to allow Composer 2 testing.

Problem/Motivation

#2272801: Allow blocks to be context aware. allows classes extending BlockBase to also be context-aware.
However, this shouldn't be needed, since many different plugins should be able to opt into context without breaking their parent class relationship

Proposed resolution

Figure out a way to make a ContextAwarePluginTrait.

Remaining tasks

The main problem here is the differences between \Drupal\Component\Plugin\ContextAwarePluginBase and \Drupal\Core\Plugin\ContextAwarePluginBase

User interface changes

N/A

API changes

API additions only.

Problem/Motivation

As reported by Berdir in slack, configuring a Broken plugin results in

Exception : Error: Call to undefined method Drupal\Core\Block\Plugin\Block\Broken::addContextAssignmentElement()
Drupal\Core\Block\Plugin\Block\Broken->buildConfigurationForm()() (Line: 182)

Proposed resolution

BlockPluginTrait is not context-aware, and shouldn't have that code.

Remaining tasks

Write tests

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A