Problem/Motivation

See #29338: Hide Promoted/Sticky fields by default in Form display, I suggested that umami should hide those base fields for node types that do not use them in views. If there are no views relying on sticky or promoted fields for recipes for example then users shouldn't be able to see that and pick a value, that's just confusing and exactly what has been discussed in that referenced issues for 20 years.

This is a fairly minor issue and just there to serve as an example for real distributions that you can and should do this.

It should also not have promoted enabled by default then.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

The problem

The sticky/promoted fields in core date from 2004, and are only used by the default front page + forum module. Some sites use them as a shortcut when they don't need a full entityqueue/flag solution.

As such they're a (small) usability issue since they're quite redundant and often don't do anything depending on how a site is configured. They're also outdated in the sense that this kind of 'feature-y' field would normally be added by entityqueue/flag or a configurable field.

Proposed solution

Make sticky/promoted fields hidden by default in Form Display.

Problem/Motivation

The user saw a page shown on the front page, and got alarmed thinking it was accidentally created as the site's homepage.
The reason of why this is happening is due that they are not many differences between front page and nodes pages.

As you can see in the image above there are only two difference:

1. The menu color are different. In the node page is blue and in the front page is gray.
2. Buttons from the views, "Read more about Article 1""Add new comment"

There is already a project that is trying to solve the same issue Empty Front Page

Proposed resolution

• Remove the view Frontpage (Content) from the front page and add a block that said welcome and some information about Drupal.
• Another possible solution would be to style the view so the user can tell the different between a front page or nodes pages.

Remaining tasks

• Discuss any other potential solutions
• Patch

User interface changes

?

API changes

?

Data model changes

?

Problem/Motivation

#3490066: Add shorter date format (without time) and start using in announcements feed showed a need for a shorter date format, without time. Several users agreed that it would be nice to offer this:

I agree a date format in core for date only (without time) would be good.

Steps to reproduce

Open Administration > Configuration > Region and language > Date and time formats (/admin/config/regional/date-time) and see that all human readable date formats include time.

Proposed resolution

It would be nice to offer human readable date formats, without time:

Remaining tasks

Add the three date formats above.

User interface changes

New installs now offer shorter human readable date formats, without time.

API changes

Data model changes

Translations

Problem/Motivation

Follow-up for #2101427: Follow-up: Browser validation error with Chrome on hidden required fields, even on forms that don't allow client-side validation

We added some #states cruft to the installer to support an old version of Chrome. That version of chrome is long gone by now, so we can remove it again.

Proposed resolution

Remove #states form attribute from install database config form options.

Remaining tasks

User interface changes

API changes

Data model changes

The _filter_html_image_secure_process() filter in FilterHtmlImageSecure checks for image tags in content. Is short, it does this:

<?php
$html_dom = Html::load($text);
$images = $html_dom->getElementsByTagName('img');
foreach ($images as $image) {
  // Perform checks and replacements.
}
$text = Html::serialize($html_dom);
return $text;
?>

The Html::serialize is always performed, even if the content does not have images. This leads to double serializing when the 'Correct faulty and chopped off HTML' filter is enabled as well, which currently results in HTML like this: text. Note the duplicate xml:lang attributes. The double attribute tag bug is tackled in another issue (#1333730: [Meta] PHP DOM (libxml2) misinterprets HTML5), but while debugging #2346989: [PP-1] 'Restrict images to this site' leads to incorrect HTML with language attribute, I found this issue.

Hello,

I face off issues about PHP:

Warning : Invalid argument supplied for foreach() dans Drupal\Core\Field\FormatterPluginManager->getOptions() (/var/www/drupal-8/core/lib/Drupal/Core/Field/FormatterPluginManager.php ligne 176)
#0 /var/www/drupal-8/core/includes/bootstrap.inc(600): _drupal_error_handler_real(2, 'Invalid argumen...', '/var/www/drupal...', 176, Array)
#1 /var/www/drupal-8/core/lib/Drupal/Core/Field/FormatterPluginManager.php(176): _drupal_error_handler(2, 'Invalid argumen...', '/var/www/drupal...', 176, Array)

and Js:
Hook de thème token_tree non trouvé with Seven as admin theme

and this cause:
Filefield sources autocomplete doesn't work anymore
Megamenu doesn't show sub items depending on which page you are

I don't have enough element to know what I need to look for.

Thanks for help

Problem/Motivation

No clear use case for inclusion in core.

Steps to reproduce

Proposed resolution

The module is deprecated and moved to contrib.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

One of the biggest challenges with the current Telephone module is that it's just a glorified textfield. It has no option to normalize the telephone number - either for the purpose of validation or formatting.

In Commerce applications, we see more and more requirements from payment gateways to collect and pass the telephone number to the payment gateway during Checkout. Given we have payment gateways from all over the world, supporting customers in virtually every possible market, we also must be able to process and send the phone number in a normalized way.

Fortunately, 2 standards are leading here:
- E.164 - the international public telecommunication numbering plan
- national format - popular if only supporting customers in one market

Google came up with the library that is now an unofficial standard, that allows transitions between formats as well as data validation. In PHP it was adapted as-is and released as a standalone composer library.

Drupal Contribs such as telephone_validation and telephone_formatter modules utilize said library to perform certain operations on the user input. But the problem is - we don't have a common storage where telephone could be stored in a normalized format, similar to how numbers or dates are already handled by core. With the steady growth in the usage of said modules and surpass of 10k installation I feel it's time to have better support directly in Core.

Proposed resolution

- Create a new field type plugin in the telephone module - TelephoneE164Item (telephone_e164). Allow users to choose that field type over current, simplified TelephoneItem
- Store the phone number user input AND E164 version in the database
- Create a validation constraint that will only accept the value IF user input can be represented in E164 format
- Create a formatter(s?) to show the value directly from user input, in E164 format, international or national format.

Remaining tasks

- Find out what should be the schema for the new field
- Document when the old field type should be used over the new field type (alarm numbers, vanity phone numbers, etc.

User interface changes

n/a

Introduced terminology

n/a

API changes

n/a

Data model changes

n/a

Release notes snippet

Problem/Motivation

Following discussion with the Drupal Security Team, it was agreed that this could be handled in a public "security improvements" issue.

At present Drupal's file API allows filenames to be created which could be dangerous if they're not handled safely. This is not a directly exploitable vulnerability, but improvements could be made that would reduce the likelihood of filenames being used as part of a chained attack.

Command injection is a specific concern here.

https://owasp.org/www-community/attacks/Command_Injection

https://portswigger.net/web-security/os-command-injection

Steps to reproduce

In some cases, browsers will escape/encode certain characters in a normal file upload, but it may be possible to avoid that escaping using a tool like Burp Suite, or perhaps via web services (rest / jsonapi).

An example of a dangerous filename which I believe a normal file field will currently accept is:

foo";echo `whoami`; #.txt

A fairly recent improvement to filename handling (which we could build upon) is described in this Change Record:

https://www.drupal.org/node/2972665

Proposed resolution

One or more of:

• Always remove/replace specific characters that may be used for command injection e.g. " ; # |` and if possible '&.
• Disallow spaces by default in filenames (makes it quite a lot harder to achieve meaningful command injection).
• Review defaults for filename transliteration to make command injection as hard as possible.

Remaining tasks

• Implement improvements.
• Add tests (e.g. in \Drupal\Tests\file\Functional\SaveUploadTest ).
• Ensure that improvements also apply to web services and other uses of the API if possible.

User interface changes

Default filename handling may change; most noticeable changes for users may include removal/substitution of commonly used characters such as spaces, apostrophes and ampersands.

Introduced terminology

n/a?

API changes

Changes to filename handling may represent an API change.

Data model changes

n/a?

Release notes snippet

tbc

Problem/Motivation

User accounts that don't have an email address can be created by administrators. _user_mail_notify() assumes that when it's passed a user account that it has an address. When that happens errors occur. It happens for any user action that sends an email. It can happen via the admin UI or Drush. This issue has resulted in at least three different issues that I could find, but there may be more:

• #3312582: When a user account doesn't have an email, new user notification email attempt shouldn't be made
• #3355151: Exception thrown when unblocking a user via drush
• #3481894: Error when trying to reset password of the account without email address

These issues have proposed patches, but they all try to stop the email from being sent at the source, e.g. the User entity or the password reset form. None of them try to prevent _user_mail_notify() from sending an email to a NULL address, which means the inherent bug will persist. This issue will take that approach.

Afterward, some of the related issues may simply be closed. Some may be repurposed as follow-ups. For instance, the password reset form may want to print an extra message if an email can't be sent.

Steps to reproduce

1. Log into the site as an administrator.
2. Create a new user. The user should not have an email address.
3. Block the user.

Expected result

The user should be blocked with no attempt to send an email.

Actual result

[error]  TypeError: Drupal\Core\Mail\Plugin\Mail\PhpMail::doMail(): Argument #1 ($to) must be of type string, null given, called in /var/www/html/core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php on line 123 in Drupal\Core\Mail\Plugin\Mail\PhpMail->doMail() (line 168 of /var/www/html/core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php) #0 /var/www/html/core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php(123): Drupal\Core\Mail\Plugin\Mail\PhpMail->doMail()
#1 /var/www/html/core/lib/Drupal/Core/Mail/MailManager.php(308): Drupal\Core\Mail\Plugin\Mail\PhpMail->mail()
#2 /var/www/html/core/lib/Drupal/Core/Mail/MailManager.php(181): Drupal\Core\Mail\MailManager->doMail()
#3 /var/www/html/core/lib/Drupal/Core/Render/Renderer.php(600): Drupal\Core\Mail\MailManager->Drupal\Core\Mail\{closure}()
#4 /var/www/html/core/lib/Drupal/Core/Mail/MailManager.php(180): Drupal\Core\Render\Renderer->executeInRenderContext()
#5 /var/www/html/core/modules/user/user.module(659): Drupal\Core\Mail\MailManager->mail()
#6 /var/www/html/core/modules/user/src/Entity/User.php(162): _user_mail_notify()
#7 /var/www/html/core/lib/Drupal/Core/Entity/EntityStorageBase.php(564): Drupal\user\Entity\User->postSave()
#8 /var/www/html/core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php(796): Drupal\Core\Entity\EntityStorageBase->doPostSave()
#9 /var/www/html/core/lib/Drupal/Core/Entity/EntityStorageBase.php(490): Drupal\Core\Entity\ContentEntityStorageBase->doPostSave()
#10 /var/www/html/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(806): Drupal\Core\Entity\EntityStorageBase->save()
#11 /var/www/html/core/lib/Drupal/Core/Entity/EntityBase.php(370): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save()
#12 /var/www/html/vendor/drush/drush/src/Commands/core/UserCommands.php(154): Drupal\Core\Entity\EntityBase->save()
#13 [internal function]: Drush\Commands\core\UserCommands->unblock()
#14 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(276): call_user_func_array()
#15 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(212): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback()
#16 /var/www/html/vendor/consolidation/annotated-command/src/CommandProcessor.php(175): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter()
#17 /var/www/html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(387): Consolidation\AnnotatedCommand\CommandProcessor->process()
#18 /var/www/html/vendor/symfony/console/Command/Command.php(279): Consolidation\AnnotatedCommand\AnnotatedCommand->execute()
#19 /var/www/html/vendor/symfony/console/Application.php(1094): Symfony\Component\Console\Command\Command->run()
#20 /var/www/html/vendor/symfony/console/Application.php(342): Symfony\Component\Console\Application->doRunCommand()
#21 /var/www/html/vendor/symfony/console/Application.php(193): Symfony\Component\Console\Application->doRun()
#22 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(110): Symfony\Component\Console\Application->run()
#23 /var/www/html/vendor/drush/drush/src/Runtime/Runtime.php(40): Drush\Runtime\Runtime->doRun()
#24 /var/www/html/vendor/drush/drush/drush.php(140): Drush\Runtime\Runtime->run()
#25 /var/www/html/vendor/bin/drush.php(119): include('...')
#26 {main}.

Proposed resolution

Add a check to _user_mail_notify() to verify that the account has an email address. Add a message if it doesn't have one.

Remaining tasks

• Agree on the message to be displayed
• Review
• Commit
• Evaluate related issues to see if some can be closed

User interface changes

A message will be added if _user_mail_notify() is passed an account that has no address.

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Drupal Core has a function to store user input in browser's local storage. This violates data protection rules. Since some modules are using function (see #2409107), this issue is intended to provide a quick solution to make Drupal CMS GDPR compliant on the day of release.

Steps to reproduce

• Enable "Who can register accounts?"> "Visitors" or "Visitors, but administrator approval is required"
• Log out
• Go to /user/register
• Register new user
• Go again go to /user/register
• The form is prefilled.
• In Local Storage the user name and mail address are stored without consent (Drupal.visitor.name and Drupal.visitor.mail)

Proposed resolution

• Short term: No longer used in core forms
• Long-term: Deprecation notice and remove the entire non-privacy-compliant function.

Remaining tasks

• Write Patch
• Write Test
• Write Change Record
• Review

User interface changes

Do not prefill form for anonymous user at user register, comment and message form.

Introduced terminology

None.

API changes

None.

Data model changes

None.

Release notes snippet

User registration and comment form do not store any personal data in the browser in accordance with data protection guidelines rules. The form attribute data-user-info-from-browser will be deprecated in a later step.

I often want to disable the Default front page, and have to find a module, or create an empty view to achieve this. What if we just offer the option of disabling the Default front page by adding a check-box under Basic site settings?

Problem/Motivation

In #2691675: Replace deprecated entityManager() in ControllerBase descendents, we noticed that NodePreviewController::title() is not called once in our tests, despite actually being defined as the title_callback.

It's not called because the parent controller sets #title directly, and we never try to get the title for that route from elsewhere (e.g. breadcrumb). And it woud most likely not work anyway as it relies on being able to dynamically load the node through the query argument and then state.

Proposed resolution

Deprecate the untested code, replace it with a static _title: "Node preview" or so title as it doesn't really matter anyway. Maybe even remove completely, not sure what our policy on that one is.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Follow up for #1498674: Refactor node properties to multilingual

Problem/Motivation

Simplify code

In 1498674 was the @todo

   // @todo Introduce node_mass_delete() or make node_mass_update() more flexible.

Proposed resolution

Add service to delete nodes by an author
Potentially NodeRepository::deleteByAuthor

Remaining Tasks

• use git blame to identify the issue that added this @todo and link to it, and link it back to here. this code was introduced in 2009 by #8: Let users cancel their accounts (yes node 8!!) https://git.drupalcode.org/project/drupal/-/commit/9a32ca468a320bec9769e...
• Do it

User interface changes

No.

API changes

TBC

When Drupal is installed, node_install() creates a record in the node_access table with nid = 0. Zero is not a valid value for nid and violates the foreign key constraint declared in node_schema(). The default should be stored some other way or a default node with nid = 0 should be added to the node table.

Problem/Motivation

When creating a new content type, the default value for the "Promoted to front page" checkbox should be FALSE.

Proposed resolution

Set the default value of promote to FALSE in Node's base field definition
This value propagates to the Node type on save via base field override configuration

Existing node types will need an upgrade path to create base_field_override config to maintain the previous default setting.

Remaining tasks

Write upgrade path for existing node types
Review
Commit

User interface changes

Promoted to frontpage checkbox on Node Type form defaults to unchecked.

Release notes snippet

The Promoted to frontpage checkbox on he Node Type form defaults to unchecked.

Problem/Motivation

When working on https://git.drupalcode.org/project/drupal/-/merge_requests/855 I couldn't get NodeAccessGrantsCacheContextTest::testCacheContext to pass.

The reason is, we call $this->moduleHandler()->hasImplementations('node_grants')

hasImplementations calls getHookListeners which reads from the invokeMap cache if it's set. However, there's no way to force reset this cache in a kernel test. When debugging the above test, I noticed node_access_test was still in the invokeMap for node_grants even after it was uninstalled.

Steps to reproduce

See above test

Proposed resolution

$this->invokeMap = []; in resetImplementations

Remaining tasks

Agree
Review
Commit

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

N/A

Whenever I create a new account It asks for email, user name and etc but It takes the same credentials in the respective fields that I have used for previous user creation and I think drupal doesn't allow to use same email for 2 or more different people.
I think it's storing on local but there is no use of it.

Beta phase evaluation

Problem/Motivation

Field Layout module was in part deprecated by the later addition of Layout Builder module and it never matured out of its experimental stage. It is still in core as an experimental module but it passed its deadline of removal with Drupal 8.5.0-alpha1 quite some time ago. It was not yet removed, but it needs a solution.

Proposed resolution

Deprecate and move to contrib

Remaining tasks

• #2844302: Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase
• Add Field Layout to Deprecated and obsolete extensions

More children needed, identify them.

User interface changes

The manage display UI is replaced with Layout Builder.

API changes

TBD. As an alpha experimental module, no API stability was guaranteed.

Data model changes

TBD.