Certain links do not contain unique link names for JAWS to announce. As an example within the “Content” screen, there are multiple “Edit” links present in a table. When the links are accessed JAWS announces “Edit link” without providing a unique link name to distinguish each link, instead of announcing as e.g. “Test Detail Page edit link”, “Test Image title edit link” etc.

This defect exists in IE 11 and Google Chrome version 55.0.2883.87 m.

Expected result: All links are expected to contain unique link names in order to distinguish between each link. In this instance JAWS is expected to announce e.g., “Test Detail Page edit link”, “Test Image title edit link” etc.

Reference: Section 508, Part 1194.21, user interface elements (d).

Notes:
• This defect also exists elsewhere within the application.
• This defect exists on a screen that is not accessible via a keyboard. The tester was forced to use the mouse to access this screen, which is not acceptable for a JAWS user.

Steps to reproduce:
1. Open JAWS
2. Open Drupal
3. Use the Tab key to navigate to the “Manage” button and press Spacebar/Enter to select.
4. Use the mouse to select “Content” button.
5. Use the Tab key to navigate to the “Edit” links throughout the screen.

Problem/Motivation

See #3278331: [Meta] Tasks to remove Seven from core and move to contrib and #3278212: [Meta] Tasks to deprecate Seven.

Seven will be deprecated in 9.5.x for removal in 10.0.x, this issue should handle the actual removal from core itself.

Steps to reproduce

Proposed resolution

Remaining tasks

1. The change record for this issue should include a link to recommendations page, https://www.drupal.org/node/3223395#s-MODULE_NAME. (For example, the CR for removing HAL)
2. Tag this issue 'Needs release note.'
3. Remove the module ;-).
4. Remove references from core/phpstan-baseline.neon.
5. Check for references in @todo.
6. Handle migration tests.
7. In all the functional tests in migrate_drupal_ui make sure that MODULE_NAME is not installed. MODULE_NAME should also be removed from the methods getAvailablePaths() and moved to getMissingPaths() in the tests using those methods.

User interface changes

API changes

Data model changes

Release notes snippet

The Seven theme has been removed from Drupal core and is now available as a contributed theme. Sites using Seven should install the contributed version or switch to a different administration theme such as the new core admin theme, Claro.

Problem/Motivation

In the Seven theme, any time an "unsaved changes" warning message appears, the asterisk of the message has an unsightly dotted underline in Microsoft Edge 86.0.622.58 (Official build) (64-bit) on Windows 10.0.19041 Build 19041 and likely other browsers.

Steps to reproduce

1. Visit /admin/structure/types/manage/page/display on a site that has a "Page" content type.
2. Use a tabledrag grippie to re-arrange the order of the fields.
3. Examine the message area at the top of the page.

Proposed resolution

abbr elements in the user-agent stylesheet have a text-decoration: underline set by default. This should be overridden in the styline for abbr.tabledrag-changed and abbr.ajax-changed to be set to none.

Remaining tasks

User interface changes

See above.

API changes

Data model changes

Release notes snippet

The spacing between titles, tables, action buttons is all different.

Problem/Motivation

Back in #2657178: Warn about experimental modules on their help pages there was an issue to add warnings in three places once an experimental module is installed.

• During install
• On the modules page
• in the site status

However, this commit has introduced a serious flaw in the UX for experimental modules on a drupal site. In general...

• Warnings must be actionable
• The site should not question the decisions of a site builder once a decision should be made
• The site should inform the site builder the implications of installing an experimental module and provide documentation on where to find the status of the experimental module.

This has real consequences for 1st tier drupal shops, which run into issues when using otherwise best practices for drupal development. Not all experimental modules are equal, and the decision to use an experimental module, once installed, should not be questioned by the site. The lightning distribution is currently using layout discovery, which should be encouraged over the deprecated and unsupported layout plugin module.

Also note, there was no UX review of the previous issue, and it was hastily committed within 2 days. It should have not been committed without proper UX review and community feedback.

Proposed resolution

1. Remove the warning from the status page.
2. Remove the warning from the modules page.
3. Add a better install notification/confirmation when installing an experimental module via the UI. This has basic support, but a handbook link or link to the status of experimental modules would be helpful.
4. Encourage drush to add a confirmation before installing an experimental module, using the same url to reference users to the status of experimental modules. Filed https://github.com/drush-ops/drush/issues/2770

Remaining tasks

Create a patch to revert the warning from post install actions. Follow up with additional patch to make the confirmation page better when installing experimental modules.

User interface changes

Experimental modules should display a warning message only on the module confirmation install page.

API changes

N/A

Data model changes

N/A

Problem/Motivation

So I've been working on making exceptions sent to the client match the format of the request (or, the route, if it really should only speak one format) over at #3304981: JSON and other serialization formats should handle non-4xx exceptions, too..

While testing this locally, I had the happy accident of writing some code which threw not an \Exception but a \TypeError, which is not an ancestor of \Exception but rather \Throwable. This resulted in a counterintuitive result where I got the ugly, last-ditch error formatter instead of my preferred formatted one.

A bit of tracing led me to discover that since Drupal 9 is still "stuck" on Symfony 4.4, the HttpKernel component only catches \Exception.

This was changed in April for Symfony 6, where the Kernel can now catch Throwables.

Interestingly, this functionality is not "on" by default, for BC reasons. (That is, the default is to only still catch \Exception.) It will, however, be the only behavior from Symfony 7.

I think Drupal should catch all the things and give them proper treatment in error handling. I've overridden the HttpKernel (I know...) on my project, but to opt-in to this behavior all we need to do is set a container parameter... and that means of course that end users can opt back out if a project needs time to prepare for Symfony 7.

This also requires changes to `InstallerRedirectTrait` and `ExceptionJsonSubscriber` which should should typehint on \Throwable. This is backwards-compatible of course because \Throwable includes \Exception.

I'm marking this major because I think it could get in "in time" for this to be a Change Record for 10.0.0? But since it's new behavior in Symfony 6, which Drupal 9 does not support, it does not need a deprecation in the same way as other code? I think?

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Coming from #2677574: All Blocks removed from regions after checking "Show Global blocks".

If an admin submits a block layout form that is empty (has no blocks), all blocks in all themes are left in a broken state (they do not appear through the admin UI).

Steps to reproduce

• Install Drupal core with the "Standard" install profile.
• Enable the "Stark" theme, setting it as default.
• At Admin > Structure > Block layout (admin/structure/block), delete all blocks for the Stark theme. After deleting the blocks, click the "Save blocks" button.
• Navigate to Admin > Structure > Block layout > Bartik (admin/structure/block/list/bartik). Note that all blocks have disappeared. The following screenshot illustrates the resulting page.

Source of bug

In BlockListBuilder::submitForm() we pass a form state value directly to a ::loadMultiple() call and then iterate through the resulting entities, making changes to each:

  $entities = $this->storage->loadMultiple(array_keys($form_state->getValue('blocks')));
  /** @var \Drupal\block\BlockInterface[] $entities */
  foreach ($entities as $entity_id => $entity) {

In the case that there are no blocks present on the form:

• An empty string is returned from $form_state->getValue('blocks'), and so all items in the storage are loaded, iterated, modified (including weight and region properties set to NULL), and saved.
• Without a region value, blocks don't show up in the UI.

Mitigating factors

Because of the block cloning that occurs when a theme is initially installed (see block_theme_initialize(), it's uncommon to have a theme enabled with no blocks; and, if there are no blocks, there is no reason to submit the form.

However, the bug can easily be triggered by contrib modules modifying the block management form. Specifically, the Block Visibility Groups module provides an enhancement that includes filtering blocks to show only those in a given visibility group (initially, none). See #2677574: All Blocks removed from regions after checking "Show Global blocks".

Proposed resolution

Examine the value returned by $form_state->getValue('blocks') and pass to ::loadMultiple() only if not empty.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Lots of classes have a addCacheableDependency() method.

There could be a single interface which defines this. (At least, the ones that have the same signature -- two of them are different.)

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

New interface.

Data model changes

Release notes snippet

Steps:
1. Install Drupal 9 with olivero theme.
2. Create any content type.
3. Visit the node and check it at a resolution @1920.

Issue:
On higher resolutions, the page container is left aligned. There is no spacing to the left of the container. As per my understanding, there should be equal padding from the left and right of the container.

Problem/Motivation

Discovered at https://git.drupalcode.org/project/drupal/-/merge_requests/2310/diffs#no..., while working on #3273983: Do not assume that plugin supporting <tag attr> also supports <tag> in SourceEditingRedundantTags and upgrade path.

Steps to reproduce

N/A

Proposed resolution

Update CKEditor5PluginDefinition::getElements() to match ::getConditions(), ::getLibrary() and ::getAdminLibrary()

Remaining tasks

Do it.

User interface changes

None.

API changes

CKEditor5PluginDefinition::getElements() no longer can return false|string[], but always string[]. It may now throw a \LogicException.

Data model changes

None.

Release notes snippet

N/A

Problem/Motivation

The method label() of entities is abstract and does not (necessarily) correspond to one specific field. Some entity types have implemented a specific version of that method while taxonomy terms do have a corresponding field (name) by default. Which is why those three expressions are basically identical:

• $term->get('name')->value
• $term->getName()
• $term->label()

Please correct me if I'm wrong but I think that the method label() is not supposed to change any actual functionality. It is there to show a string representation of that entity. Nothing else.

In a project I needed that string representation to be different for taxonomy terms, so I changed the method label() (by using my own class for taxonomy terms). Now here is what happened. As soon as I saved a taxonomy term, the field name was lost and instead the output of the label() method was saved in that field.

After debugging this for a bit, I found that the method getName() was using the method label() instead of fetching the content of the field name directly. I assume that the method getName() is used when a term is saved to fetch the current value of the name field, but I don't think that we should rely on the label() method returning that field. If we do, why even have a label() method in the first place? As soon as we change it, the name field is not usable anymore. At least not manually. It will always hold a copy of the label() result.

Steps to reproduce

• Update the method label() for your taxonomy terms
  • Overwrite the class for taxonomy terms (which I did), extend the original class and overwrite the method label()
  • Write a temporary core patch
  • I think there is also a callback method that can be registered which is but marked as deprecated
• Save a taxonomy term
• Edit the taxonomy term again
• The field name has changed

Proposed resolution

I don't think that the method getName() should be using the method label(). Instead it should return the name of the taxonomy term, just as the method name suggests: return this->get('name')->value;.

I would like to hear your thoughts and please correct me if I misunderstood anything.

Problem/Motivation

I think there could be some cases when we have to get just the entity contextual links without having to view/build the entity.

Error description refers to incorrect element

when a user does not have permission to edit site name or slogan, an incorrect access denied message is displayed: "Defined on the Site Information page. You do not have the appropriate permissions to change the site logo." it refers to "site logo".

Error refers to pages the user does not have access

When a user does not have permission to do something, we don't usually have an explanation message.

I'd like to propose removing the "You do not have the appropriate permissions to change the ...." message. I have a client that became confused why he was not granted permission to do something, despite being so close to being able to do it.

And remove "Defined on the XXX page." text if the user does not have permission to access it.

Problem/Motivation

Drupal's components (in the namespace Drupal\Component) all have composer.json files for #1826054: [Meta] Expose Drupal Components outside of Drupal.

For example, here's the Annotation component's composer.json:

{
  "name": "drupal/core-annotation",
  "description": "Annotation discovery and implementation of plugins.",
  "keywords": ["drupal"],
  "homepage": "https://www.drupal.org/project/drupal",
  "license": "GPL-2.0-or-later",
  "require": {
    "php": ">=7.3.0",
    "doctrine/annotations": "^1.4",
    "drupal/core-file-cache": "^8.8",
    "drupal/core-plugin": "^8.8",
    "drupal/core-utility": "^8.8"
  },
  "autoload": {
    "psr-4": {
      "Drupal\\Component\\Annotation\\": ""
    }
  }
}

There are several problems with this:

1. The PHP version requirement is wrong. Drupal core requires PHP 8.1, so PHP 8.1 syntax may appear in the core components at any time.
2. The constraint for Doctrine is out of date for D10; 10.0.x requires ^1.12.
3. The specified versions of other components are also wrong and/or broken. Very bad things would certainly happen if you tried to install the 8.8.x version of the Plugin component with parts of Drupal 10. I think the most we could guarantee is that they work with each other within the same major version. (Actually, this means they're all incorrect in Drupal 9 too, because they say ^8.8 rather than ^8.8 || 9.)

There is also no set of expectations anywhere that I could find about the support, BC, and ugprade path policies of the theoretical standalone packages that would come from these composer.json files. Nor has anyone reported the D9 components' packages being broken with unresolvable dependencies.

Proposed resolution

Either get rid of these files, or come up with a way to make them maintainable.

• One possibility is to write a script or something that at least updates them automatically for when a new major version is branched.
   

• That's still not a complete solution because they also would potentially need to be updated every time core increases a requirement for an external dependency they have a constraint on, which could happen in any minor or patch release.
   

• Additionally, the external dependencies would need to be updated between releases. For example, doctrine/annotation is going bye-bye in Drupal 10. (TBD whether this component will go along with it, or just be rewritten for the PHP attributes implementation, but other for other components it'd be easy to miss that removing a use statement might also mean needing to update the composer.json file.)

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Release notes snippet

Drupal's Component packages are now semi-automated from drupal/drupal's update script.

The drupal/drupal dev repo now reconciles components' dependencies with those of drupal/core and drupal/drupal during a Composer update command.

This means that dependency constraints declared in the components will always follow the needs of Drupal core.

This step is taken to ease maintainership of these components.

After writing changes in existing config, Drupal try to modify it's chmod. Not sure this is right, because, if Drupal successfully write changes to config, nothing else it should do.

Problem source

I install Drupal with 'drush si' in command line with my user: 'andyceo'. After that, all active configs have the chmod: 'rw r r' and owner=andyceo and group=andyceo.

I use ACL to allow both 'www-data' (apache2 user in ubuntu) and 'andyceo' change Drupal's 'files' folder:

$ getfacl files/
# file: files/
# owner: andyceo
# group: andyceo
user::rwx
user:www-data:rwx
user:andyceo:rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:user:www-data:rwx
default:user:andyceo:rwx
default:group::rwx
default:mask::rwx
default:other::rwx

Problem/Motivation

BlockContent::delete is not guaranteed to be called as its just a wrapper to Storage::delete

Steps to reproduce

Call \Drupal::entityTypeManager()->getStorage('block_content')->delete($some_entities) and notice that BlockContent::delete is not called.

Proposed resolution

Move the logic from BlockContent::delete to BlockContent::postDelete

Remaining tasks

Move the logic

User interface changes

API changes

Data model changes

Release notes snippet

entity_delete_multiple() calls $storage_controller->delete($entities) directly.

So any code present in the EntityClass::delete() method is never executed. Thus those two lines are not equivalent :

entity_delete_multiple('my_entity_type', array(1));
entity_load('my_entity_type', 1)->delete();

Problem : entity_delete_multiple() is marked deprecated, with the official recommendation being "use $storage_controller->delete($entities)", i.e we promote bypassing the $entity->delete() method, and deleting entities through the controller directly.

Right now, this means that entity-type-specific code for delete() should not be added in the entity type class, but in the storage controller.
However:
- nothing documents that, if that's how we want things to be, Entity::delete() should be final.
- there are definitely cases where the code would be storage-controller agnostic.

Note : The problem doesn't seem to arise for save, since we never added a generic entity_save() function.

Problem/Motivation

As detected by #2484693: Telephone Link field formatter InvalidArgumentException with 5 digits or fewer in the number, PHP does not guarantee the parse_url function results for URIs.
The problem is that PHP's parse_url is 'designed' for url's not for URIs.
Because by documentation parse_url:

This function is intended specifically for the purpose of parsing URLs and not URIs.

That can lead to many issues as this function is widely used in the Core as shown in the following table:

The ones which work:

Not OK:

Proposed resolution

We have Drupal\Component\Utility\UrlHelper (URL). We should create a similar UrIHelper (URI) class which is a true RFC 3986 parser.

Note: An external parser can't be used with our current Drupal requirements (PHP 5.6+ or php-intl requirements, both which Drupal doesn't have now)

Wrap parse_url in a drupal_parse_uri function so we can manage all specific cases and unit test it.

Remaining tasks

Discuss, Fix PHP, Fix Drupal, Enjoy

User interface changes

None.

API changes

An added URIHelper class.

Data model changes

None.

Problem/Motivation

This error occurred when adding an English translation of a German article (node/2/translations/add/de/en):

InvalidArgumentException: Invalid translation language (en) specified. in Drupal\Core\Entity\ContentEntityBase->addTranslation() (line 691 of core\lib\Drupal\Core\Entity\ContentEntityBase.php).

Steps to reproduce

1. Install using standard profile in English
2. Log in as a user with "translate any entity" permission - user 1 will do
3. Create an English article node
4. Install Content Translation module
5. Add German language
6. Enable content translation for article nodes with the default settings
7. Go to de/node/1/translations/add/en/de and add a translation
8. Go back to de/node/1/translations/add/en/de
9. You will get a fatal error

or

1. Go to content admin and use the filters to find the node I want to translate. Click its Translation operation link.
2. Add a French translation and save it. This takes me back to the content admin page.
3. Wait, I forgot to change something! But I can't see my node any more as it's not in the first page of results. I know, I'll just press Back and that'll get me back to the form I was just at, right?
4. BOOM.

Note there may be other ways to reproduce this such as unchecking Create new revision in the node and translation.

Proposed resolution

Redirect to the latest translation?
or something else

Remaining tasks

1. Create patch with test
2. Decide on where to send the user
3. Review
4. Commit

User interface changes

API changes

Synopsis

Changing the language of a translatable node with a translatable menu link from a "real" language (e.g. en) to a "pseudo" language (und or zxx) will result in an invalid argument exception: Invalid translation language (und) specified. or Invalid translation language (zxx) specified. respectively.

Note: If you are using the contributed token module, you will get a similar error in token_node_menu_link_submit() instead, since that function uses code very similar to _menu_ui_node_save().

Steps to reproduce

1. Install Drupal 8.4.x-dev (Standard profile) in English language
2. Enable Content Translation module
3. Add a second language (e.g. German) at Configuration > Regional and language > Language
4. Enable content translation with default settings for Content/Basic page and Custom menu link/Custom menu link at Configuration > Regional and language > Content language translation
5. Add a new basic page in English:
   • Fill in the title field (e.g. "123")
   • Check "Provide a menu link"
   • Leave everything else at default settings
   • Hit "Save and publish"
6. Edit your new basic page:
   • Set the language to either "- Not specified - " (und) or "- Not applicable -" (zxx)
   • Change the title of the menu link to "234"
   • Leave everything else alone
   • Hit Save

Expected result

• Language of basic page is either und or zxx, depending on your choice above
• Title of menu link is "234"
• Language of menu link is equal to language of basic page
• Neither basic page nor menu link have any translations

Actual result

White page with error message:

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

InvalidArgumentException: Invalid translation language (und) specified. in Drupal\Core\Entity\ContentEntityBase->addTranslation() (line 863 of core/lib/Drupal/Core/Entity/ContentEntityBase.php).

_menu_ui_node_save(Object, Array) (Line: 398)
menu_ui_form_node_form_submit(Array, Object)
call_user_func_array('menu_ui_form_node_form_submit', 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('node_page_edit_form', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm('node_page_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: 574)
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}()
call_user_func_array(Object, Array) (Line: 153)
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: 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: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Problem/Motivation

This is a follow-up to #3264120: Remove aggregator module and our dependency on Laminas Feed to discuss documentation updates regarding database dumps. I am copying comment #42, by catch, from that issue to here.

To fix (hopefully) the dumps, this is what I did:

gunzip core/modules/system/tests/fixtures/update/drupal-9.3.0.filled.standard.php.gz

Edited it and manually added the if statements from #3261629: Database dumps are no longer driver-agnostic (top and bottom of the file).

gzip core/modules/system/tests/fixtures/update/drupal-9.3.0.filled.standard.php

We should try to find a way to have standard steps to generate the dumps that don't reintroduce this issue though - it might been copying the dump scripts from 9.4.x or 10.0.x out of the git tree before switching to 9.3.0, or loading the database into 9.3.0, making changes, then switching to 9.4.x (or 9.3.whatever) before running the dump script. Or a time machine to apply the commit to 9.3.0

From catch these two issues have relevant notes about making dumps. #3275093: Drupal 9.3.0 dumps were created with PHP 8, needs to be PHP 7.3 and #3290810: Remove updates added prior to 9.4.0 (9.4.4 for ckeditor) and add 9.4.0 database dumps.

Steps to reproduce

Proposed resolution

Move the section, Creating your own dump to a new page and expand the instructions.

Remaining tasks

Decide on the text of the new instructions

User interface changes

API changes

Data model changes

Release notes snippet