Problem/Motivation

Some file extensions in field.field.media.document.field_media_document.yml are missing from ExtensionMimeTypeGuesser, which can cause some issues as reported in #3466462: Fix handling of unknown file extensions in FileMediaFormatterBase.

The following file extensions are missing completely: fodt fods fodp fodg numbers pages

The .key extension is present, but is mapped to application/pgp-keys, to which it was historically mapped (along with .asc). Its official media type according to IANA is now application/vnd.apple.keynote, so perhaps it's time to update the mapping.

Steps to reproduce

1. Manually configure the *.fodt, *.fods, *.fodp, *.fodg, *.numbers or *.pages file extension as an allowed upload file type, or have them configured automatically via the document media type recipe, the standard profile or the Umami demo profile.
2. Upload one of these file types to a file field or as a media document.
3. The resulting file entity will have the fallback "application/octet-stream" MIME type (which is visible in the database, and also sent as an HTTP header for private downloads) rather than an appropriate specific MIME type.

Proposed resolution

• Re-map .key from application/pgp-keys to application/vnd.apple.keynote
• Map .numbers application/vnd.apple.numbers
• Map .pages to application/vnd.apple.pages
• Map .fodg to application/vnd.oasis.opendocument.graphics-flat-xml
• Map .fodp to application/vnd.oasis.opendocument.presentation-flat-xml
• Map .fods to application/vnd.oasis.opendocument.spreadsheet-flat-xml
• Map .fodt to application/vnd.oasis.opendocument.text-flat-xml
• While we're here, fix alphabetical order of application/json

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

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

When enabled "Output this field as a custom link" checkbox , add counter field token in link path , then counter token broken in href on FE.

Steps to reproduce

• Add/edit the view
• Add field: View result counter
• Add field: Custom text, Add value in text field
• After scroll down, you 'll find opt: rewrite results > click on it
• Then you 'll find checkbox: "Output this field as a custom link"& enable it
• You 'll see opt link path , add here counter field token for eg: /test/{{ counter }}
• Click on apply btn & save the view

Issue is replicable Drupal 10 version as well
Note: I didn't find any issue w.r.t to counter that fails this mentioned scenario, if anyone finds then can close ir as duplicate by attaching the link of existing issue.

Expected behaviour

Instead of this broken counter field token "/test/%7B%7B%20counter%20%7D%7D" in href tag counter field's token value should render(eg: /test/1)

Proposed resolution

When checked "Output this field as a custom link" checkbox & add the counter field token in to link path, then counter token should work instead of broken in href

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/dialog.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties and remove IE specific style definitions.

User interface changes

None. There should be no visual differences.

Problem/Motivation

The "Status" field on the user profile form allows users to be blocked. This field is displayed even in my own profile which doesn't really make sense. This allows users to block themselves from the site, which could lead into frustrating situations, like we can see on this forum post: https://www.drupal.org/forum/support/post-installation/2014-04-29/blocke....

Proposed resolution

Hide "Status" field from the user form when rendered for the current user.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Background information

• How to write a release note snippet
• Writing release notes for Drupal core releases

Release notes

• 11.1
  • 11.1.0 release notes draft gdoc
  • Issues tagged '11.1.0 release notes'
• 10.4:
  • 10.4.0 release notes draft gdoc
  • Issues tagged '10.4.0 release notes'

Instructions

1. Read over the release notes draft. The section at the top is the initial outline for the release notes. The sections at the bottom need to be completed.
    

2. Make sure that all issues tagged '11.1.0 release notes' and '10.4.0 release notes' are included in the respective drafts.
    

3. If an issue is tagged for the 11.1.0 notes but not for the 10.4.0 notes, check whether it was backported and correct the tagging.
    

4. If an issue is tagged for the 10.4.0 release notes, ensure something was actually backported. Also ensure that the 10.4 version of the release note is accurate.
    

5. Review the format of the release notes, and leave comments on the Google doc where something seems incorrect:
   • Ensure that every release note describes a disruptive change. Additions without any disruptive changes belong in the release highlights post, not the release notes.
   • Ensure that every release note follows the release note snippet best practices.
   • Ensure that every release note (save those about a dependency update) includes a link to a change record.
   • Ensure that release notes are formatted correctly in bulleted lists, and that each list item has a blank newline between the tag and the list item text. For example:
     

     <li>
     
     A disruptive change is described here. For more information, review <a href="">the change record about what-and-such</a>.
     
     </li>
     

   • Follow the rough organization suggested by committers. If you think something belongs in a different section, leave a comment.

6. Use the Google Docs "suggestion" feature to suggest corrections, readability improvements, etc.
    

7. Comment on this issue to receive credit for working on the release notes.

Problem/Motivation

Draft mode returns wrong revision of includes. I get default revision of second level paragraph instead of latest revision.

Technical problem:
When trying to access the working revision entity data with resourceVersion=rel:working-copy and using includes, the current revision of the referenced entities is being returned by the method "resolveIncludeTree" in IncludeResolver class. This method should return the data as per the revision being passed in the API query or the working revision.

Steps to reproduce

Install Content moderation;
Add support version negotiation for any entity type: "https://git.drupalcode.org/project/drupal/-/merge_requests/1365.patch"
Create paragraph type A;
Create paragraph type B;
Add paragraph reference field to paragraph A;
Create node with paragraph A (+ paragraph B inside A)
Publish node;
Create draft with changed B;
Check node json data with resourceVersion=rel:working-copy. Returned wrong revision of includes.

Proposed resolution

web/core/modules/jsonapi/src/IncludeResolver.php
loads included entity by id
$targeted_entities = $entity_storage->loadMultiple(array_unique($ids));

Change it so that we're getting the entity from the field item instead. That way the field item is responsible for providing the accurate revision of the entity.

Problem/Motivation

> cspell -------------------------------------- ◯ ^8.16.0 ------ ◉ ^8.16.1 ------

Note; This bump, although small, has been given its own issue, because it actually requires changes outside the package.json and/or yarn.lock-file.

@longwave confirmed it's okay (in this specific case) to bundle all JavaScript dependencies that don't have the above changes in a single issue.
This is very welcome, because it means a lot can be done in one issue and basically every extra issue about JavaScript dependencies ends up in reroll-limbo if any of the other JavaScript dependencies gets committed.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

? Pick the packages you want to upgrade.          Current          Range            Latest

   @floating-ui/dom ---------------------------- ◯ ^1.6.8 ------- ◉ ^1.6.12 ------
   chokidar ------------------------------------ ◯ ^3.6.0 -------                  ◉ ^4.0.1 -------
   cspell -------------------------------------- ◉ ^8.16.0 ------ ◯ ^8.16.1 ------
   dotenv -------------------------------------- ◯ ^16.4.5 ------ ◉ ^16.4.7 ------
   eslint-plugin-import ------------------------ ◯ ^2.29.1 ------ ◉ ^2.31.0 ------
   eslint-plugin-no-jquery --------------------- ◯ ^3.0.2 ------- ◉ ^3.1.0 -------
   eslint-plugin-yml --------------------------- ◯ ^1.14.0 ------ ◉ ^1.16.0 ------
   eslint -------------------------------------- ◯ ^8.57.0 ------ ◉ ^8.57.1 ------ ◯ ^9.16.0 ------
   jquery-ui ----------------------------------- ◯ ^1.14.0 ------ ◉ ^1.14.1 ------
   jquery -------------------------------------- ◉ ^4.0.0-beta.2                   ◯ ^3.7.1 -------
   jsdom --------------------------------------- ◯ ^24.1.1 ------ ◯ ^24.1.3 ------ ◉ ^25.0.1 ------
   nightwatch ---------------------------------- ◯ ^3.7.0 ------- ◉ ^3.9.0 -------
   postcss-preset-env -------------------------- ◉ ^9.6.0 -------                  ◯ ^10.1.1 ------
   postcss ------------------------------------- ◉ ^8.4.40 ------ ◯ ^8.4.49 ------
   prettier ------------------------------------ ◯ ^3.3.3 ------- ◉ ^3.4.2 -------
   sortablejs ---------------------------------- ◯ ^1.15.2 ------ ◉ ^1.15.6 ------
   stylelint ----------------------------------- ◯ ^16.10.0 ----- ◉ ^16.11.0 -----
   terser -------------------------------------- ◯ ^5.31.3 ------ ◉ ^5.37.0 ------
   tua-body-scroll-lock ------------------------ ◯ ^1.5.0 ------- ◉ ^1.5.3 -------
 > webpack ------------------------------------- ◯ ^5.96.1 ------ ◉ ^5.97.1 ------

@longwave confirmed it's okay (in this specific case) to bundle all JavaScript dependencies that don't have the above changes in a single issue.
This is very welcome, because it means a lot can be done in one issue and basically every extra issue about JavaScript dependencies ends up in reroll-limbo if any of the other JavaScript dependencies gets committed.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Comment for \Drupal\Core\Datetime\DateHelper::dayOfWeekName() says it returns translated string and it really make sense to return translation here. But in fact now it returns untranslated English name of the day. This change was brought by the
#3281557: DateTime::__construct(): Passing null to parameter #1 ($datetime) of type string is deprecated . I didn't find the related discussion, suppose it's changed by mistake.

The change to use an untranslated string was added in #3281557-54: DateTime::__construct(): Passing null to parameter #1 ($datetime) of type string is deprecated. No explanation is given and it is not discussed in later comments.

Proposed resolution

Return the original behavior - return translation from the method.

Remaining tasks

User interface changes

No.

API changes

No.

Data model changes

Just return state to previous.

Problem/Motivation

When importing config that has changes to core.extension (i.e enabling or uninstalling modules) memory usage grows linearly based on the number of modules being installed or uninstalled.

On our XL site:

• When making 5 module changes (2 uninstalls, 3 installs) memory usage jumps to over 1GB.
• The memory usage seems to be roughly the same if the combination is different (i.e 2 uninstalls and 1 install uses roughly the same memory as 1 uninstall and 2 installs).
• 3 module changes peaks at ~800MB memory
• 2 module changes peaks at ~700MB
• 1 module change peaks at ~600MB

This was profiled using blackfire run php -d memory_limit=-1 ./bin/drush cim -y

Here's a screenshot of the Blackfire memory graph. Everything seems to stem from RouteBuilder::rebuild.

Things of note:

1. 118,000 calls to unserialize
2. 97,000 calls to serialize
3. 45,000 SQL queries executed

Interestingly, when profiling a drush updb -y that does the following, memory usage peaked at 250MB:

  $moduleInstaller = \Drupal::service('module_installer');
  $moduleInstaller->install([
    'module1',
    'module2',
    'module3',
  ], FALSE);
  $moduleInstaller->uninstall([
    'module4',
    'module5',
  ], FALSE);

Steps to reproduce

This is probably only applicable to large sites with a lot of routes/config/modules?

There does seem to be a somewhat linear memory usage just by doing the same thing with a standard profile and uninstalling some modules, although obviously MUCH lower memory (less than 200MB)

Proposed resolution

The main thing here is - why does memory usage keep increasing? RouteBuilder::rebuild is called once for every module change. Is there a memory leak in here somewhere?

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Variables are missing comments.

Steps to reproduce

Proposed resolution

Add comments for non test files.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Whenever I need to save a date+time programmatically, I write

$now = (new \Drupal\Core\Datetime\DrupalDateTime('now', new \DateTimeZone('UTC')))->format('Y-m-d\TH:i:s');
# or
$now = \Drupal::service('date.formatter')->format(time(), 'custom', 'Y-m-d\TH:i:s', 'UTC');

Even with the help of VS Code and/or a use statement, it's quite a lot to remember and rather complicated.

Imagine if I could just ask for drupal_get_now() and get all the goodness of (new \Drupal\Core\Datetime\DrupalDateTime('now', new \DateTimeZone('UTC')))->format('Y-m-d\TH:i:s') in one fell swoop!

Setting the date field on a node would be as easy as
$order_node->set('field_paid_date', drupal_get_now());

I bet

drupal_get_now('date'); // just the date
drupal_get_now('timestamp'); // timestamp

would be useful to lots of people as well.

Steps to reproduce

Try saving a date programmatically.

My guess is that 90% of the dates my sites save programmatically are 'now'.

Proposed resolution

Place the function in the datetime.module.

Remaining tasks

Merge request 10200 needs review and tests.

Problem/Motivation

When an editor adds a media item via the modal and encounters an error, for example skipping the required Alternative Text field, the error message displays on the page, behind the modal.

This causes usability issues since the error message is obscured by the modal, leaving the editor confused as to why the form does not save.

Steps to reproduce

1. Add a media item via a modal, eg: edit an existing Image media item.
2. Save the form without including alternative text.

Watch this video as an example.

Proposed resolution

Display error messages within the modal.

Remaining tasks

1. Get core maintainer approval of the resolution
2. Implement the resolution
3. Test
4. Deploy

User interface changes

Error messages from a modal form would display within the modal, rather than on the page the modal appears from.

API changes

None

Data model changes

None

Release notes snippet

TBD

Problem/Motivation

The Block module uses vertical tabs to present visibility settings on the block form.

For example, on /admin/structure/block/manage/olivero_site_branding

This has been broken since #3467860: Ensure consistent ordering when calculating library asset order changed when the vertical-tabs library was loaded. CKEditor 5's library definitions were updated accordingly, but not Block.

Steps to reproduce

Visit the block form and scroll down to the Visibility section, note that each vertical tab has the string "Not Required" appended.

Expected:

Actual:

Proposed resolution

Following the CR instructions, add the library as an explicit dependency.

Remaining tasks

Write tests

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Hello and thanks for all the efforts,

Problem/Motivation

After updating to 10.4.0-rc1, I've started receiving the error message below:

Error: Class "Doctrine\Deprecations\Deprecation" not found in Doctrine\Common\Lexer\Token->offsetGet() (line 104 of /var/www/html/vendor/doctrine/lexer/src/Token.php)

Steps to reproduce

My PHP version is 8.3.14
Output of the composer depends doctrine/deprecations command is below:

doctrine/collections    2.2.2      requires doctrine/deprecations (^1)     
doctrine/lexer          2.1.1      requires doctrine/deprecations (^1.0)   
drupal/core-recommended 10.4.0-rc1 requires doctrine/deprecations (~1.1.3)

I've also tried deleting "vendor" directory and re-run the composer install command, but it didn't work.

What should I do?

Best,
Orkut

Steps to reproduce

Proposed resolution

See comment #19 by longwave

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Follow-up from #3490355: Add procedural hook short circuit per module or file. Let's mark all the modules.

Would be great to do a before/after comparison of drush install to see if/how much memory and potentially time we save.

Steps to reproduce

N/A

Proposed resolution

Bugfixes

• Add fix to HookCollectorPass, can't change the $dir variable
• Update DI tests to not expect services key

Add container parameter for modules fully converted
Add Attribute for ones using procedural only
Move procedural hooks to top of files
Convert unconverted hooks

• block_themes_installed
• media_library_form_views_form_media_library_page_alter

If there is not already a services file create it

Do not add the attribute to jsonapi.module because there are no functions.
If a module has no .inc or .module files do nothing. E.G. page_cache
If a module only has procedural functions that need to be scanned do nothing E.G. package_manager

Do we need to ignore module.post_update.php

Remaining tasks

Follow ups:

• field partially ignored
• locale
• update
• node_mass_update
• test modules (likely not worth doing)

#3491448: Update tests calling theme suggestions through moduleHandler.

User interface changes

N/A

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Hello,

I am having an issue with sub form in a paragraph(paragraph referenced in another paragraph). I updated my drupal core to 10.3.10 and since then, I've been seeing that the fields in my sub form stick together and I don't know why. It seems like there is no padding bottom on the field.

How can I resolve this?

Problem/Motivation

1. Created a feature exporting user field settings with the contributed D8 feature module
2. Various changes to the user fields
3. Incorporating my colleagues various changes into my repo
4. Running drush features-import produced this error:

[derp@der[ public]$ drush fia -y
Reverting Base User...
PHP Fatal error:  Call to a member function getConfigDependencyName() on null in /var/www/vhosts/derp.dev/releases/herp/public/core/lib/Drupal/Core/Entity/EntityDisplayBase.php on line 274
Drush command terminated abnormally due to an unrecoverable error

Proposed resolution

Wrap the add Dependency method call on line 274 with a quick !empty check

Remaining tasks

User interface changes

API changes

Data model changes

Original report by generalconsensus

Problem/Motivation

While #3303127: Determine which core config entity methods should be config actions will be straightforward for some of the more basic configuration entities, for others it will be relatively complex. Not surprisingly, views is on the complex end of the spectrum.

Our best indicator for concrete use cases is looking to core config that's been overridden in an install profile, since that provides a concrete use case. So an initial exercise to begin to scope config actions requirements for looking at how core's module-provided views such as views.view.taxonomy_term.ymlhave been overridden in the demo_umami profile.

Sample diffs run from the root of a Drupal core repo:

diff -u core/modules/node/config/optional/views.view.frontpage.yml core/profiles/demo_umami/config/install/views.view.frontpage.yml
diff -u core/modules/taxonomy/config/optional/views.view.taxonomy_term.yml core/profiles/demo_umami/config/install/views.view.taxonomy_term.yml

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes