Problem/Motivation

If you are using wikimedia/composer-merge-plugin on a project, then the new Recipe unpack Composer plugin will not work because in RootComposer.php

In RootComposer.php line 142:

  [AssertionError (1)]
  Composer root package and composer.json match

  private static function checkRootPackage(string $composer_content, RootPackageInterface $root_package): bool {
    $composer = JsonFile::parseJson($composer_content);
    return empty(array_diff_key($root_package->getRequires(), $composer['require'] ?? [])) && empty(array_diff_key($root_package->getDevRequires(), $composer['require-dev'] ?? []));
  }

In $composer the result of the merge from wikimedia/composer-merge-plugin are present.

Steps to reproduce

- Use wikimedia/composer-merge-plugin
- Have some composer.json with require and/or required-dev merged.

Proposed resolution

- Remove this check?
- Execute the unpack plugin before Composer merge plugin?

Remaining tasks

Determine solution.

Release notes snippet

Hello all,

Problem/Motivation

Drupal Version: 9.3.6
PHP Version: 8.1.3
Database: PostgreSQL
Database Version: 13.6
Development Environment: Docker 4 Drupal

I'm trying to create a view, using fields, one relationship with entity reference field between 2 content types and a contextual filter for content ID. When I try to provide the default value by content ID from URL, it works. Unfortunately, I have to provide default value as "raw value from URL" type. When I try to do it, I get the error message which I paste below:

SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input syntax for type bigint: "structure" LINE 6: ... ((field_measuring_stations_node_field_data.nid = 'structure... ^: SELECT "node_field_data"."langcode" AS "node_field_data_langcode", "field_measuring_stations_node_field_data"."langcode" AS "field_measuring_stations_node_field_data_langcode", "node_field_data"."created" AS "node_field_data_created", "node_field_data"."nid" AS "nid", "field_measuring_stations_node_field_data"."nid" AS "field_measuring_stations_node_field_data_nid" FROM "node_field_data""node_field_data" LEFT JOIN "node__field_measuring_stations""node__field_measuring_stations" ON node_field_data.nid = node__field_measuring_stations.field_measuring_stations_target_id AND node__field_measuring_stations.deleted = :views_join_condition_0 LEFT JOIN "node_field_data""field_measuring_stations_node_field_data" ON node__field_measuring_stations.entity_id = field_measuring_stations_node_field_data.nid WHERE ((field_measuring_stations_node_field_data.nid = :node_field_data_nid)) AND ("node_field_data"."type" IN (:db_condition_placeholder_1)) ORDER BY "node_field_data_created" DESC NULLS LAST LIMIT 5 OFFSET 0; Array ( [:node_field_data_nid] => structure [:db_condition_placeholder_1] => station [:views_join_condition_0] => 0 )

Steps to reproduce

The way to reproduce the error is:
- Install Drupal 9.3.6 with PHP 8.1.3 and PostgreSQL 13.6 (I'm going to paste docker-compose.yml and .env content as comments, if someone would like to use them).
- Create 2 different content types with entity reference one to another.
- Create a view with contextual filter, providing default value as "raw value from URL" type.

Proposed resolution

I've found this issue, while searching a solution. It could be helpful for debugging.

Best,
Orkut

Problem/Motivation

Follow-up from #2725415: Text Editor module fails to track usage of images uploaded in text_with_summary fields, allows uploaded images to be deleted

Some quotes from there:

WimLeers in #35

_editor_get_processed_text_fields() essentially hardcodes text.module's field types. I'm not sure how we can get around that. I can think of work-arounds that will enable Drupal 8 contrib to inject more field types, but I cannot think of a way to have them being found automatically; the entity/field system metadata is not rich enough for that AFAIK. In the grand scheme of things, I think this is only a small flaw though, and one that is not caused by or inherent to this issue.

Berdir in #36:

In TMGMT, I have a similar but not identical problem. Given an entity with field definitions, I want to extract all translatable text from it. That can be text fields but also string and other field types. (but not list_string, as the values there are machine names, basically, similar to format). Additionally, and that's more related to the problems that editor.module has, I would have to know how format/value/summary are connected and for which properties a format is. See http://cgit.drupalcode.org/tmgmt/tree/sources/content/src/Plugin/tmgmt/S...

Proposed resolution

Add more properties/metadata to data definitions to help solve those use cases.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Bump phpspec/prophecy to 1.23.0 to support PHP 8.5 (could be backported to 10.x)

Steps to reproduce

Part of #3523596: [meta] PHP 8.5 support

Proposed resolution

upgrade as of https://github.com/phpspec/prophecy/commit/b6eee2b6fc274809c107bb0fb6ee2...

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

When replacing a file and overwriting the existing file, current file sanitization rules are checked and an update message is displayed to the user, even if the filename is not being changed.

The file replacement behavior works as expected in this scenario, but the displayed status message then reflects a filename which does not exist in the file system.

Steps to reproduce

1. Upload a file
2. Edit the file's media entity
3. Replace the file with one with a different filename, and whose filename would normally be altered by the system's file sanitization rules
4. Check the "Overwrite original file" option
5. Save the media entity

See the resulting status message that states "Your upload has been renamed to XXXX.XXX" based on the file sanitization rules, which does not reflect the original filename at which the uploaded file now resides.

The status message comes from the file being renamed when added to the temporary file directory, but as it eventually ends up in the final file system destination, this difference is not clear to the user.

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

UniqueFieldConstraint enforces uniqueness of a single entity field value.

A constraint to enforce multi-key uniqueness would be very useful, for example on a join table.
Here's an example from stack.

I searched far and wide but was surprised that this feature request did not already exist.
Someone point me in the right direction if this is a dupe.

Currently if e.g. some plugin has a malformed annotation, the site will simply crash on plugin discovery / when clearing caches.

From my apache error.log:

Uncaught PHP Exception Doctrine\\Common\\Annotations\\AnnotationException: "[Syntax Error] Expected Value, got 'Mymod custom text' at position 28 in class Drupal\\mymod\\Plugin\\Block\\Block_CustomText." at /PATH/TO/D8/vendor/doctrine/annotations/lib/Doctrine/Common/Annotations/AnnotationException.php line 42, referer: http://d8lab.loc/admin/config/development/performance

and the page response:

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

Doctrine\Common\Annotations\AnnotationException: [Syntax Error] Expected Value, got 'Mymod custom text' at position 28 in class Drupal\mymod\Plugin\Block\Block_CustomText. in Doctrine\Common\Annotations\AnnotationException::syntaxError() (line 42 of vendor/doctrine/annotations/lib/Doctrine/Common/Annotations/AnnotationException.php).

Doctrine\Common\Annotations\DocParser->syntaxError('Value', Array) (Line: 861)
Doctrine\Common\Annotations\DocParser->Values() (Line: 833)
Doctrine\Common\Annotations\DocParser->MethodCall() (Line: 744)
Doctrine\Common\Annotations\DocParser->Annotation() (Line: 641)
Doctrine\Common\Annotations\DocParser->Annotations() (Line: 334)
Doctrine\Common\Annotations\DocParser->parse('/**
 * @Block("mymod_custom_text", "Mymod custom text")
 */', 'class Drupal\mymod\Plugin\Block\Block_CustomText') (Line: 67)
Doctrine\Common\Annotations\SimpleAnnotationReader->getClassAnnotations(Object) (Line: 91)
Doctrine\Common\Annotations\SimpleAnnotationReader->getClassAnnotation(Object, 'Drupal\Core\Block\Annotation\Block') (Line: 145)
Drupal\Component\Annotation\Plugin\Discovery\AnnotatedClassDiscovery->getDefinitions() (Line: 86)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() (Line: 283)
Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() (Line: 174)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 22)
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('system_breadcrumb_block') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('system_breadcrumb_block', Array) (Line: 76)
Drupal\Component\Plugin\PluginManagerBase->createInstance('system_breadcrumb_block', Array) (Line: 65)
Drupal\Core\Plugin\DefaultSingleLazyPluginCollection->initializePlugin('system_breadcrumb_block') (Line: 57)
Drupal\block\BlockPluginCollection->initializePlugin('system_breadcrumb_block') (Line: 80)
Drupal\Component\Plugin\LazyPluginCollection->get('system_breadcrumb_block') (Line: 45)
Drupal\block\BlockPluginCollection->get('system_breadcrumb_block') (Line: 138)
Drupal\block\Entity\Block->getPlugin() (Line: 113)
Drupal\block\BlockAccessControlHandler->checkAccess(Object, 'view', Object) (Line: 93)
Drupal\Core\Entity\EntityAccessControlHandler->access(Object, 'view', NULL, 1) (Line: 340)
Drupal\Core\Entity\Entity->access('view', NULL, 1) (Line: 56)
Drupal\block\BlockRepository->getVisibleBlocksPerRegion(Array) (Line: 137)
Drupal\block\Plugin\DisplayVariant\BlockPageVariant->build() (Line: 259)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 149)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
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)

I think we should do something other than just crash and burn.
However, it is important that the developer, or someone, notices that something is wrong.

My proposal:
- Skip, but remember, broken plugin annotations.
- Continue as usual, with the broken plugins omitted.
- If the cache is being cleared by a privileged user or on the cli, show a message mentioning where the broken annotations were found.
- In any case, log the event.
- Optionally, report broken plugin annotations in the status report page.

At this moment, blocks using “Block Context” only show the context being used when more than one context is available.

This is confusing for the end-user.

This is a follow-up from #2377757: Expose Block Context mapping in the UI see remarks in #65, #165 and #170. In the original patch there was a solution that added a label with a "context_slot_title". This was removed in https://www.drupal.org/node/2377757#comment-10365663 but never replaced with a something that actually shows the context with > 1 option.

For FacetAPI we are using the block context system. At this moment there is no way to see the facet name being placed by the block, if only 1 facet exists, which is very confusing and requires extra documentation or a form_alter on the block edit form, while this can easily be fixed in core.

As far as I know, the context system is not in use yet by any core feature as long as #2550199: Add a ContextProvider for Feeds is not in yet. This means there is no disruption at all. Edit: At least since #2339151: Conditions / context system does not allow for multiple configurable contexts, eg. language types, the context system is used in core.

Visual changes

Currently in HEAD:

With patch applied:

Why this should be an RC target

1. Without this patch, there is no mention of the context in the UI with only 1 context created, this is confusing for the user.
2. There is no disruption or change to current core behaviour, because this is not yet in place for anything in core.
3. There was similar functionality in core before this originally got comitted.

The code added in https://www.drupal.org/SA-CORE-2017-003 required writing to the session every time an anonymous user uploads a private file. This can have performance implications since the session cookie means those users won't see cached pages after the upload.

The information in the session needs to be there after the file is uploaded so that the user can preview the file before saving the content it is attached to. However, it doesn't need to be there after that.

Therefore, it would be a useful improvement if we can figure out how to delete the record of that file from the user's session once the content is permanently saved (or once the file is deleted). That way, in many cases the anonymous user who uploaded the file will be able to go back to receiving cached pages again.

There are a number of existing issues to improve the UX for the menu system in D8, many of which overlap, contradict, etc. A list:

• #103680: Path alias validation should test for full URLs
• #191360: Scalable menu selector
• #308263: Allow privileged users to bypass the validation of menu items
• #475968: Path helper interface for menu module
• #483078: Menu item name should be node title by default
• #491022: Remove weight field from menu item entity forms
• #594660: Rename default menu names
• #605894: Replace menu weight selector on node/add with relative item positioning
• #663946: Merge "List links" page into "Edit menu" page
• #969814: Suggestion how to improve "Menu" Usability
• #1101600: Users need to be able to select from list when adding menu items to a menu
• #1123662: Participants did not know how to get the path while creating a menu link
• #1123698: Participants do not understand the different menu options
• #1164706: Users thought "Navigation" menu was site navigation (but in Drupal-land "Main menu" would hve been the right choice)
• #1164716: Reduce prominence of filters on admin/content page
• #1164766: Two menu items with the same name (but different paths) cannot be distinguished.
• #1164780: Users miss the "Provide a menu link" checkbox on node/add
• #1164832: “Weight” field had no clear meaning, so users tried to apply a weight to help things get on the front page.
• #1164924: When creating or moving menus, users need a menu preview/demo page.
• #1167376: Unclear menu terminology while creating a menu link from a page
• #1167418: Workflow: What comes first while creating a page with a menu? Page or Menu?
• #1239666: Add the option to add custom menus to a content type on menu creating/editing
• #1440694: Add a menu item for each "Basic page" by default (Standard install profile)
• #1510532: [META] Implement the new create content page design

If I have a vocabulary where I want terms to have multiple parents and I want to achieve certain structure I REALLY need to play with the weights of terms to get proper structure since term can have multiple parents but it has only one sorting weight. And it makes things really hard some times.

So I don't see any reasom why the weight setting should not be moved into the taxonomy_term_hierarchy table where the weight would be set for each relationship separately.

--

TO DO:

• add weight column into the taxonomy_term_hierarchy table
• change the taxonomy form to allow selecing of multiple parents and assigning sorting weight to each relationship
• alter all funcitons and methods that get/set/manupulate the taxonomy_term_hierarchy table/term-term relationships
• update Views integration to take this new structure into account
• change the vocabulary terms overview form to utilize ajax since handling new structure with the old approach of splitting the number of results the user can drag & drop per page would be inefficient

Problem/Motivation

https://www.drupal.org/SA-2017-001 (commit: http://cgit.drupalcode.org/drupal/commit/?id=7b55855) introduced changes to \Drupal\search\Form\SearchBlockForm::buildForm() wrt cacheability, but didn't have test coverage yet.

Proposed resolution

Add missing test coverage.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

For UX and Frontend developers it is kind of difficult to get an overview of all available elements that can be rendered. There is a module for this called styleguide https://www.drupal.org/project/styleguide. But currently it has hardcoded all elements in drupal core with custom render arrays. So modules or new core developments offering new elements would have to be added later or by new contribs.

First off it might be a great addition to add the styleguide as a core module.
Second it would be helpfull to add example/dummy (or whatever you want to call it) method to the ElementInterface and Class to make it possible to generically render a render array with test/dummy data to render within this styleguide module. Maybe even make it return multiple render arrays when different sets of options give different visual outputs of Elements.

If this is implemented it would be very easy for core Elements and contrib Elements to automatically be added to the output of the styleguide. Also developers can see a nicely features example of an Element.

This issue has been cleared by the security team to handle in public.

By default, access checks will be performed on entity queries, like the one issued from UniqueFieldConstraintValidator. If you were to enable a module that implemented hook_query_TAG_alter() that targeted the access tag for that entity, the validator would only be verifying uniqueness across the field values that the current user can see, not across the whole entity type.

Admittedly, I'm not sure if this is more of a bug or a feature request because I'm not 100% clear on the desired functionality. The class comment says that it "Validates that a field is unique for the given entity type.", which suggests that it should be checking against all the values. But maybe there are cases where you wouldonly want to check against what the current user could view.

Problem/Motivation

Follow up of #2650434: Clearing cache via UI in translated language resets config translation of field labels to default language to address #2 and #3 in #2650434-150: Clearing cache via UI in translated language resets config translation of field labels to default language.

+++ b/core/lib/Drupal/Core/DrupalKernelInterface.php
@@ -15,6 +15,16 @@
+   * This event allows you to initialize overrides such as language to the
+   * services.

"language to the services" ?

+++ b/core/modules/language/src/EventSubscriber/LanguageRequestSubscriber.php
@@ -91,6 +106,7 @@ public function onKernelRequestLanguage(GetResponseEvent $event) {
+    $events[DrupalKernelInterface::CONTAINER_INITIALIZE_SUBREQUEST_FINISHED][] = ['onContainerInitializeSubrequestFinished', 255];

Why this service priority?

Proposed resolution

Remaining tasks

Originally reported by @Wim Leers

Problem/Motivation

Now that we no longer create body fields for new content types or block_content types. And in the process of moving their storage.body fields out lets update the createBodyField to not create text_with_summary fields but instead text_long field storage types.

Steps to reproduce

NA

Proposed resolution

Update the createBodyField() function to create text_long storage types.

Remaining tasks

Implement
Fix tests
Review

User interface changes

NA

Introduced terminology

NA

API changes

NA

Data model changes

NA

Release notes snippet

When creating new content types or block_content types in tests the body field will now be text_long fields vs text_with_summary.

Problem/Motivation

In D7 the contrib module imagecache_actions defines the "Change file format" image effect (submodule imagecache_colorations). This effect is able to alter the output format (and quality setting when the ImageMagick toolkit is in use) of an image derivative. However, in D8 in its current state, this is no longer possible.

What is the difference between D7 and D8 causing this?
In D7 you could get and change the image info array and the save method of the toolkit would use this info array to determine the image format to save to. In D8 the info array has been split over individual protected properties that are publicly exposed by getters only.

Note: this issue is part of #2105863: [meta] Images, toolkits and operations.

Proposed resolution

Instead of publicly exposing the info array or adding setters for the individual items in the info array, I suggest to add a saveOptions property or getSaveOptions() method to ImageInterfae. This property/method provides an alterable key-value store that can contain options that influence how an image is saved. Think of
- format (output as jpg, png or gif).
- quality for jpg.
- compression level and filters to use for png.
- progressive or not
- ...other?

This key-value store can be used by implementations of ImageToolkitInterface::save() to determine how to save the image.

The idea is that we change the API first with this additional property/method and then let toolkits decide what they accept, though we could (and should) document some keys that are foreseen (quality, format, compression, filter)

Why do it this way?
- This allows to fully utilize the abilities of the underlying toolkit, we are not restricting what parameters can be passed.
- It will make it easier to write a patch for issue #1310452: Allow to override the image toolkit's global JPEG/PNG quality value (or it will allow us to do it in contrib, if we fail to get that one committed in a timely manner).
- Time: do this API change now, fill in new options later (not being API changes, the latter can be done after beta).

Remarks:
- The png filter is defined differently by different toolkits. The PNG_FILTER_XXX constants are defined by GD and not available when GD is disabled and thus cannot be used by our image system. So a set of own constants that the different toolkits have to map themselves should
be part of introducing that option.
- This patch will only introduce the format and quality options as they are necessary to remove the regression. and don't need UI changes.
- I propose to introduce compression and filter in #1310452: Allow to override the image toolkit's global JPEG/PNG quality value as well as a UI (in image toolkit settings form) to define them.
- Setting to major as this is a regression from D7.

Remaining tasks

- review patch.

User interface changes

For now: none in the core UI.

API changes

Yes, but additions only.

Problem/Motivation

Given that web browsers can automatically decide which image variant to use with responsive image styles, it should not be required to select a fallback image.

Steps to reproduce

Proposed resolution

Make the "Fallback image style" field optional.

Remaining tasks

Make the "Fallback image style" field optional.
Update test coverage.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

If you didn't do the extra work to add fields as Base fields (who does on most projects?) then it results in N number of select queries to retrieve the data. Even when these fields have a cardinality of 1.

SqlContentEntityStorage::loadFromDedicatedTables

I was building a Performance test for a client project and it immediately jumped out at me that all the fields on the user were adding their own dedicated select query. In my case, this was on a user account. But it could just easily be on a node or some other entity. In many, many cases those fields are all single cardinality. So instead of N number of select queries, we could do a single (albeit potentially nasty) JOIN and retrieve all the field data for those in a single query instead of round tripping in a foreach for each of the fields.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

I actually used a performance test on a client test to tune a bunch of SQL queries on a REST endpoint. I had to make some changes though and copy in too much from PerformanceTestTrait

Steps to reproduce

PerformanceTestTrait assumes you are running a JavaScript test. In my case, I wasn't and never will need it. I just want a normal Functional test.
Secondly, a very minor thing but the logQuery massages some random variables and this list isn't easily extended.

Proposed resolution

1. Decouple the Selenium2 browser logic
2. Make logQuery easily extended.
3. Add to the list of massaged common logQuery

if (str_starts_with($query, 'SELECT "name", "value" FROM "key_value_expire" WHERE "collection" =')) {
      $args[':now'] = 'NOW';

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet