I have a numeric field that holds pricing data. If the pricing data in the database is 0.00 or NULL and the field is set to round (I'm rounding to 2 decimal places) and the "Count the number 0 as empty" and "Hide if empty" boxes are checked, then the field is output as 0.00 (expected: hidden). The field is successfully hidden if rounding is disabled.

Probably unnecessary info:
- price column in MySQL is of type decimal(6,2)
- Views integration via Entity API (7.x-1.x-dev)

Steps to reproduce:

• Add a Number (Decimal) field to a content type
• Create a view of fields as an unformatted list with this content type and add the Number field
• In the field display settings, make sure Scale is set to 2
• In 'No results behaviour', tick 'Hide if empty' and 'Count the number 0 as empty'
• Create nodes with differing numeric values: e.g. NULL (unfilled), 0, 0.0, 0.01 (give the node a corresponding title so you can tell which is which)
• See that the field is displayed for nodes with 0.00
• Update the field display settings in the view to set Scale to 0
• See that the field no longer appears

Problem/Motivation

The /filter/tips page has a link to http://www.w3.org/TR/html/ but this page is redirected to https://html.spec.whatwg.org/, resulting in a 301 error.

Steps to reproduce

Run an SEO check on any site with comments enabled. The 301 error should appear.

Proposed resolution

Change the link to https://html.spec.whatwg.org/ to eliminate the 301 error.

Remaining tasks

Change the link to https://html.spec.whatwg.org/

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

While upgrade from Drupal 8.9.16 to Drupal 9.1.10 it run into the error
Error 1:

[error] Error: Call to a member function delete() on null in Drupal\Core\Config\ConfigImporter->checkOp() (line 934 of /var/www/boroo/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php) #0 /var/www/boroo/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(603): Drupal\Core\Config\ConfigImporter->checkOp('', 'create', 'block.block.chi...')
#1 /var/www/boroo/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(507): Drupal\Core\Config\ConfigImporter->processConfigurations(Array)
#2 /var/www/boroo/vendor/drush/drush/src/Drupal/Commands/config/ConfigImportCommands.php(333): Drupal\Core\Config\ConfigImporter->doSyncStep('processConfigur...', Array)
#3 /var/www/boroo/vendor/drush/drush/includes/drush.inc(206): Drush\Drupal\Commands\config\ConfigImportCommands->doImport(Object(Drupal\Core\Config\StorageComparer))
#4 /var/www/boroo/vendor/drush/drush/includes/drush.inc(197): drush_call_user_func_array(Array, Array)
#5 /var/www/boroo/vendor/drush/drush/src/Drupal/Commands/config/ConfigImportCommands.php(304): drush_op(Array, Object(Drupal\Core\Config\StorageComparer))
#6 [internal function]: Drush\Drupal\Commands\config\ConfigImportCommands->import(NULL, Array)
#7 /var/www/boroo/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
#8 /var/www/boroo/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#9 /var/www/boroo/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#10 /var/www/boroo/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(311): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#11 /var/www/boroo/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#12 /var/www/boroo/vendor/symfony/console/Application.php(1027): Symfony\Component\Console\Command\Command->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#13 /var/www/boroo/vendor/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#14 /var/www/boroo/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#15 /var/www/boroo/vendor/drush/drush/src/Runtime/Runtime.php(118): Symfony\Component\Console\Application->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/boroo/vendor/drush/drush/src/Runtime/Runtime.php(49): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 /var/www/boroo/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run(Array)
#18 /var/www/boroo/vendor/drush/drush/includes/preflight.inc(18): require('/var/www/boroo/...')
#19 phar:///usr/local/bin/drush/bin/drush.php(141): drush_main()
#20 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#21 {main}.

Error 2:

[error] Error: Class 'Drupal\Core\Config\PostConfigImportEvent' not found in Drupal\Core\Config\ConfigImporter->processPostImportHooks() (line 676 of /var/www/boroo/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php) #0 /var/www/boroo/docroot/core/lib/Drupal/Core/Config/ConfigImporter.php(507): Drupal\Core\Config\ConfigImporter->processPostImportHooks(Array)
#1 /var/www/boroo/vendor/drush/drush/src/Drupal/Commands/config/ConfigImportCommands.php(333): Drupal\Core\Config\ConfigImporter->doSyncStep('processPostImpo...', Array)
#2 /var/www/boroo/vendor/drush/drush/includes/drush.inc(206): Drush\Drupal\Commands\config\ConfigImportCommands->doImport(Object(Drupal\Core\Config\StorageComparer))
#3 /var/www/boroo/vendor/drush/drush/includes/drush.inc(197): drush_call_user_func_array(Array, Array)
#4 /var/www/boroo/vendor/drush/drush/src/Drupal/Commands/config/ConfigImportCommands.php(304): drush_op(Array, Object(Drupal\Core\Config\StorageComparer))
#5 [internal function]: Drush\Drupal\Commands\config\ConfigImportCommands->import(NULL, Array)
#6 /var/www/boroo/vendor/consolidation/annotated-command/src/CommandProcessor.php(257): call_user_func_array(Array, Array)
#7 /var/www/boroo/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#8 /var/www/boroo/vendor/consolidation/annotated-command/src/CommandProcessor.php(176): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#9 /var/www/boroo/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(311): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#10 /var/www/boroo/vendor/symfony/console/Command/Command.php(255): Consolidation\AnnotatedCommand\AnnotatedCommand->execute(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#11 /var/www/boroo/vendor/symfony/console/Application.php(1027): Symfony\Component\Console\Command\Command->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#12 /var/www/boroo/vendor/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand(Object(Consolidation\AnnotatedCommand\AnnotatedCommand), Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#13 /var/www/boroo/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#14 /var/www/boroo/vendor/drush/drush/src/Runtime/Runtime.php(118): Symfony\Component\Console\Application->run(Object(Drush\Symfony\DrushArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#15 /var/www/boroo/vendor/drush/drush/src/Runtime/Runtime.php(49): Drush\Runtime\Runtime->doRun(Array, Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/boroo/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run(Array)
#17 /var/www/boroo/vendor/drush/drush/includes/preflight.inc(18): require('/var/www/boroo/...')
#18 phar:///usr/local/bin/drush/bin/drush.php(141): drush_main()
#19 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#20 {main}.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I am working on a highly access-controlled project and while the requisite entity API access controls are in place, I would like to further restrict by default the entities shown on collections pages by filtering. This is in line with the recommendations at https://www.drupal.org/docs/core-modules-and-themes/core-modules/jsonapi... .

However, I don't want to require this be done on the client side, but rather alter the query programmatically if no filters are passed in the URL. This is easy enough to do with hook_query_TAG_alter(), except there's no tag to indicate the query is for the purposes of satisfying a json:api request.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

We implement the following core PHP classes and interfaces in a number of places in core:

• \JsonSerializable
• \SessionHandlerInterface
• \php_user_filter

In PHP 8.1 tentative return types were added to methods on these classes and interfaces, which triggers deprecations warning on existing code.

Code that is compatible with PHP 8.1 only can add the return types now - but for backward compatibility we can declare #[ReturnTypeWillChange] which silences the warnings and tells PHP we will add the return types later on. The attribute will be ignored in earlier versions.

Steps to reproduce

Proposed resolution

Add #[ReturnTypeWillChange] before all method implementations in classes that implement or extend core PHP code.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Guzzle 6 passes NULL as the $numeric_prefix parameter to http_build_query(). PHP 8.1 has tightened up parameter types and only allows strings here.

The Guzzle team will not fix this as Guzzle 6 is considered end of life, and the issue does not exist in Guzzle 7: https://github.com/guzzle/guzzle/pull/2918

Steps to reproduce

Proposed resolution

Guzzle does not use use function or prefix any function calls with \ so we can inject a shim into the GuzzleHttp namespace that intercepts the call and passes on the correct argument.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Please ignore this issue. It is only for testing.

Problem/Motivation

When adding new media through the Media Library, it's possible to add more than the allowed number of media items.

Steps to reproduce:
1) In the Media Library, if you can select two items, select two.
2) Now upload a third item.

Expected: You should not be able to select more than the allowed number, or should receive a warning if you do.
Actual: no warning appears, and if you then insert the media you get nothing is attached. It fails without warning.

Proposed resolution

1. When the number of selected items exceeds the maximum allowed after adding one or more items in the media library, display a warning.
2. If the user then persists on inserting the media items with an overage, do not allow it, but display an error message.

Video:
https://www.drupal.org/files/issues/2019-12-21/3082690-71-walkthrough_0.mov

Remaining tasks

• Discuss solution
• Write patch
• UX Review
• A11Y Review
• Code review
• Frontend framework manager review
• Commit

User interface changes

Added error / warning messages to the media library.

Video of #21: https://www.drupal.org/files/issues/2019-07-17/media-library-exceeds-lim...

The warning after adding and exceeding the limit:
https://www.drupal.org/files/issues/2019-07-17/media-library-add-warning...

The warning after clicking 'Save and select':
https://www.drupal.org/files/issues/2019-07-17/media-library-save-and-se...

The error after clicking 'Save and insert' or 'Insert selected':
https://www.drupal.org/files/issues/2019-07-17/media-library-save-and-in...

API changes

Data model changes

None

Release notes snippet

Problem/Motivation

The form element description tend to be very long and therefore is hard to read
Also the elements don't look nice from a design point of view when they're all using a different length

Proposed resolution

Limit width of form elements with a max-width set including form description

Before/After

e.g. of the current implementation:

Limit width example:

Problem/Motivation

It's not possible to assign a role to the admin account.

Steps to reproduce

• Use composer create-project drupal/recommended-project mydir to create a Drupal 9.1.8 instance that uses Dutch as language, the Standard profile, and a MySQL database
• Add a new role, for example Author
• Move it in the role order above the maintenance role (beheerder, in Dutch)
• Assign the new role to the admin account and save
• On /admin/people the role is shown assigned to the administrator; on /user/1/edit, the role isn't assigned
• After clearing the cache, the role is still not assigned in /user/1/edit, but is shown on /admin/people
• By default, the search block is rendered in the left column; editing the this block visibility to show it only to the Author and Administrator, the block is hidden for the admin account
• Create a new account and assign it the Author role
• Log in with this new account and verify the Search block is visible

I'm constructing a form presently and I have a problem when I use datetime and datelist form elements in a table. Example of code:

$form['part_a']['courses_table'] = [
      '#type' => 'table',
      '#header' => [
        $this
          ->t('Title'),
        $this
          ->t('Hours'),
        $this
          ->t('Date (month/year)'),
        $this
          ->t('Location'),
      ]
    ];

    for ($i = 0; $i < $nb_course; $i++) {
      $form['part_a']['courses_table'] [$i] = [
        'title' => [
          '#title' => t('Title'),
          '#title_display' => 'invisible',
          '#type' => 'textfield',
          '#required' => TRUE
        ],
        'hours' => [
          '#title' => t('Hours'),
          '#title_display' => 'invisible',
          '#type' => 'number',
          '#min' => 1,
          '#required' => TRUE
        ],
        'date' => [
          //        '#title' => t('Date of Admission'),
          '#title_display' => 'invisible',
          '#date_increment' => 1,
          '#date_part_order' => ['month', 'year'],
          '#date_year_range' => ($year - 1) . ":" . $year,
          '#type' => 'datelist',
          '#required' => TRUE
        ],
        'location' => [
          '#title' => t('Location'),
          '#title_display' => 'invisible',
          '#type' => 'textfield',
          '#required' => TRUE
        ]
      ];

    }

If I use this kind on architecture in my form, the datelist element is never validate and I have always the error "The date is invalid. ". If I use a datetime, I have a similar error of type "'The date date is invalid. Please enter a date in the format 2018-26-11."

When I'm looking in the core for these both elements, it seems the bug occur because these elements aren't converted as a DrupalDateTime object for the validation

If I use the standard form element date, it works correctly but you don't have the same possibilities than with elements datelist and datetime.

Of course, outside a table, these elements work properly, it's only happen when they are use in a table. I tried to add "#tree" => TRUE to my table thinking it could be a bug due the hierarchy but it didn't fix the problem and the bug happens if the table has 1 like more elements.

Problem/Motivation

Twig 3 is here
https://github.com/twigphp/Twig/releases/tag/v3.0.0

Proposed resolution

Update Drupal 9 to Twig 3.

Remaining tasks

Discuss. Patch. Commit.

User interface changes

None.

Hello all, it’s time for the weekly migration subsystem meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. See the parent issue for an idea of the typical agenda.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Core migration issues

• RTBC
• NR
• all open
• Statistics, Google spreadsheet

Next video meeting

2021-07-15 - The hope is that most or all of the maintainers will attend. We will try to focus on longer-term goals than in the weekly meeting.

Recording of the video meeting: https://youtu.be/7IjRQkzEBD4

Problem

The disclosure chevron doesn’t adapt to Windows' high-contrast mode very well. It works correctly in Legacy Edge and IE11. It doesn't work in Firefox or Chromium-based browsers.

Steps to reproduce

Enable High Contrast mode in Windows

After upgrading from Drupal 8.9 to Drupal 9.0 I get the two following error/warning messages when trying to create new content using some (not all) of my content types, among them the native “page”-type:

Error message:

The website encountered an unexpected error. Please try again later. Error: Call to a member function getAccountName() on null in Drupal\node\NodeForm->form() (line 155 of core/modules/node/src/NodeForm.php).

Warning message:

call_user_func() expects parameter 1 to be a valid callback, class 'Drupal\node\Entity\Node' does not have a method 'getCurrentUserId' in Drupal\Core\Field\FieldConfigBase->getDefaultValue() (line 397 of core/lib/Drupal/Core/Field/FieldConfigBase.php).

Does anyone know what causes this?

Root cause

• This issue may affect sites that were originally built with an earlier Drupal 8 version than 8.6.x and which were upgraded to Drupal 9.
• The reason is that Node::getCurrentUserId method was deprecated in 8.6.x and was removed in 9.0.0. The replacing method in Drupal 9 is Node::getDefaultEntityOwner
• Configuration entities that are still having a reference to the removed method will trigger this bug.
• Note that other entity types than Nodes (e.g. Media) can also be affected.

Workaround

The following workaround steps are for Node entities but should be quite well applicable for other Entity types as well.

1. You want to identify those Node content types that are affected by this issue.

2. You can either a) do this by trial and error i.e. try to create new nodes for each content type on your site and see which content types are affected OR b) you can export your configuration and search for 'getCurrentUserId' to get a list of configuration files that are affected. The following steps use approach b) using Drush command line tool on Linux.

3. Export all configuration from command line using drush config:export

4. Navigate to your config/sync directory.

5. Identify the affected configuration files using

grep -R "getCurrentUserId" *

. The files matching this search will be like core.base_field_override.node.CONTENT_TYPE.uid.yml, for example core.base_field_override.node.page.uid.yml. As mentioned above, other entity types than nodes might also be affected.

6. For each affected configuration file, first take a backup of the configuration file. Then, use your favorite text editor and replace default_value_callback: 'Drupal\node\Entity\Node::getCurrentUserId' with default_value_callback: 'Drupal\node\Entity\Node::getDefaultEntityOwner' in each affected configuration file. If your site is affected by some other Entity type than Node, you will need to modify this find / replace according to your entity type.

7. Once you have edited all affected configuration you can double check with grep -R "getCurrentUserId" * that you did not miss any affected configuration file.

8. Once you have fixed all affected configuration files, you will need to import these configurations from your config/sync directory back to your database. This can be done with drush config:import

9. After you have imported the configurations, you will need to rebuild your caches. This can be done with drush cache:rebuild

10. Test and verify that you are now able to create new nodes of the affected content types.

Hello all, it’s time for the weekly migration subsystem meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. See the parent issue for an idea of the typical agenda.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Core migration issues

• RTBC
• NR
• all open
• Statistics, Google spreadsheet

Next video meeting

2021-10-14 - The hope is that most or all of the maintainers will attend. We will try to focus on longer-term goals than in the weekly meeting.

Agenda items

Add items here

• #3220155: Add extra orderBy to d7_file source plugin to avoid random results

Adding the required state to radios, adds the required marker to all available options.

$form['field_options']['#states']['required'] = array(
  ':input[name="field_required[und]"]' => array('value' => 1)
);

Problem/Motivation

If the source database has multiple files with the same timestamp value, then the returned result is unpredictable and random most of the time when using d7_file migrate source plugin.

We already have this for d6 plugin:

$this->select('files', 'f')
      ->fields('f')
      ->condition('f.filepath', '/tmp%', 'NOT LIKE')
      ->orderBy('f.timestamp')
      // If two or more files have the same timestamp, they'll end up in a
      // non-deterministic order. Ordering by fid (or any other unique field)
      // will prevent this.
      ->orderBy('f.fid');

But for d7 we don't have it yet:

$this->select('file_managed', 'f')
      ->fields('f')
      ->condition('f.uri', 'temporary://%', 'NOT LIKE')
      ->orderBy('f.timestamp');

Proposed resolution

Add orderBy('f.fid') to d7_file source plugin query.

Remaining tasks

Submit a patch/merge request, review, commit.

Problem/Motivation

A site builder is able to allow the user to enter a description for the file field upload. However, in some circumstances, the description may be mandatory. Right now there's no way for a site builder to make the file field upload description mandatory.

Proposed resolution

Add a new setting for file items to require the file description.

Remaining tasks

N/A

User interface changes

A new file field setting that allows to enforce the description.

Site builder perspective

End-user perspective

API changes

None.

Data model changes

New, description_field_required, boolean key in the mapping of code>field.field_settings.file schema.

Release notes snippet

As a site builder, on a file field settings form, after checking Enable Description field, check the Require the Description field setting in order to make the file upload required.

Original report

If I add a file field and check Description, I don't get the option to make Description a required field. This results in the public seeing often-unfriendly file names instead of a meaningful description.

Steps: As admin:
1. Edit basic page
2. Add new file field

Actual result: Description is not prechecked
Expected result: Optionally, Description is pre-checked as the public-friendliest solution

3. Check Description

Actual result: No option to require description appears
Expected result: Check box to require description appears. Optionally, it is pre-checked as the public-friendliest solution.

As editor:
1. Add new basic page
2. Attach file
3. Don't fill in Description field
4. Save and publish

Actual result: No error
Expected result: Error