Problem/Motivation

As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.

There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-prop, which targets the jQuery prop function.

Steps to reproduce

In core/.eslintrc.jquery.json Change "jquery/no-prop": 0, to "jquery/no-prop": 2, to enable eslint checks for uses of jQuery prop(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directory.

Proposed resolution

Replace usage of jQuery.prop with vanilla js alternatives.

Remaining tasks

• Review MR !4266
• Close MR !1252

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Problem/Motivation

Symfony 6.4.0-RC1 is available

Steps to reproduce

$ composer outdated

Direct dependencies required in composer.json:
mglaman/phpstan-drupal             1.2.2        1.2.4      
phpunit/phpunit                    9.6.13       10.4.2     
symfony/browser-kit                v6.4.0-BETA3 v6.4.0-RC1 
symfony/css-selector               v6.4.0-BETA3 v6.4.0-RC1 
symfony/dom-crawler                v6.4.0-BETA2 v6.4.0-RC1 
symfony/error-handler              v6.4.0-BETA1 v6.4.0-RC1 
symfony/lock                       v6.4.0-BETA3 v6.4.0-RC1 
symfony/phpunit-bridge             v6.4.0-BETA3 v7.0.0-RC1 
symfony/var-dumper                 v6.4.0-BETA3 v6.4.0-RC1 
														   
Transitive dependencies not required in composer.json:     
doctrine/annotations               1.14.3       2.0.1      
doctrine/lexer                     2.1.0        3.0.0      
phpunit/php-code-coverage          9.2.29       10.1.8     
phpunit/php-file-iterator          3.0.6        4.1.0      
phpunit/php-invoker                3.1.1        4.0.0      
phpunit/php-text-template          2.0.4        3.0.1      
phpunit/php-timer                  5.0.3        6.0.0      
sebastian/cli-parser               1.0.1        2.0.0      
sebastian/code-unit                1.0.8        2.0.0      
sebastian/code-unit-reverse-lookup 2.0.3        3.0.0      
sebastian/comparator               4.0.8        5.0.1      
sebastian/complexity               2.0.2        3.1.0      
sebastian/diff                     4.0.5        5.0.3      
sebastian/environment              5.1.5        6.0.1      
sebastian/exporter                 4.0.5        5.1.1      
sebastian/global-state             5.0.6        6.0.1      
sebastian/lines-of-code            1.0.3        2.0.1      
sebastian/object-enumerator        4.0.4        5.0.0      
sebastian/object-reflector         2.0.4        3.0.0      
sebastian/recursion-context        4.0.5        5.0.0      
sebastian/type                     3.2.1        4.0.0      
sebastian/version                  3.0.2        4.0.1      
symfony/console                    v6.4.0-BETA3 v6.4.0-RC1 
symfony/dependency-injection       v6.4.0-BETA3 v6.4.0-RC1 
symfony/event-dispatcher           v6.4.0-BETA1 v6.4.0-RC1 
symfony/filesystem                 v6.4.0-BETA1 v6.4.0-RC1 
symfony/finder                     v6.4.0-BETA3 v6.4.0-RC1 
symfony/http-foundation            v6.4.0-BETA3 v6.4.0-RC1 
symfony/http-kernel                v6.4.0-BETA3 v6.4.0-RC1 
symfony/mailer                     v6.4.0-BETA3 v6.4.0-RC1 
symfony/mime                       v6.4.0-BETA1 v6.4.0-RC1 
symfony/process                    v6.4.0-BETA3 v6.4.0-RC1 
symfony/routing                    v6.4.0-BETA3 v6.4.0-RC1 
symfony/serializer                 v6.4.0-BETA3 v6.4.0-RC1 
symfony/validator                  v6.4.0-BETA3 v6.4.0-RC1 
symfony/yaml                       v6.4.0-BETA3 v6.4.0-RC1 

Proposed resolution

composer update --with=phpunit/phpunit:^9

$ composer-lock-diff --no-links
+------------------------------+--------------+------------+
| Production Changes           | From         | To         |
+------------------------------+--------------+------------+
| symfony/console              | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/dependency-injection | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/error-handler        | v6.4.0-BETA1 | v6.4.0-RC1 |
| symfony/event-dispatcher     | v6.4.0-BETA1 | v6.4.0-RC1 |
| symfony/filesystem           | v6.4.0-BETA1 | v6.4.0-RC1 |
| symfony/finder               | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/http-foundation      | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/http-kernel          | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/mailer               | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/mime                 | v6.4.0-BETA1 | v6.4.0-RC1 |
| symfony/process              | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/routing              | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/serializer           | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/validator            | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/var-dumper           | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/yaml                 | v6.4.0-BETA3 | v6.4.0-RC1 |
+------------------------------+--------------+------------+

+------------------------+--------------+------------+
| Dev Changes            | From         | To         |
+------------------------+--------------+------------+
| mglaman/phpstan-drupal | 1.2.2        | 1.2.4      |
| symfony/browser-kit    | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/css-selector   | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/dom-crawler    | v6.4.0-BETA2 | v6.4.0-RC1 |
| symfony/lock           | v6.4.0-BETA3 | v6.4.0-RC1 |
| symfony/phpunit-bridge | v6.4.0-BETA3 | v6.4.0-RC1 |
+------------------------+--------------+------------+

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As things go, within hours after #3399123: Upgrade JavaScript dependencies to latest minor/patch releases was committed, cspell released a new major version.

$ yarn outdated
[snipped]
cspell                  7.3.9   7.3.9  8.0.0

Let's get this into 10.2.x.

Steps to reproduce

Proposed resolution

$ yarn add -D cspell
$ yarn spellcheck:make-drupal-dict

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

In modal dialogs content, including buttons and other interactive elements may be clipped out of view. Modal does not handle breakpoints properly.

Steps to reproduce

Example screenshots from latest Filed UI with Macbook with browser at about 50% and 60% widths where 50% triggers a breakpoint but about 51% to 75% clips content.

Problem/Motivation

#3379520: [Ignore] In space (and/or this issue), no one can hear patches scream VIII

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Currently, date range fields are always displayed with start and end date.

There are situations where only one of these values should be displayed, e.g. when creating a view for upcoming events where we only want to show the start date.

Proposed resolution

Add an option to the date range formatter to select both start and end date (default), only start date or only end date.
Show the separator field only when the first option is selected.

Remaining tasks

• Address patch review in #30
• Issue Summary update (#75)

User interface changes

Content type display:

Views:

API changes

Data model changes

New from_to configuration setting.

Release notes snippet

You can now customize the way date ranges are displayed to match your specific needs. The new display option offers three choices:

• Start and End Date (Default): This is the default behavior, displaying both the start and end dates in your date ranges, just as you've always seen.
• Start Date Only: Choose this option to display only the start date in your date ranges. This is perfect for situations where you want to highlight the beginning of an event or a period.
• End Date Only: Opt for this format if you wish to showcase only the end date in your date ranges. It's ideal when you want to emphasize the conclusion of an event or a time frame.

This new feature offers increased flexibility, making it easier to tailor your date range presentations to your site's unique requirements.

Problem/Motivation

I had one media field which allows to upload JPG, PNG's and SVG's at the same time. When I tried to apply the image style with webp converter in place then the SVG's image got broken. As core was unable to convert the SVG to webp.

Steps to reproduce

1. Create one image style and select webp converter effect 'Convert Webp'
2. Create some media or image field (allow uploading various image types along with SVG) and then select this image style there (that was created in step 1 )
3. When SVG image is uploaded and displayed on front-end then it is broken.

Proposed resolution

As SVG is already very light in size, so I belief we can have a setting in place to bypass translating any of images that can not be converted to webp format. SVG is one such example. But having a configuration to specify the fallback rules to restrict (or allow) on some specific formats will make life easy.

Remaining tasks

1. Backend Configuration to allow/disallow certain types of images to be converted.
2. Deliver function need to be updated to consider the configuration to serve the fallback styles accordingly.

User interface changes

1. Backend Configuration should be there for Admin usage to restrict/ allow the webp conversion on some specific types when this effect is selected. Please see the attachment

Problem

Because DependencySerializationTrait uses get_object_vars() to collect serializable service properties, but that function cannot access private properties. Because of that, the code below fails, because $entityTypeManager becomes null when deserialization happens.

<?php

final class MyForm extends \Drupal\Core\Form\FormBase {

  private $entityTypeManager;

  public function __construct(\Drupal\Core\Entity\EntityTypeManagerInterface $entityTypeManager) {
    $this->entityTypeManager = $entityTypeManager;
  }

  public static function create(\Symfony\Component\DependencyInjection\ContainerInterface $container) {
    return new static(
      $container->get('entity_type.manager')
    );
  }
}

This seems to be a known limitation for 2 years or so: https://www.drupal.org/project/drupal/issues/2727011#comment-12619886

Proposed solution

Use Reflection or Clousers instead of get_object_vars().

Related

https://www.lambda-out-loud.com/posts/accessing-private-properties-php/

PS.: We are using this fix since patch 1 was submitted here in production without noticeable unexpected sideeffects.

Problem/Motivation

Following the migration of my Drupal 9 website to Drupal 10, it became impossible to load images in the field_image of the nodes.

Do you have any idea where this error could come from?
User error: "1" is an invalid render array key in
Drupal\Core\Render\Element::children()
(/var/www/clients/..../core/lib/Drupal/Core/Render/Element. php line 98)

sorry for my English
Thank you very much if you take the time to tell me an idea

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Observed in #3315319-9: Random fails in Drupal\Tests\ckeditor5\FunctionalJavascript\AdminUiTest and Drupal\Tests\ckeditor5\FunctionalJavascript\CKEditor5Test and in #3315490-24: Random fail in Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockPrivateFilesTest: many tests wait too little (not for enough AJAX responses to arrive) or too much (waiting for an AJAX response that will never come because no AJAX request was triggered, hence waiting for the default timeout of 10 seconds for no reason at all).

Proposed resolution

Add a new ::assertExpectedAjaxRequest() method with a $count parameter to allow explicit testing of the number of AJAX responses any test item should trigger.

Make ::assertWaitOnAjaxRequest() use this new method, but without the assertion.

If either method is called when there are zero ajax requests made, a deprecation error will be fired.

Remaining tasks

User interface changes

None.

API changes

TBD

Data model changes

None.

Release notes snippet

TBD

Description: Within the “Create Node” page, when the “File” field is accessed, JAWS announces “File file upload edit browse…” and does not announce the additional information “One file only. 256 MB limit. Allowed types: pdf doc docx xls xlsx ppt pptx csv txt”. Instead, JAWS is expected to announce the label and the additional information e.g. “File upload edit browse, One file only. 256 MB limit. Allowed types: pdf doc docx xls xlsx ppt pptx csv txt”.

• Testing was performed using JAWS v18.0.2945.
• This defect exists in IE 11 and Google Chrome v68.0.3440.106.

Steps to reproduce:

1. Add a file field to a content type: Limit 1, add as many "Allowed file extensions" as you choose.
2. Open JAWS v18.0.2945.
3. Create/Edit a node that has the file field.
4. Use the Tab key to navigate to the “File” field.

Notice that JAWS announces “File file upload edit browse…” and does not announce the additional information “One file only. 256 MB limit. Allowed types: pdf doc docx xls xlsx ppt pptx csv txt”.

Expected result: All additional information needed to complete form fields is expected to be announced by JAWS.

I have a table with ~ 3 billion records.

Currently a simple SELECT query with ORDER BY primary key takes ~225ms. If I drop "NULLS LAST" from the pgsql\Select::orderBy it takes just 2 ms. On more complex queries the difference is much more noticeable.

The problem was already reported by @adam-vessey in https://www.drupal.org/project/drupal/issues/2443657#comment-14870439

PostgreSQL, and it seems like the changes made here on their own would interfere with index usage in PostgreSQL, at least with ordering operations since indexes in PostgreSQL: https://www.postgresql.org/docs/current/indexes-ordering.html

By default, B-tree indexes store their entries in ascending order with nulls last

So, since the "order by" statements no longer matches the indexes (as they're created by default), things are likely to fall back to sequential scans in situations where it otherwise would be fine.

Could/should we start adding "NULLS FIRST" to general index definitions that we generate for PostgreSQL, such that indexes will match the expectations of "order by" statements we pass it, and so facilitate their use?

Hi,
I have the drupal set up with version 10.1.6 with simple search engine assiociated with content type. I am enabling the SSO, but from security team i have got the report "42424 - CGI Generic SQL Injection (blind)" error.

I have tried tor emove some of the contributed modules like Taxonomy menu, CSV importer, serialization etc.., but still facing same issue. I ahve not modified any core functionalitties or written any customized queries. Please let me know any suggestion to overcome this vulnarability. Mention if you think any contributed modules will cause this isse if any.

More Details:
Synopsis
A CGI application hosted on the remote web server is potentially prone to SQL injection attack.
Description
By sending specially crafted parameters to one or more CGI scripts hosted on the remote web server, Nessus was able to get a very different response, which suggests that it may have been able to modify the behavior of the application and directly access the underlying database.

An attacker may be able to exploit this issue to bypass authentication, read confidential data, modify the remote database, or even take control of the remote operating system.

Note that this script is experimental and may be prone to false positives.
See Also
http://www.securiteam.com/securityreviews/5DP0N1P76E.html
http://www.nessus.org/u?ed792cf5
http://www.nessus.org/u?11ab1866
Solution
Modify the affected CGI scripts so that they properly escape arguments.
Risk Factor
High
CVSS v3.0 Base Score
8.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L)
CVSS v2.0 Base Score
7.5 (CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P)
References
XREF CWE:20
XREF CWE:77
XREF CWE:89
XREF CWE:91
XREF CWE:203
XREF CWE:643
XREF CWE:713
XREF CWE:722
XREF CWE:727
XREF CWE:751
XREF CWE:801
XREF CWE:810
XREF CWE:928
XREF CWE:929
Plugin Information
Published: 2009/11/06, Modified: 2022/10/28
Plugin Output
tcp/443/www

Using the GET HTTP method, Nessus found that :

+ The following resources may be vulnerable to blind SQL injection :

+ The 'pass' parameter of the /user/login CGI :

/user/login?form_build_id=form-nyrOf9WeeWVSuZEsoiKUyqZDOlXQh69K_YTFUNUuo
FY&op=Log%20in&name=&form_id=user_login_form&pass=zzform-nyrOf9WeeWVSuZE
soiKUyqZDOlXQh69K_YTFUNUuoFY&op=Log%20in&name=&form_id=user_login_form&p
ass=yy

-------- output --------

+ The 'op' parameter of the /user/login CGI :

/user/login?form_build_id=form-nyrOf9WeeWVSuZEsoiKUyqZDOlXQh69K_YTFUNUuo
FY&pass=&name=&form_id=user_login_form&op=Log%20inzzform-nyrOf9WeeWVSuZE
soiKUyqZDOlXQh69K_YTFUNUuoFY&pass=&name=&form_id=user_login_form&op=Log%
20inyy

-------- output --------

+ The 'name' parameter of the /user/login CGI :

/user/login?form_build_id=form-nyrOf9WeeWVSuZEsoiKUyqZDOlXQh69K_YTFUNUuo
FY&pass=&op=Log%20in&form_id=user_login_form&name=zzform-nyrOf9WeeWVSuZE
soiKUyqZDOlXQh69K_YTFUNUuoFY&pass=&op=Log%20in&form_id=user_login_form&n
ame=yy

-------- output --------

+ The 'form_id' parameter of the /user/login CGI :

/user/login?form_build_id=form-nyrOf9WeeWVSuZEsoiKUyqZDOlXQh69K_YTFUNUuo
FY&pass=&op=Log%20in&name=&form_id=user_login_formzzform-nyrOf9WeeWVSuZE
soiKUyqZDOlXQh69K_YTFUNUuoFY&pass=&op=Log%20in&name=&form_id=user_login_
formyy

-------- output --------

/user/login?form_build_id=form-nyrOf9WeeWVSuZEsoiKUyqZDOlXQh69K_YTFUNUuo
FY&pass=&op=Log%20in&name=&form_id=user_login_formzzform-nyrOf9WeeWVSuZE
soiKUyqZDOlXQh69K_YTFUNUuoFY&pass=&op=Log%20in&name=&form_id=user_login_
formyy {2}

-------- output --------

Problem/Motivation

Quoting @bircher, maintainer of https://www.drupal.org/project/config_split, https://www.drupal.org/project/config_filter, etc., after I asked him What concrete things have gone wrong due to bugs in configuration, especially if they were caused by overriding/splitting/… — any of the advanced Configuration Management things?

what can go wrong, well sorting mostly... oh and to know if a key is required or not. So sometimes when a value is null or the array empty we can omit the key and sometimes not

👉 This issue aims to address the "sometimes […] we can omit the key and sometimes not" part. See #3364109: Configuration schema & required values: add test coverage for `nullable: true` validation support for the other part.

When talking about "keys" here, we're referring to the keys in a type: mapping. The root of every configuration object is a mapping — so the top-level keys you see in any MODULENAME.settings.yml file for example is a key.

For configuration management purposes it's critical to know which keys are required and which ones can be omitted. This can be entirely arbitrary: it depends on the PHP code that interacts with the stored configuration whether the key is required or optional.

In other words: today requiredness is implicit: it depends on the module's code. It's impossible to know based on the config schema. Only with trial & error can you figure this out … and even then, a single new code path could possibly cause a key that seemed optional to suddenly be required.

In general, most keys are implicitly required, with the exception of third_party_settings and subkeys of dependencies.

This leads to configuration management modules needing to add hardcoded hacks such as

              // @todo find a better way to know which elements are required.
              if ($type->getDataDefinition()->getDataType() === 'config_dependencies') {
                // Except for sub keys of dependencies.
                unset($diff[$key]);
              }

Steps to reproduce

Use modules like https://www.drupal.org/project/config_split and https://www.drupal.org/project/config_filter.

Proposed resolution

#3324150: Add validation constraints to config_entity.dependencies introduced the ValidKeys constraint. It can be configured in one of two ways:

1. ValidKeys: ['foo', 'bar']→ allows these two keys
2. ValidKeys: '<infer>'→ automatically infers the allowed keys based on the keys defined for this mapping in the config schema — this removes the need to sprinkle the entire config schema with statements like the above

But that only determines which keys are allowed, not which ones are required.

1. So let's update the existing ValidKeys constraint to not just allowing keys, but requiring keys.
2. Only keys that have nullable: true specified should be allowed to be omitted, and that way we reuse that existing config schema property! 👍 I realized (after a LOT of debugging 🙈) that this cannot work, because we still need to be able to distinguish between optional keys vs optional values. There are plenty of examples where some piece of configuration (some key-value pair) may be required but have an optional value — in fact, those already exist!

   For example: editor.editor.*:image_upload.max_dimensions.width MUST be present in all Text Editor config entities, but it may be set to null to indicate there is no maximum image width.

   So we need a new key. This would be specific to type: mapping. I think requiredKey: false would make sense: the absence of this in the config schema would imply requiredKey: true👍

3. Do this for ALL configuration: ALL configuration that has a non-optional value that is missing should trigger a validation error.
4. BUT:
   1. In this issue, only fix invalid config_test.* configuration, to first get the infrastructure in place.
   2. Use the \Drupal\Core\Config\Schema\SchemaCheckTrait::$ignoredPropertyPaths infrastructure that #3364109: Configuration schema & required values: add test coverage for `nullable: true` validation support added to ensure we know which configuration in core is invalid, which also makes it easy to create follow-up issues per pattern, module or config entity type — just like we did for #3361534: KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate (see #15).
   3. … which also makes it possible to reduce disruption: #3361423: [meta] Make config schema checking something that can be ignored when testing contrib modules
5. In #18, the need for conditionally required keys was surfaced and explained in detail. Rather than finding all the places where this is applicable, this does it only for a single concrete case where it is clearly needed: editor.editor.*:image_upload.status. See #18 for details. To support this, a new ConditionallyRequiredKeys validation constraint was added, which allows specifying conditionality within a single type: mapping:
   • @bircher had concerns (#25) that it would be complex for config_split, config_filter etc. to determine conditionally required keys.
   • @phenaproxima raised similar concerns on the MR.
   • Thanks to @bircher in #30, I was able to implement in #32 his proposal: no more need for an additional validation constraint that must be explicitly associated whenever conditionally required keys exist, but instead using config schema's existing dynamic typing to achieve the very same!

   See #32 for details.

   The best part: this led to the pleasant surprise that we actually already have a bunch of significant conditional config structure differences specified in our schema, for example type: core_date_format_pattern.[%parent.locked] in HEAD resolves to either core_date_format_pattern.0 or core_date_format_pattern.1 already too — this uses that exact same mechanism. 👍

This has zero effect on running a Drupal site: nor on the rest of Drupal core, nor on contrib. Because config validation does not yet run in production, only on tests, since #3361534: KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate.

Remaining tasks

Review.

User interface changes

None.

API changes

None. The actual API changes would happen in #3361423: [meta] Make config schema checking something that can be ignored when testing contrib modules.

Additions:

1. (to reduce scope, moved to #3401883: Introduce Mapping::getValidKeys(), ::getRequiredKeys() etc.):
   1. Mapping::getValidKeys()
   2. Mapping::getRequiredKeys()
   3. Mapping::getOptionalKeys()
   4. Mapping::getDynamicallyValidKeys()
2. ValidKeys now also is able to generate error messages for all type: mapping data that is missing required keys.

Data model changes

None.

Release notes snippet

N/A

Problem/Motivation

In a site where there are several editors working, some menu links are disappearing, breaking the menu tree. It happens when a menu link is edited, referencing a node while the node is currently edited at the same time.

Steps to reproduce

• Have menu ui module installed.
• One user is editing a node with the 'Provide a menu link' option disabled.
• Another user is editing a menu link, setting the node created by the first user as the link, as a reference.
• The first user saves the page. As the 'Provide a menu link' option was disabled because there was no menu link related with the node, the menu link is removed, by the menu ui form submit

Plus, this video also shows how to reproduce the problem: https://www.drupal.org/files/issues/2023-11-06/drupal-core-3221319-menu-links-race-condition.mp4

Proposed resolution

Remaining tasks

User interface changes

New error message

API changes

NA

Data model changes

NA

Release notes snippet

NA

Problem/Motivation

ajax_page_state is a list of the 'minimal representative set' of libraries on page, which can still be a long list. We should compress it, this will allow it to be passed into GET requests per #956186: Allow AJAX to use GET requests.

The mechanism for this has already been added in #3303067: Compress aggregate URL query strings.

Steps to reproduce

Some hosting environments limit the length of URLs, see

#3380486: Extremely long Views AJAX query string triggers 403 in AWS
#3384852: Ajax Pager broken after upgrade 10.0.9 to 10.1.2

Proposed resolution

Remaining tasks

User interface changes

API changes

Due to a new middleware that uncompresses ajax_page_state as soon as a request is received, there is no API change for any code that expects it to be an array - it's still n array. Similarly, ajax_page_state is compressed only when it's about to be put into Drupal settings at the very last moment, so there's no API change for manipulating it.

WebTestCase::getDrupalSettings() and WebDriverTestCase::getSettings() both get a new $uncompress_ajax_page_state argument defaulting to TRUE and commented out per the deprecation policy. This means most cases for getting the parameter will also be unchanged, but if some really wants to get the raw compressed string they still scan.

Data model changes

Release notes snippet

Have a problem with an embedded form in a view that EVA adds to an entity. Here is the scenario:

• There is one view called drd_domain
• This view contains two displays: a page (page_1) and a EVA (entity_view_1)
• The $form['#action'] should go to two different URLs for each of the displays but it always goes to the page

I have found where this is going wrong: \Drupal\views\Form\ViewsForm::buildForm() in line 160

$form['#action'] = $view->hasUrl() ? $view->getUrl()->setOptions($options)->toString() : Url::fromRoute('<current>')->setOptions($options)->toString();

Even if Drupal renders the EVA display, it returns TRUE for hasUrl() and therefore takes getUrl() from the view and will use the URL from the page, for wathever reason. If EVA were on its own in a view, this line above would use fromRoure('') which would give us exactly what we're looking for.

I don't know how to resolve this but I hope that this analysis is helping you to find the best way out of that. I would hate to have two separate views as this would cause a real maintenance nightmare.

If you want to reproduce this, you could simply install DRD and go to a Core view, which would show exactly the described effect.

Problem/Motivation

When using PHP 8.1 the following warnings are displayed/logged.

Deprecated function: strnatcasecmp(): Passing null to parameter #2 ($string2) of type string is deprecated in Drupal\shortcut\Entity\Shortcut::sort() (line 186 of core/modules/shortcut/src/Entity/Shortcut.php).
Drupal\shortcut\Entity\Shortcut::sort(Object, Object)
uasort(Array, Array) (Line: 128)
Drupal\shortcut\Entity\ShortcutSet->getShortcuts() (Line: 208)
shortcut_renderable_links() (Line: 47)
Drupal\shortcut\ShortcutLazyBuilders->lazyLinks()
call_user_func_array(Array, Array) (Line: 101)

Steps to reproduce

Not 100% sure that causes this issue, it seems to be when getting a title returns null in certain cases.

Proposed resolution

Prevent passing in NULL by converting to string.

Problem/Motivation

Trying to explain the increase in random JS testing fails and we're wondering if DNS resolution is the cause again.

Apparently we've seen a massive increase in the DNS requests to drupal.org since switching to gitlabci. Maybe this is caused by Chrome doing DNS prefetching - see https://www.chromium.org/developers/design-documents/dns-prefetching/

We can disable this in chromedriver so let's see if that makes a difference.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Twig dump function in the exposed form

After updating my site from Drupal 10.0.9 to Drupal 10.1.0 and then to 10.1.1. Disappeared my views exposed filter. I have custom code in a hook form alter. Change theme, delete code, but no solution came.

Then I installed a new Drupal site, with the steps below. First with version 10.0.9.. no problem. Then with 10.1.0 and 10.1.1. A {{ dump() }} inspection of the view-exposed-form.html.twig yields no results and the exposed form disappears. This only if an exposed filter of type taxonomy term is created. With other filters, not of this type, everything functions normally.

Because this was done in a fresh installation, without any custom code, without any other module, nor themes, I suspect this is a bug. Unfortunately I can't find the solution myself.

Steps to reproduce

1. Create a vocabulary.
2. Create a custom content type
3. Create a view page, with filter criteria to the newly created content type. : Unformatted list, Content: teaser
4. Create an exposed filter to select the taxonomy terms via multi select. Possibly create other exposed filters that do not refer to a taxonomy term.
5. Exposed form in a block : yes.
6. Add the exposed form block to anny region on your page
7. Add a {{ dump(form) }} function to view-exposed-form.html.twig