Updated: Comment #44

Problem/Motivation

Since path aliases are now entities, their previous custom storage has also been converted to an entity storage handler and the existing alias storage service has to be deprecated.

Proposed resolution

Deprecate \Drupal\Core\Path\AliasStorage and its service (path.alias_storage) in favor of getting the path_alias entity storage handler from the entity type manager.

Remaining tasks

Review the patch.

User interface changes

Nope.

API changes

A few methods from \Drupal\Core\Path\AliasStorageInterface have been moved as-is to \Drupal\Core\Path\PathAliasStorageInterface: preloadPathAlias(), lookupPathAlias(), lookupPathSource() and pathHasMatchingAlias().

A few methods from \Drupal\Core\Path\AliasStorageInterface have been deprecated without any replacement: aliasExists(), languageAliasExists() and getAliasesForAdminListing().

Problem/Motivation

Media bundles allow for source values to be mapped to fields on the bundle. The mapping is executed in Drupal\media\Entity\Media::prepareSave. There is an issue with how URLs are processed. Sometimes the metadata value is a string. Other times it is a \Drupal\Core\Url object. When the mapped value is saved, the assumption is that the value is a string. Take a look at Drupal\media\OEmbed\Resource::getAuthorUrl. This method calls Drupal\Core\URL::fromUri, which expects to receive a string. If it receives a URL object, then the result is a fatal error.

Steps to reproduce

1. Create a 'Remote Video' media bundle
2. Create an 'Author URL' field (Link field
3. Map this field to 'The URL of the author/owner'
4. Attempt to add a YouTube video as a Media entity
5. Note the following error for a Link field: Recoverable fatal error: Object of class Drupal\\Core\\Url could not be converted to string in /app/web/core/lib/Drupal/Core/Url.php on line 281

If the mapped field is a text field, then then the result is a different fatal error:

Or the following error for a Text field: <code> Uncaught PHP Exception Drupal\\Core\\Entity\\EntityStorageException: "Expected argument of type "string", "Drupal\\Core\\Url" given" at /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php line 847

Proposed resolution

Drupal\media\Entity\Media::prepareSave can check if a particular metadata is a URL object. If so, convert the object to a string before saving.

Remaining tasks

Submit patch.
Community review.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem

Patches to entities that are have Entity Reference fields that are set to use a View as the reference method fail with a 500 error, and the dreaded leaked metadata message:

“"The controller result claims to be providing relevant cache metadata, but leaked metadata was detected. Please ensure you are not rendering content too early. Returned object class: Drupal\\jsonapi\\ResourceResponse.””

Steps to Reproduce

• New Drupal 8.7 install
• Standard install profile
• Enable JSON:API and Serialization modules
• Ensure JSON:API is set to accept all methods (GET, POST, PATCH, DELETE)
• Create new content type
• Create a test node of the new content type
• Create Entity Reference view against the new content type
• Add reference field to Article content type selecting content.
  • Change the reference Method to Views: Filter by an entity reference view
  • Set the view to the newly created reference view
• Create a test Article node in Drupal, referencing the test node of the new CT.
• Find the same article in the JSON:API article endpoint
• After authenticating with external client, attempt a PATCH of the same article. No changes need to be made to the data.
• Witness the 500 error response.
• Edit the Article content type and change the Reference method to Default and check the box next to the new test content type,
• Try the same PATCH operation
• Witness a 200 OK response.

Additional information

Initial investigations have pointed the issue may actually stem from over in Viewsland. When patchIndividual() is executed, it necessarily goes and validates the entity prior to saving. From there, it looks like when the reference field is validated, it uses the entity reference view to perform that validation. It would seem that views considers this an HTML View according to the comments in Views’ StylePluginBase - see lines 702-713:

// Views may be rendered both inside and outside a render context:
// - HTML views are rendered inside a render context: then we want to
//   use ::render(), so that attachments and cacheability are bubbled.
// - non-HTML views are rendered outside a render context: then we
//   want to use ::renderPlain(), so that no bubbling happens
if ($renderer->hasRenderContext()) {
  $renderer->render($data);
}
else {
  $renderer->renderPlain($data);
}

I can confirm that the error isn't thrown if you force the call through renderPlain().

Obviously, it would seem that the real issue might indeed be Views (why render the whole view like this for field validation?), or even in the caching system as a whole (why hit these cache problems when doing a PATCH?), but I haven’t had enough cycles to keep diving the rabbit hole and figured (with @gabesullice’s advice) to go ahead and open the issue here for further exploration and discussion.

Hello,

I cloned the 8.7.6 version of the core. Then I made a patch to views module (see attachments).
When I add this patch to my composer.json like this :

{
...
"patches": {
"drupal/core": {
"Correct date filter bug": "patch/views_filter_exposed_filter_date.patch"
}
}
}

it constantly throws an error:

Could not apply patch! Skipping. The error was: Cannot apply patch patch/views_filter_exposed_filter_date.patch

Why does it happen ? Thank you in advance for your ideas.

After upgrading to 1.24 we've experienced server crashing performance issues with filters including multiple entity references. I've reduced an example request down to what seems to be a minimal set of filters that lead to a timed out response.

  ?filter[status][value]=1
  &filter[node--location][condition][path]=field_location.uuid
  &filter[node--location][condition][value][]=1c28abaa-f088-404f-925f-263838332601
  &filter[node--location][condition][operator]=IN
  &filter[taxonomy_term--audience][condition][path]=field_event_audience.uuid
  &filter[taxonomy_term--audience][condition][value][]=9422db2a-0071-4d3e-8b33-f3762c26fc19
  &filter[taxonomy_term--audience][condition][operator]=IN
  &filter[taxonomy_term--audience][condition][memberOf]=audience
  &filter[audience][group][conjunction]=OR
  &filter[parent][condition][path]=field_event_audience.parent.uuid
  &filter[parent][condition][value][]=9422db2a-0071-4d3e-8b33-f3762c26fc19
  &filter[parent][condition][operator]=IN
  &filter[parent][condition][memberOf]=audience

I haven't been able to test this with 2.x yet as we're relying on consumer_image_styles at the moment and it does not appear to be compatible with 2.x. That's the next step but wanted to report this in case anyone has other ideas in the meantime.

Problem/Motivation

The global variables base_url, base_path and base_root as well as the base_path() function are still used throughout core. Removal of those is tricky, since there is no direct replacement on the Symfony request object for those. The globals in Drupal are always relative to the application directory, while Symfony $request->getBaseUrl() returns the base URL relative to the front controller.

For example when running the installer (hxxp://example.com/drupal/core/install.php), Symfony will report the base URL including the core path, while $base_url will only be up to drupal.

Proposed resolution

Since there is no direct replacement in Symfony, it is necessary to introduce an additional service which is capable of returning the base URL and the base path relative to the application (not the front controller).

Remaining tasks

User interface changes

API changes

Data model changes

Hi everyone!
I tried to find something related to this issue but wasn't able. Here's the description:

- You need a multilingual site with at least 4 languages to test this
- You need to enable content moderation (use default editorial workflow states, draft, published, archived), languages (remember, at least 4) and revisions.

Steps:

1) Create a content in any language, doesn't matter if published or in draft state
2) Create a default translation in language B: can either be published or archived
3) Create a draft translation in language C: at this point you should be able to see 3 versions of your content in the node/nid/translations page
4) Create a default translation in language D: can be archived or published, doesn't matter. At this point you can see the issue.

This is a screenshot of the translations UI at step (3)

This is a screenshot of the table content_moderation_state at step (3)

And these are the same screenshots after step (4)

The line where content_entity_revision_id = 20 and langcode = es is no longer on the second screenshot, and also the actual translation disappeared from the UI and from the site.

Here is a video I made with all these steps (index in description of the video):

youtube video

Notice that the actual revision is still in the database, in the end of the video I get it back by adding it again and reverting to the previous revision. This is a workaround and does not fix the issue.

So far our actual workaround has been to force the first state of every translation to be in draft using the patch from this issue:
When adding a new translation the entity should start from the draft state

Problem/Motivation

This issue is a master list of things to be done before the 9.x branch is opened. #2822727: [policy, no patch] Adopt a continuous API upgrade path for major version changes defines what can happen in 9.x, so does https://dri.es/making-drupal-upgrades-easy-forever. We should keep a list of the steps here, but make child issues for each.

Opening the Drupal 9 branch allows a few things to happen.

1. We can upgrade Drupal's PHP requirements to require Symfony 4 or higher (and Twig etc.)
2. Contrib modules can test against the Drupal 9 branch to ensure they still work
3. We can begin removing deprecated code, and backwards compatibility layers

In order for the Drupal 9 branch to be useful, we need to be able to do all three of these immediately when the branch is opened.

Proposed resolution

The 9.0.x branch will open when the must-haves for the alpha are complete or when 8.9.x is opened according to the normal release schedule.

Must-haves prior to tagging Drupal 9.0.0-alpha1

1. #2976394: Allow Symfony 4.4 to be installed in Drupal 8 - unless Drupal 8 is passing tests against Symfony 4, it won't be possible to update our dependencies in 9.x.
2. All deprecated code usages must be removed and deprecations properly documented - we can't remove deprecated code that is called by Drupal core. (see the @deprecated tag) #3007329: [META] Drupal 8 core must not use any deprecated code, must be enforced by automated testing
3. Contrib modules must be able to test against Drupal 9 without having to make an entire new code branch. #2807145: [policy no, patch] Allow contrib projects to specify multiple major core branches and #2313917: Core version key in module's .info.yml doesn't respect core semantic versioning enable this

Once these issues are resolved, a Drupal 9 branch becomes useful, because it allows for contrib testing.

Additionally, there are some issues that we should resolved before Drupal 9 beta 1 is tagged:

Must-haves prior to tagging Drupal 9.0.0-alpha1

1. All Drupal 6 and Drupal 7 -> Drupal 8/9 content migrations should be stable. In practice this mostly means multilingual migrations #2208401: [META] Stabilise Migrate Drupal Multilingual module . If we don't do this, we can't expect people to migrate of Drupal 6 and Drupal 7

   There may be minor configuration translation migrations or contrib -> core migrations still outstanding which would be great to clean up but should not actually block release.

2. We should have adopted a policy for PHP 7.x version support, as this needs to be announced as far as possible before the LTS and 9.0.0 release so hosts have time to upgrade. #2917655: [policy] Decide on PHP 7.x support status
3. We should provide accurate update recommendations (9.0, not a non-existent minor version of Drupal 8) on the Status Report (/admin/reports/status). #2998287: Provide accurate information on the security coverage of the 8.x final minor and LTS, and recommend updating to the next major version when appropriate.
4. We should have a proper policy for CSS and markup changes, see #2659890: [Plan] Drupal 9 markup and CSS backwards compatibility

Remaining tasks

User interface changes

API changes

Data model changes

Core is in the process of adding support for manifest.json files.

#2698127: Extend site information page to generate a manifest.json file

This give designers the ability to specify 'umami demo' specific icons, for desk-top and mobile, at various sizes.

I want to split off the design of the various umami icons into a separate issue.

It is common to support :-

A) A main SVG icon which, because it inherently scales, can cover many of the standard sized, from which the OS makes its selection.

B) For browser which don't do SVG provide basic PNG support.

The manifest support 'theme_color' and 'background_color' -- I think the umami community should makes those decisions for itself.

See below for an example manifest.json file :-

{
  "lang": "en",
  "dir": "ltr",
  "name": "Very good Drupal Website™",
  "short_name": "Drupal Website™",
  "icons": [{
        "src": "my/default/theme/logo.png",
        "sizes": "144x144"
      }],
  "start_url": "/",
  "display": "browser",
  "orientation": "portrait",
  "theme_color": "#ffffff",
  "background_color": "#ffffff"
}

Problem/Motivation

While working toward #2982680: Add composer-ready project templates to Drupal core., we discovered that the Vendor Hardening Plugin sometimes fails to work, throwing an error:

Fatal error: Uncaught Error: Class 'Drupal\Component\FileSecurity\FileSecurity' not found in phar:///Users/ganderson/bin/composer/src/Composer/Plugin/PluginManager.php(196) : eval()'d code:245

The problem is that the drupal/core-file-security component is only available as a replaced component in drupal/core; it is not recognized as a standalone Composer package during the autoload dump phase.

Proposed resolution

Removing drupal/core-file-security from the replace section of drupal/core's composer.json file clears up this problem. We can instead add it as a "path' repository, so that it will be discovered and used when doing core Drupal development on the drupal/drupal project.

Remaining tasks

Under this configuration, Composer-managed Drupal sites build on drupal/core rather than drupal/drupal (like tarball releases) will have two copies of drupal/core-file-security: one in the core directory, and one in vendor/drupal/core-file-security. The copy in vendor is the one that will be used.

To avoid confusion, we could relocate the drupal/core-file-security component out of the core directory, and put it somewhere else. Perhaps the path composer/Component would work (next to the existing composer/Plugin path, which exists for a similar reason).

Follow-on Tasks

• #3076600: Create drupal/core-recommended metapackage
• #2982680: Add composer-ready project templates to Drupal core.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

tbd

If you already have an old d8 database, and you mistakenly specify that database during the install, the installer says "Drupal already installed" even if it isn't. I'm not sure if there's a way Drupal could distinguish between situations where the specified database exists and contains Drupal data, but the site is not actually installed, and situations where the database is set up and Drupal has been successfully installed. If it's possible to make that distinction, the "Drupal already installed" heading could be changed to something more helpful, like "You specified a database that already contains Drupal data. To continue with the install, you need to delete or empty that database, or specify a different database."

Granted, the bullets below the heading should help with that, but the heading itself can cause confusion.

We (Acquia) recently did some user testing with Umami (I'm still working out how to make the videos / data from this public). Pretty much every participant got botched up at the Recipe Category field and not understanding what they should type in there. And since there are only a few options to choose from, a drop-down is a better UX pattern here.

(Because there are far more terms in the "Tags" vocabulary, they were able to figure the autocomplete one there out better, though the interaction still needs work, but that's a core bug, not yours. :))

Problem/Motivation

The different views that are displaying content in Umami, such as /recipes and /articles, display only original/translated items in the current language.
When adding a new language, the list of recipes and articles will appear empty in that language, until they will be translated to that language.

Proposed resolution

Change the settings of these views to display all available recipes in all languages.
When a new language is added displaying the view will display items in all languages.

Remaining tasks

Create a patch that uses the settings from this screenshot: https://www.drupal.org/project/language_hierarchy/issues/2825851#comment...

User interface changes

API changes

Data model changes

Release notes snippet

If you go to the admin/content view, you will find an action called "Save content".
I have been trying to get what this action is doing? it's not clear at all. since Drupal by default saves the content and it doesn't have a wordpress-like autosave feature I guess.

maybe we need to hide this action and add to the autosave https://www.drupal.org/project/autosave_form module instead.

Backport of D8 issue #936316: CSS aggregation strips some essential whitespace within strings

When performing AJAX actions the site should populate an aria-live region with a loading message so that assistive technology (i.e. screen readers) is informed that a change is in progress.

Patch is based on patch in https://www.drupal.org/project/drupal/issues/2907132 by @ckueda. Related to https://www.drupal.org/project/drupal/issues/2973140.

Problem/Motivation

Given :

1. A backend form
2. Containing a Managed file form element, containing at least one file on submission
3. Sending an e-mail on submit (containing the uploaded files as attachments for exemple)
4. E-mail has to use another theme than the backend (active) one.
5. {{ directory }} variable is used in the e-mail template (for example to generate absolute paths to images)

The active theme can't be fully overriden (for example using \Drupal::theme()->setActiveTheme()) because :

1. \Drupal\file\Element\ManagedFile::processManagedFile() load the list of files during the page load before form submission
2. $variables['directory'] is statically cached during the page load by _template_preprocess_default_variables() (through the template_preprocess() function)

So the {{ directory }} variable in the final rendering get the path from the theme of the form, not from the override. It doesn't reflect the actually active theme, this variable is not reliable.

We don't get this behavior if the managed file field is empty, because the list of links is empty so not rendered.

Proposed resolution

Initialize $variables['directory'] as empty in template_preprocess() and set it to the active theme out of the template_preprocess() scope (for example in \Drupal\Core\Theme\ThemeManager::render() where $variables['directory'] is used as a flag) .

Remaining tasks

To be determined.

User interface changes

No user interface change to expect.

API changes

No API change to expect.

Data model changes

No data model change to expect.

Problem/Motivation

There's a new Url($newurl->getRouteName(), $newurl->getRouteParameters(), $language); call in LanguageDropdownForm which fatals for base: URLs.

Proposed resolution

There's no need for this.

Remaining tasks

Just remove it.

Problem/Motivation

From #2935951-43: Copy migrate source plugin from migrate_drupal_d8 into migrate_drupal, we discussed extracting getDefinitionFromEntity from ContentEntity and EntityContentBase into a re-usable trait. Let's do it.

Proposed resolution

Remaining tasks

Extract the method into a trait.

User interface changes

API changes

Data model changes

Problem/Motivation

@rainbreaw has recently been instrumental in unblocking several core initiatives that have needed accessibility review. Currently @andrewmacpherson is the only topic maintainer, and has done a great job, but as some user-facing core initiatives struggle to be as accessible as they can be and improve their UX for all users, it would be very helpful to have additional experts working on this front and guiding the accessibility gate.

Proposed resolution

Add @rainbreaw to MAINTAINERS.txt as an accessibility topic maintainer.

Remaining tasks

Get a +1 from Rain, plus whatever additional sign-offs are needed. Then commit the patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.