I'm working on a 8.8.0 Drupal installation (running on php 7.3.12).
I've first uninstalled the "comment" module and than I've enabled it and I've created a new comment type, called "comment" and added a comment field to a content type (with translation enabled).
Everything works but if I try to go to http://localhost:9999/it/comment/3/edit I obtain a blank page and dblog tells me:

Error: Call to a member function isLanguageAlterable() on null in language_entity_field_access() (line 416 of /var/www/html/web/core/modules/language/language.module)

Line 415 and 416 are these:

$config = ContentLanguageSettings::loadByEntityTypeBundle($entity->getEntityTypeId(), $entity->bundle());
return AccessResult::forbiddenIf(!$config->isLanguageAlterable());

The problem is that $entity->bundle() returns NULL and so also $config is NULL.
If I replace $entity->bundle() with my comment bundle name (comment), that page works (even if the edit form does not display all fields, but only "subject").

I've not custom modules enabled and this is a "fresh" installation (with configuration but without contents).

I have upgraded my site to Drupal 8.8, which introduces a new "path_alias" module. However when running drush updb, I get:

...
>  [notice] Update started: system_update_8804
>  [error]  SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'PRIMARY': INSERT INTO {path_alias} (id, revision_id, uuid, path, alias, langcode, status) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6), (:db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13), (:db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17, :db_insert_placeholder_18, :db_insert_placeholder_19, :db_insert_placeholder_20), (:db_insert_placeholder_21, :db_insert_placeholder_22, :db_insert_placeholder_23, :db_insert_placeholder_24, :db_insert_placeholder_25, :db_insert_placeholder_26, :db_in
...

Problem/Motivation

As discovered and discussed in comments #2960643-27: Cannot load entity by uuid after rename - #2960643-32: Cannot load entity by uuid after rename the config entity updater might misbehave because it updates the #finished key in the sandbox based on the last entity type.
So if there are multiple entity types being updated in a single update and the last entity type has fewer entities than the previous ones, then not all previous ones will be updated as the sandbox will be flagged as finished.

Proposed resolution

Put the sandbox keys into a dedicated section - instead of $sandbox[$sandbox_key] use $sandbox['sandbox_keys'][$sandbox_key].

Populate $sandbox['sandbox_keys'][$sandbox_key]['#finished'] for each sandbox key. Populate the sandbox's #finished - $sandbox['#finished'] based on AND-ing all #finished of each sandbox key.

+ Re-run all updates that are updating multiple entity types in core in a single update.
+ Publish a change record that custom and contrib has to re-run their updates as well if they update multiple entity types in a single update.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The Book module does not fully use the new translation features we have. It doesn't translate the node titles in the different menus it generates.

Steps to reproduce:

• Configure Book content type for translation
• Enable a second language
• Create a book outline in English
• Translate each node in the outline
• Navigate the book in the second language

The nodes get loaded correctly, in the correct language. However, the navigation in the node footer, as well as the Book block, display the node titles in English, which is incorrect.

I'm the maintainer of the Book Translation module. D8 will make much of the module obsolete (which is great). However, it misses this small part.

Problem/Motivation

This is a portion of #2900409: [Meta] Improve UI of Reference field settings form, separated out after comment #133.

When you are setting up an entity reference field, you usually only select 1 bundle or maybe a couple of similar bundles to be referenced. It is then somewhat jarring when you go to choose the sort options in the settings dialog, and you are shown all kinds of fields that are not present on these bundles, or have labels on the chosen bundles that are different from the labels that are shown.

Proposed resolution

Limit the field choices in the Sort By select list to fields that are on the selected bundles. Also, display the field label that is in use on those bundles; or, if there is more than one label in use, the most commonly-used label in use on those bundles.

Remaining tasks

None

User interface changes

Sort options will correspond to the selected bundles in entity reference field settings.

Before: this screenshot shows the title field with the label "Recipe name" even though only the Vendor content type is selected:

After: with a little help from browser tools to show both widgets at the same time, the Vendor content type is selected and the title field is displayed as "Vendor name":

See Comment #9 for additional screenshots.

API changes

None.

Data model changes

None.

Release notes snippet

Probably not necessary.

Problem

1. Drupal has adopted Views’ dropbutton in several common places in core. Since its introduction in #1608878: Add CTools dropbutton to core, we've spent lots of time refactoring the existing button: #1799498: Improve dropbutton and others [which?]. This component is now even being used for primary form actions on the new node edit form: #1751606: Move published status checkbox next to "Save". However, the implementation there has made the dropbutton harder to theme by pushing it beyond its initial design. (Specifically, allowing its to consist of buttons instead of links, and by introducing sub-elements using #prefix and #suffix).
2. From a UX standpoint, the existing dropbutton’s behaviour is sub-optimal. Since the sub-items are contained within the button, when the button is opened it often must grow in width to accommodate the width of the sub-items. This change moves the click target out from under the user’s cursor, forcing them to hit a slightly different spot in order to close the menu again. The standard implementation of this design pattern does not suffer from this issue: Twitter Bootstrap, Zurb Foundation, jQuery UI. Drupal is the odd one out here.
3. From a code maintenance and re-use point of view, it makes sense to decouple the dropbutton itself from the menu it discloses. This allows the menu component in particular to be used elsewhere in the UI, and both can be themed separately.
4. The open/closed state of the menu isn't conveyed to assistive technology, it is only apparent visually.
5. The current focus style for the more-actions button is weak, and won't pass WCAG 1.4.11 Non-text contrast.

Proposed Resolution

Since we cannot change the current Dropbutton (and Operations) implementation for BC reasons, the way to move on is:

1. Create a new Splitbutton element with the required markup, functionality and (accessibility) features.

   • The new Splitbutton element must allow having buttons as well as links, and it should be able to replace the hard-coded fake Dropbutton in Views UI.
   • It should be easy to add modifier CSS classes (described in #2160481: Componentize the dropbutton CSS).
   • Convey the behaviour and state to assistive technology, in line with the Menu Button pattern from the WAI-ARIA Authoring Practices.

     References:

     • Navigation Menu Button Example for WAI-ARIA Authoring Practices 1.1
     • #2893663-2: Dropbutton should report open/closed state to assistive technology
     • Comment #67 here.
     • #2893663-10: Dropbutton should report open/closed state to assistive technology
     • #2278473-100: Simplify Dropbutton markup in line with our CSS standards
   • Should have the proper focus styles, to satisfy WCAG success criteria 1.4.11 Non-text contrast. Using an outline (i.e. shape) change is recommended, rather than changing colour alone.
2. Replace core's Dropbutton and Operations usage with the new Splitbutton element.
3. Deprecate Dropbutton.

Remaining tasks

TBD.

User interface changes

TBD.

API changes

TBD.

Original Proposed Resolution

• Refactor the implementation in core to allow for buttons as well as links in the element while maintaining theme-ability. This is a good opportunity to implement the splitbutton design. — #2278479: Change the dropbutton theme function to ensure consistent output and accommodate the splitbutton design
• Refactor the markup, CSS and JS to be as simple as possible — #2278473: Simplify Dropbutton markup in line with our CSS standards
• Componentize the primary and regular dropbuttons — #2160481: Componentize the dropbutton CSS
• Convey the behaviour and state to assistive technology, in line with the Menu Button pattern from the WAI-ARIA Authoring Practices.
• Follow the keyboard-control behaviour from the Menu Button pattern in the WAI-ARIA Authoring Practices.
• Improve the focus styles, to satisfy WCAG success criteria 1.4.11 Non-text contrast. Using an outline (i.e. shape) change is recommended, rather than changing colour alone.

Status

• The standard interaction pattern mentioned above (split button with separate menu) and a new style for the Seven theme both have consensus from the UX team: http://groups.drupal.org/node/283223#Split_Buttons_and_Dropbuttons
• We have prototype markup, CSS and Javascript all working with keyboard and screenreader access in a project sandbox. The Markup and CSS are solid (the CSS has been build with a clear separation between core structure and appearance). However, JS implementation needs work.

Problem/Motivation

The following error has been reported multiple times:

Argument 2 passed to Drupal\jsonapi\Routing\Routes::Drupal\jsonapi\Routing\{closure}() must be an instance of Drupal\jsonapi\ResourceType\ResourceType, NULL given

The only potential source of this error is in Drupal\jsonapi\ResourceType\ResourceTypeRepository::getRelatableResourceTypesFromFieldDefinition():

    $has_target_bundles = isset($handler_settings['target_bundles']) && !empty($handler_settings['target_bundles']);
    $target_bundles = $has_target_bundles ?
      $handler_settings['target_bundles']
      : $this->getAllBundlesForEntityType($entity_type_id);

    return array_map(function ($target_bundle) use ($entity_type_id, $resource_types) {
      $type_name = "$entity_type_id--$target_bundle";
      return isset($resource_types[$type_name]) ? $resource_types[$type_name] : NULL;
    }, $target_bundles);

The two known reasons that NULL might be generated is if an entity reference field has handler settings referencing a missing target bundle or the resource type name has been overridden by JSON:API Extras.

Proposed resolution

Neither of these reasons is a bug in JSON:API, per se. Instead, they could be caused by bad configuration, a poorly defined custom base field, or by JSON:API Extras.

In order to help users suffering from those bugs, introduce exceptions that will pinpoint the source of the errors.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

N/a

Problem/Motivation

The default Dropdown button is being implemented on #3023243: Drop Buttons style update. This issue is a follow-up to get the primary one addressed. At the moment this is not being used anywhere so we want to implement it for potential contrib use cases.

Specs:
FIGMA

Remaining tasks

• Create patch to add styling for the dropbutton primary variation
• Accessibility review
• RTL review (Right to left)

Test Pages

-

Problem/Motivation

Today, whenever a patch includes an updated composer.lock file, the dependencies in that lock file are calculated using whatever PHP version the patch submitter happens to be using. This means that the generated dependency graph might be different depending on who generated the patch file. Worse than that, some results might actually be erroneous. Erroneous results might result in a failure from the composer update command, or, worse still, might produce dependencies that do not work with the advertised minimum version of Drupal. Some of these erroneous results would not be caught by the tests.

One example where this can go wrong in Drupal 9.0.x relates to the minimum PHP version in the drupal/drupal composer.json file. Currently, PHP 7.2.3 is required; however, if you install this version of PHP and run composer update, you will get an error:

  Problem 1
    - symfony/mime v5.0.0 requires php ^7.2.5 -> your PHP version (7.2.3) does not satisfy that requirement.

In addition to symfony/mime, there are other packages with minimum PHP versions that are higher than when 7.2.3 was originally selected as the minimum for Drupal 9.x. For example, symfony/service-contracts v2.0.0 requires php ^7.2.9.

Proposed resolution

• Set the minimum version of PHP to 7.2.9, so that the version that we declare as our minimum matches what our dependencies require.
• Set config.platform.php in the drupal/drupal root-level composer.json file to match the minimum PHP version in core/composer.json, so that dependency resolution is always done consistently, regardless of the version of PHP installed on the machine running the composer update command.
• Add an integration test that ensures that the version of PHP stipulated in config.platform.php always matches the minimum version of PHP in core/composer.json, so that the tests will always catch any mistakes that may be made updating one of these without the other.

Remaining tasks

We need to decide if this should be backported to the 8.9.x and/or the 8.8.x branches. In theory, the dependency versions on these branches should no longer change very often. However, it is possible that they might, e.g. due to a security update. With PHP 7.0 and 7.1 both being at EOL, some projects may decide to drop support for them in a minor or patch release. (I personally recommend against this, but it may happen.) Having this backported to the earlier branches therefore might be helpful, even though the odds of needing it there are fairly low.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

n/a

ContentEntityStorageBase::loadUnchanged() implies that its argument is a valid entity id, but never checks it. Supplying, eg, NULL as an argument can lead to a number of side-effects, such as resetting static cache, calling preload hook for all entities etc, to say nothing about just time it takes.
There is a similar issue concerning load() method - #3035980: Provide a better error when a NULL is passed to EntityStorageBase::load(). Same should be implemented for loadUnchanged().

After updating to Drupal 8.8.0, the Status Report (/admin/reports/status) throws a 500 error with the exception --

Uncaught PHP Exception Symfony\Component\Routing\Exception\RouteNotFoundException: "Route "entity.view.edit_form" does not exist."

This will happen if the Views UI module is not installed and a view is found to be a using the deprecated moderation_state value in content_moderation_requirements because it attempts to create a route provided by the Views UI module (entity.view.edit_form).

Workaround for now is to enable Views UI.

Right now, \Drupal\Core\Render\Element\FormElement::processAutocomplete() allows one to pass a route name and route parameters to the URL generator that will build the autocomplete backend URL, but it does not support URL options (query string parameters and such).

This can be quite limiting in cases like the one I just encountered, where I want to alter the autocompleting entity reference query but only if a certain condition is true on the client side (signaled by the presence of a query string parameter).

I think it would make a nice addition to core for autocompleting form elements to support URL options :)

Problem/Motivation

Drupal currently has 3 message types:

• status
• warning
• error

These are found in MessengerInterface as constants. This interface also defines methods to directly add a message for each of these types, such as addWarning.
Any string "type"could be passed as the second argument to addMessage however there are other places in core where these 3 and only these 3 types are allowed.

For example, the render array output by StatusMessages passes an array with these 3 types to themes,

'#status_headings' => [
  'status' => t('Status message'),
  'error' => t('Error message'),
  'warning' => t('Warning message'),
],

If a new type is used then the heading text won't display properly in themes like classy, where you find: {{ status_headings[type] }} in status-messages.html.twig

If these types were not hardcoded in Drupal core, or if there was a way to extend these 3, then new message types could be added for unique events.

Proposed resolution

Determine a way to extend the 3 message types.
Add additional info such as status headings and fallback classes. New types should be able to "fallback" to existing styles. For example, a "success" type could add messages--status class to use the existing "status" styling.

Remaining tasks

1. Add option to add additional Messenger types from a module
2. Make these new types discoverable for JavaScript Drupal.Message see: getMessageTypeLabels

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#2241655: EntityStorageInterface::create() should always create a "new" entity revealed some places where we have very interesting legacy code (and one new one!)

Part of this code can be found in file_copy() and file_save_data(), where a file or entity would always be created created even it already exists.

Proposed resolution

Stop doing that, in any way possible.

Remaining tasks

Find a way

User interface changes

API changes

In core/modules/layout_builder/src/Form/DefaultsEntityForm the status messages are added as a render array, which prevents them from being rendered with the StatusMessages class.

If the messenger is used instead, it will make the message display more flexible.

I was redirected from Pathauto to Core for this issue
( https://www.drupal.org/project/pathauto/issues/3100678 )

Since I updated to Drupal 8.8, and pathauto 1.6
I get the following error :

Entity/field definitions
Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
URL alias

    The URL alias entity type needs to be installed.

I tried installing entity-update and running drush entup, the error persists;
Also tried running updates, cron and clearing all caches.

#drush entup
The following updates are pending:

path_alias entity type : 
  The URL alias entity type needs to be installed.
Do you wish to run all pending updates? (y/n): y
Cache rebuild complete.                                                                                                                                                               [ok]
Finished performing updates.                                                                                                                                                         [ok]

The error persisted so I run it again in verbose mode :

root@www /home/www.mydomain.com # drush entup -vv
Executing: mysql --defaults-extra-file=/tmp/drush_2Wl2V1 --database=mydatabase --host=localhost --port=3306 --silent  < /tmp/drush_18mVNw
Executing: mysql --defaults-extra-file=/tmp/drush_jjhqg2 --database=mydatabase --host=localhost --port=3306 --silent  < /tmp/drush_yn9c6w
The following updates are pending:

path_alias entity type : 
  The URL alias entity type needs to be installed.
Do you wish to run all pending updates? (y/n): y
env COLUMNS=193 /usr/local/bin/drush  --backend=2 --user=0 --verbose --root=/home/www.mydomain.com --uri=http://default  updatedb-batch-process 647 2>&1                           [notice]
Executing: mysql --defaults-extra-file=/tmp/drush_chzotL --database=mydatabase --host=localhost --port=3306 --silent  < /tmp/drush_5lhIy0
Executing: mysql --defaults-extra-file=/tmp/drush_tSjZmh --database=mydatabase --host=localhost --port=3306 --silent  < /tmp/drush_QzKaqw
EntityDefinitionUpdateManagerInterface::applyUpdates() is deprecated in 8.7.0 and will be removed before Drupal 9.0.0. Use                                                               [notice]
\Drupal\Core\Entity\EntityDefinitionUpdateManagerInterface::getChangeList() and execute each entity type and field storage update manually instead. See
https://www.drupal.org/node/3034742. EntityDefinitionUpdateManager.php:175
Command dispatch complete                                                                                                                                                                [notice]
env COLUMNS=193 /usr/local/bin/drush  --backend=2 --verbose --root=/home/www.mydomain.com --uri=http://default  cache-rebuild 2>&1                                                 [notice]
Cache rebuild complete.                                                                                                                                                               [ok]
Command dispatch complete                                                                                                                                                                [notice]
Finished performing updates.                                                                                                                                                          [ok]
Command dispatch complete                                                                                                                                                                [notice]

I'm told drush entup is now useless, so how am I supposed to fix this error ?
Thanks in advance :-)

Problem/Motivation

https://www.drupal.org/project/seckit/issues/3074080 is porting to the new BrowserTestBase. The old method was protected function drupalPostForm($path, $edit, $submit, array $options = [], array $headers = [], $form_html_id = NULL, $extra_post = NULL) { where the new method is protected function drupalPostForm($path, $edit, $submit, array $options = [], $form_html_id = NULL) {. It misses $headers. Notably protected function drupalGet($path, array $options = [], array $headers = []) { still has $headers.

Proposed resolution

1. Add an optional $headers to prepareRequest and submitForm
2. Move the header setter code from drupalGet into prepareRequest.
3. Pass down $headers from drupalPostForm to drupalGet and submitForm both.

Remaining tasks

Write it.

User interface changes

API changes

Additional optional $headers argument on prepareRequest and submitForm and drupalPostForm. It'll be a bit annoying the order of arguments change vs WebTestBase but I guess that can't be helped now.

Data model changes

Release notes snippet

Coming from #2742585-102: Deprecate dangerous assertTrue/False() compatibility overrides in PHPUnit Kernel, Functional and FunctionalJavascript tests:

@mondrake

How about deprecating also the assertEquals override in KernelTestBase and BrowserTestBase, so forcing tests to call explicitly castSafeStrings when needed?

@alexpott

the gain with it is less obvious.One thing that is interesting is instead of the assertEquals hack we could register a Comparator to compare MarkupInterface objects...

Using "field_group" to sort the fields into tabs leads to inaccessible options in the sidebar when creating/updating a node.

Steps to reproduce

1. Install Drupal 8.8.0-rc1
2. Install Claro, set as admin theme
3. Add, enable "field_group" module 8.x-3.0-* (or 8.x-3.x)
4. Go to "manage form display" of basic page bundle
5. Add a "Tabs" field group, add one Tab and place the body field in it
6. When creating a basic page, most options in the sidebar are not accessible any more, when the screensize is bigger 85em (drupal/core/themes/claro/css/components/vertical-tabs.pcss.css:345)

See attached screenshot.

Problem/Motivation

As detailed in #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes.

Part of this process is creating theme-specific copies of any templates and CSS files that were previously inherited from Classy. There should be an easy way to distinguish these used-to-be-Classy templates/CSS files from ones created specifically for a theme.

Proposed resolution

In the templates & css directory for every core theme subtheming Classy, add a classy directory with a README explaining that:
- It is for templates/css copied from Classy,
- If a template in this directory is altered it should be moved outside the classy directory as it's now theme-specific.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet