Problem/Motivation

There is currently no way to remove an empty destination property from a Row once it has been added. This limits the ability of migration event subscribers to alter the outcome of a migration update.

Steps to reproduce

Create a migration that will null out the contents of a field for a particular entity. Use the PRE_ROW_SAVE event to attempt to undo that, and see that the Row class does not provide a public method to accomplish this.

Proposed resolution

Add public methods to the Row class.

Remaining tasks

None

User interface changes

None

Introduced terminology

None

API changes

New methods added to \Drupal\migrate\Row.

Data model changes

None

Release notes snippet

None

Problem/Motivation

/**
 * Tests access to user autocompletion and verify the correct results.
 */
function testUserAutocomplete() {
  $this->drupalLogin($this->account);
  $this->drupalGet('user/autocomplete', array('query' => array('q' => $this->account->getUsername())));
  $this->assertRaw($this->account->getUsername());
  $this->assertNoText('registry initialized', 'The registry was not initialized');
}

The path user/autocomplete does not exist in Drupal 8 for a long time. The test still passes because user/autocomplete is found in drupalSettings.path.currentQuery.

Steps to reproduce

Proposed resolution

Search for all remaining usages of the route or string and decide what to do with each one.

Remaining tasks

Patch
Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When trying to load a library with an icon pack it seems like the regular expression for the library property schema definition is not correct and does not allow hyphens which are valid in THEME.libraries.yml.

An IconPackConfigErrorException exception is being thrown:

Drupal\Core\Theme\Icon\Exception\IconPackConfigErrorException: my_theme:foo Error in definition `foo`:[library] Does not match the regex pattern ^\w+/[A-Za-z]+\w*$ in Drupal\Core\Theme\Icon\Plugin\IconPackManager->validateDefinition() (line 430 of core/lib/Drupal/Core/Theme/Icon/Plugin/IconPackManager.php).

Steps to reproduce

Create a new THEME.icons.yml file in your theme and try to use - in the library property:

foo:
  label: Foo
  extractor: path
  config:
    sources:
      - images/svgs/*.svg
  library: 'my_theme/an-icon-library'

Proposed resolution

The ">regular expression for validating the library should be changed from ^\w+/[A-Za-z]+\w*$ to ^[a-zA-Z0-9_]+\/[a-zA-Z0-9_-]+$ (following the RegEx from metadata.schema.json which ensures we can use hyphens in the library name after the slash.

Problem/Motivation

\Drupal\Tests\system\Functional\Datetime\DrupalDateTimeTest::testTimezoneFormat doesn't make any HTTP requests.

Proposed resolution

Move \Drupal\Tests\system\Functional\Datetime\DrupalDateTimeTest::testTimezoneFormat to an existing date kernel test or create a new one.
While you're there, remove the unnecessary ::setup method
Consider moving testSystemTimezone too, which as per #2 could be tested via routing a Request via the Kernel.

Remaining tasks

See above

User interface changes

None

API changes

None

Problem/Motivation

PHP has a language misfeature where a class can be marked as final. There's no benefit as far as the language is considered, it is solely useful as a social construct to indicate this class is not covered by any BC policies and could change at any time and so it should not be extended. However, as #17 says

Looking back at amount of wasted time of community on issues like "make this place extensible" and sometimes unexpected future of new code I strongly against using final

Moreover making open source it looks a nonsense to spend time on closing/protecting it

Proposed resolution

The same social construct can be reached by using @final instead. It is used by Guzzle, Symfony, Twig, behat, composer, phpstan etc. It is recognized by PhpStorm and possibly other IDEs which is no surprise since it was invented for phpDocumentor back in the PHP4 days. Drupal could also use it in all places which are exempted from BC already: plugin implementations, paramconverters, access checkers, event subscribers, hook implementation classes etc.

Further, @final is just a comment and as such it can be applied to anything -- indeed, it is used in upstream on methods already which fixes another long standing problem of the same make: private.

(Originally the issue was only about hook implementations but nothing here is specific to those.)

API Definition
current text
TBA

proposed text
TBA

Remaining tasks

Confirm where documentation changes are needed.
Add proposed text
Confirm change to relevant core policy docs.

Problem/Motivation

Call to undefined function Drupal\system\Plugin\ImageToolkit\imageavif() in Drupal\system\Plugin\ImageToolkit\GDToolkit::checkAvifSupport() (line 565 of web/core/modules/system/src/Plugin/ImageToolkit/GDToolkit.php)

Using Drupal 11.2.0-beta1 with only a few contrib modules that are not using the ImageToolkit.

Steps to reproduce

Edit or create a user:

/admin/people/create
/user/edit
or
/user/1/edit

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

This is a followup for the tests suggested in #1443158-2: file_field_presave assumes that a file object has been loaded which were never written as part of that issue.

Problem/Motivation

This was discovered in #3441503: Add validation constraints to system.theme and is postponed on that issue.

Currently, the 'system' module must be installed before the 'stark' theme can be installed. 'Stark' is set as the default theme in the `system.theme.yml` file of the 'system' module, unless an installation profile specifies an alternative default theme. This configuration results in a circular dependency issue that needs to be addressed in this particular issue.

Steps to reproduce

Proposed resolution

1. Change
   

   default: stark
   

   in core/modules/system/config/install/system.theme.yml to

   default: null
   

2. When the first theme is installed, assign its name to system.theme:default.

Remaining tasks

Postponed on #3441503: Add validation constraints to system.theme

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

GitHub has recently started to make use of SECURITY.md files if present in the repository root. Many open source projects have since stared to have a SECURITY.md file explaining how to report security vulnerabilities properly.

Just a moments ago, we got WordPress to commit their SECURITY.md file, and I would like to propose that we use a SECURITY.md file as well.

This file can explain the procedures we have security.drupal.org, how to report a Drupal core vulnerability, how it works for core, security coverage, and a lot of other information that will surely make it easier for security researchers and end users alike.

Thank you.

Steps to reproduce

N/A

Proposed resolution

Add SECURITY.md that points to the drupal policy

Remaining tasks

Decide if it belongs in root or core. I think it should be as easy to find as possible.
Decide on wording of the link.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

This summer I'm likely going to be working on #229568: Pathauto in Core and I'm seeing several options for how I can propose merging Pathauto (or other potential modules) into core.

1. Lieutenant model: This is my preferred option. Pathauto would continue to "live" in contrib and would be "bundled" in the core repository from the 8.x-1.x branch. Is this possible it all (maybe using git sub-modules)? If so what changes would we need to make to have this possible? It was brought up at Dries' core conversation in Denver but it hasn't really been discussed since then.
2. Normal merge: When we merge modules into core there can be two different ways it can be done.
   
   1. Enhancement: Merge into an existing core module, for example, merge Pathauto with path.module. How does this work if someone wants to turn off automatic aliasing (or whatever feature the merged module adds)?
   2. Add as-is: This would copy/paste all of Pathauto's files into core/modules/pathauto and if approved enable Pathauto as part of the standard install.

I would first just like to really discuss if the Lieutenant model is possible, feasible, and something that Dries/catch would agree to doing because that is highly my preferred option. I just don't want to waste my time attempting to merge in Pathauto if it's not going to be a plan that I don't agree with.

Regardless of how it is merged in, we would continue to probably use a core fork sandbox and provide patches based on diffs of that sandbox compared to 8.x.

Problem/Motivation

FormBuilder::handleInputElement() contains a long condition that checks if #access is a boolean or a valid access result object: https://git.drupalcode.org/project/drupal/-/blob/63740f3de3c3459fa14229b...
Moving this condition to a separate method would make it easier to maintain, document and reuse.

Steps to reproduce

Proposed resolution

Create a new private method that returns a boolean.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Currently the oEmbed from Podigee does not provide a valid thumbnail height and width value. Therefor this must be patched currently in the media Drupal core module.

The issue was discovered in Drupal 10.4, but still persists in Drupal 11.x. The attached patch does work in Drupal 10.x and Drupal 11.x.

Proposed resolution

In \Drupal\media\OEmbed\Resource::__construct() the variables $thumbnail_width and $thumbnail_height can be passed into the constructor as NULL. But this values are being used. They are not checked before they are used. Solution: check the values via an if-case before using them.

See attached patch.

Steps that trigger the issue / test case

Install the and configure the Media Entity Podigee Drupal module. Do not apply the patch from the project description. You'll get an error on the media entity creation, since Podigee does not provide a thumbnail width and thumbnail height. But Drupal core tries to use these values, without checking. Example url for a Podigee media url: https://einfach-machen-nachhaltiger-konsum.podigee.io/5-einfach-energie-...

By the way, it's pretty obvious that we can potentially stumble into a unhandled exception, because the code is using unchecked values (the thumbnail width and thumbnail height).

Problem/Motivation

Different Drupal forms throw an ajax.$form.ajaxSubmit error on submit.

This has affected users at image upload, Block editing within Layout Builder sections, and ajax submissions for webforms. It is blocking development of various site items.

Steps to reproduce

Adding any elements to a form also gives the same error.

Steps:

1. Install & enable the webform module.
2. Add a new test form.
3. Click the "+ Add element" button.
4. Pick any element type, and fill in the form to create a new element.
5. Click the "Save" button.

Proposed resolution

Fix the bug with ajax so that Drupal users can add / modify webforms, successfully upload images etc.

Remaining tasks

Test the proposed patch.
Merge it if good.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

NA

Problem/Motivation

• The current mail system dates from many years ago and only supports plain text email and the PHP transport.
• There are contrib modules that extend this, but they are significantly hampered by the current interfaces which were designed only for plain text. We end up code duplication in each module sending HTML mail as they attempt to fill the missing function in their own way.
• Sending emails in the modern world is a complex task. The Drupal community are currently maintaining this code, which is inefficient. There is little ongoing development so the code is more outdated and lower quality.

Advantages of Symfony Mailer include HTML mails, file attachments, embedded images, 3rd-party delivery integrations, load-balancing/failover, signing/encryption, async sending and more. Other 3rd-party libraries add capability for CSS inlining and HTML to text conversion.

Proposed resolution

Stage 1: Create a @Mail plug-in based on Symfony mailer.

Add the symfony/mailer component as a composer dependency to Drupal core. Additionally make all supported Symfony mailer transports accessible via a simple mail plugin which can act as a drop-in replacement for the existing php mail plugin.

• #3165762: Add symfony/mailer into core

Stage 2: Create a new mail system based on Symfony mailer.

Similar in concept to Drupal Symfony Mailer. module, simplified and without any of the "overriding" code (which is for 'upgrading' emails sent by Core and other modules to be full modern HTML).

• #3379794: Add symfony mailer transports to Dependency Injection Container (mail delivery layer)
• #3380041: Create new mailer service based on symfony which creates a new API with direct access to the power of Symfony Mailer, plus integration into Drupal mechanisms, including: theme/template/render, multi-language, CSS libraries, configuration, plug-ins, hooks, and logging.
• #3380269: Create a plug-in system to build emails with Symfony Mailer
• #3380273: Create a system for configurable emails in Symfony Mailer
• #3380470: Migration strategy for moving to Symfony Mailer
• #3380472: Create a BC mapper for MailManager to convert to Symfony Mailer
• #3380476: Change core modules to use Symfony Mailer

Stage 3: Support new mail system in contrib.

Work with contrib to ensure adoption

• Migrate implementations of hook_mail() to use new Mailer API
• Migrate implementations of hook_mail_alter() to new events similar to MessageEvent.

Stage 4: remove the old mail system

• Deprecate then remove MailManager and @Mail plug-in system.
• Deprecate then remove use of the old mail system in core modules.
• Deprecate then remove the old API hook_mail() and hook_mail_alter().

The last one could be done one Drupal major version after the others as it provides a big increase to BC with a small amount of code.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

#### Original Issue Summary ####

What does Symfony Mailer provide that is better than the current mail system

Swiftmailer simplifies means integrating email communications within Drupal. The current mail system only supports plain text email and one transport method.

Swiftmailer provides plain text and HTML content types and multiple transport methods. It has a pluggable system that allows it to be extended, like Twig.

Currently we manage our own plugin system for mail that provides a default PHP `mail()` integration. Contributed modules must then provide integration with SMTP, sendmail, or others. This also means integrations for Sendgrid and Mandrill must require the SMTP module or write their own mail plugin.

What new features would Swiftmailer enable that we currently don't have?

Swiftmailer would immediately allow Drupal to send email over SMTP, Sendmail, PHP, or any other possible transport method. More can be read here: http://swiftmailer.org/docs/sending.html.

This also means users can immediately integrate with services like SendGrid and Mandrill out of the box with Drupal.

* SendGrid: https://sendgrid.com/docs/Integrate/Code_Examples/v2_Mail/php.html
* Mandrill: https://mandrill.zendesk.com/hc/en-us/articles/205582157-How-to-Send-wit...

One need, especially in the e-Commerce realm, is HTML enabled emails for rich customer experiences. Allowing Drupal to send HTML based emails out of the box will improve the experience built on top of Drupal for customers interacting with it.

Why is Swiftmailer the best library for that? Are there alternatives?

Swiftmailer is an open source library that is part of SensioLabs. Drupal currently incorporates Twig and many Symfony components, all of which are part of SensioLabs. This makes Swiftmailer highly qualified and further brings together the Drupal communities and PHP community at large collaborating with SensioLab libraries.

There is PHPMailer (https://github.com/PHPMailer/PHPMailer), however it is not pluggable like Swiftmailer, and may be harder to customize than Swiftmailer.

What are the drawbacks of integrating Swiftmailer?

We have to handle deprecation of Drupal's messy mail system (Mail plugins, hook_mail.) We would probably have to deprecate the SMTP module and Mailsystem module.

I can't come up with any drawbacks.

Next steps

• Use this issue as the plan/meta for integrating Swiftmailer
• Get the library in core
• Have core's php_mail use Swift_Transport_MailTransport instead of mail() directly
• Use a library like html2text/html2text to deprecate methods in \Drupal\Core\Mail\MailFormatHelper
• If an email specifies its content type as text/html respect that and allow it to send
• Find a way to expose settings like the Swiftmailer module for configuring transport options

Original issue summary

Might be a good first step in de-WTF-ing our mail system.

Problem/Motivation

In the "Manage display" tab on a node you can set a format for field of type "Number (decimal). When you choose "Default" there are some settings for thousand marker and decimal marker, but these are not language specific. I would like them to be translatable or at least have an option like "Default for display language" and have them set automatically according to the locale of each language.

In some countries, 1,000 means one (1), whereas in other countries, the comma is used as a thousand separator, so it means one thousand (1000).

We can translate Label, Prefix, and Suffix for a field, but wouldn't it be great to also be able to set the Thousand marker and Decimal marker by language?

Steps to reproduce

Proposed resolution

1. Localization on Regional settings page

   Add Localization options for each installed language on the Regional settings page (/admin/config/regional/settings), inside the Locale fieldset. The user can set custom separators for each installed language (da, en, fr, etc.).

   Detaching language from localization givers more flexibility to the site owner. He may want to use a different set of number separators than what we would expect for his region.

   Consider adding those settings to the user profile page as well, so a user is able to override the global localization settings.

2. Using Localization for each installed language in field displays

   Add a new option under the "Thousand marker" and "Decimal marker" settings from the "Manage display" page (/admin/structure/types/manage/article/display).

   It could be an option the user can select, where either a global character is used, or a language specific. The current select options could be updated to this:

   Thousand marker

   • - None -
   • Decimal point
   • Comma
   • Space
   • Thin space
   • Default for display language <<< Add this option

   Decimal marker

   • Decimal point
   • Comma
   • Default for display language <<< Add this option

Remaining tasks

For the number formats https://www.drupal.org/project/advanced_number_format might be a good starting point if we want to start in contrib, and eventually get it into Drupal core.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

This is a followup on suggestions made in #2972776: [policy, no patch] Better scoping for bug fix test coverage Comment #100

Proposed resolution

Testing core gate

current text

N/A

proposed text

Add an upgrade path test

When is this needed?

When a change makes data stored prior to the change incompatible with updated code.

Details

These are the types of changes that require an update test.

• Configuration schema changes
• Database schema changes

Resources

Writing Automated Update Tests

Remaining tasks

Review

Problem/Motivation

I'm not sure if this is an issue with entity_reference or field...

We recently uninstalled a module that contained an custom entity. There were nodes that had entity_reference fields. We removed the reference fields but I'm still getting an error on the field_cron run

Drupal\Core\Field\FieldException: Field 'field_vt_recipients' on entity type 'monument' references a target entity type 'medal' which does not exist. in Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem::schema() (line 172 of /code/web/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php).

I've checked my config files and there's no medal reference or field_vt_recipients left. is there another place I can look to clear this error?

We're currently on v 10.4.6

This issue will provide a high-level overview and table of contents of policy and infrastructural issues related to core development following the release of 8.0.0, including:

• When and how 8.1.x and subsequent branches are opened for develoment and prepared for release.
• The workflow for backporting changes between minor versions and from Drupal 8 to Drupal 7.
• The process for adding new features to 8.1.x and beyond (policies and implementation details)
• Etc.

Most discussion should not happen in this issue; instead, discuss in each child issue as appropriate. Add this issue as the parent issue for any relevant proposal or policy.

References

• Drupal core release cycle: major, minor, and patch releases
• Allowed changes during the Drupal 8 release cycle
• Drupal 8's APIs defined
• Backport policy
• Always Be Shippable (Dries' blog post) and Dries'DrupalCon Barcelona keynote
• Infrastructure blockers to 8.0.0, etc.: #2559711: [meta] Drupal.org (websites/infra) blockers to Drupal 8.0.0, 8.1.0, etc.

Original semver policy discussion

• #2135189: Proposal to manage the Drupal core release cycle

Patch releases (e.g. 8.0.1)

• #2576141: Release branches for core patch releases/release candidates

Minor versions (e.g. 8.1.x): Schedule, allowed changes, workflow

• #2455081: [policy, no patch] 8.1.x release schedule
• #2116841: [policy] Decide what the Drupal Public API should be and how to manage it
• #2550249: [meta] Document @internal APIs both explicitly in phpdoc and implicitly in d.o documentation
• #2623118: [policy, no patch] Update patch backporting workflow to be compatible with semantic versioning
• #2631820: [policy, then infra] Bulk update core issues for relevant minor versions

Backports, Drupal 7

• #2598662: Decide when Drupal 7 (and Drupal 8 and later) should enter the LTS and security-support-only phase
• #2598382: [policy] Adopt a 6-month feature release schedule for Drupal 7 (similar to Drupal 8) and use pseudo-semantic versioning
• #2597872: Allow features to be added during the beta phase, especially if they are backportable to the previous version
• #2462101: [policy, no patch] Update backport policy to account for 8.x minor versions and 7.x divergence

Drupal 9.x

• #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1
• #2607260: [meta] Core deprecation message introduction, contrib testing etc.
• #2608496: [policy, no patch] Drupal 9 release timing and Drupal 7/8 EOL

Problem/Motivation

Add a button in a form and the ajax callback works fine.
Move the button into a table row and ajax is not triggered

This is detailed further in this blog post: https://www.webomelette.com/ajax-elements-drupal-form-tables

Steps to reproduce

Create a button within a table row and add an ajax callback
No ajax is triggered and the button submits the page fully

Proposed resolution

Add ajax support for within tables

Remaining tasks

Merge request

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

Ajax is now supported within table rows.

Updated #65

Problem/Motivation

• Install content_moderation
• Apply the "Editorial" workflow to articles.
• Create an article node in the published workflow state.
• Goto /admin/content
• Use the bulk action "Unpublish content" on the article node.
• You will see this validation error:
  

Proposed resolution

• Remove the publish/unpublish action
• Provide action plugins for every state
• Dynamically create/update/delete action instances when workflow settings are changed.
• Update moderation_content admin view with the state actions.

Remaining tasks

Dynamically create/update/delete action instances when:

• create/update/delete operation happens on a workflow entity by implementing hook workflow (insert|update|delete).
• changes to the workflow entity happen during config import.
• changes to the workflow entity are done hook_update_N.

Update moderation_content admin view with the state actions.
Add functional test for both cases.

User interface changes

moderation_content admin view will have state change actions.

API changes

No API change only addition.
Adds new moderation state change action and deriver.

Data model changes

None.