Problem/Motivation

The SymfonyMailer class that was added in #3165762: Add symfony/mailer into core does not properly handle multiple comma-separated email addresses in the $message['to'] variable that is produced by Drupal. It attempts to send the entire message['to'] string into the Symfony mailer to() method, which expects a single address.

This results in an exception like the following:

Symfony\Component\Mime\Exception\RfcComplianceException: Email "test1@example.com, test2.example.com" does not comply with addr-spec of RFC 2822. in Symfony\Component\Mime\Address-\>__construct() (line 54 of /opt/drupal/vendor/symfony/mime/Address.php).

The addTo() method should be used to add additional addresses, or we can use to(...$toAddresses) with an array.

Reference: https://symfony.com/doc/current/mailer.html#email-addresses

Drupal core's MailManagerInterface::mail expects a string $to parameter, so sending to multiple addresses requires formatting them as a comma-separated list (and that is the recommendation).

Reference: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Mail%21Ma...

Steps to reproduce

1. Enable the Symfony mailer per the instructions in this change record: https://www.drupal.org/node/3369935
2. Trigger an email to be sent to multiple comma-separated addresses.

Proposed resolution

The SymfonyMailer class should parse $message['to'] into an array of addresses, and then use to(...$toAddresses) to pass them to Symfony mailer.

Remaining tasks

TBD

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

TBD.

Problem/Motivation

Deprecate the migrate process plugins used for migrating legacy Drupal sites.
There are 78 Migrate Drupal process plugins, 25 are in the migrate module. That leaves 53 to check to see if any are useful outside of a legacy migration.

Steps to reproduce

Proposed resolution

Deprecate in 11.3.0 for removal in 12.0.0

• TBA

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

username has a character limit of 60. If we create a user with name of 58 or 59 characters and try to translate a content, translation will not get saved. However on creating or editing a content in original language, it gets saved.

In authoring information tab (in node add, edit), 'Authored by' has maxlength 1024. Only in translation form, Authored by inside translation tab has maxlength 60. In the same translation form, Authored by field inside 'Authoring information' tab has maxlength 1024 and this causes issue.

The ContentTranslationHandler adds an entity_autocomplete field with a maxlength of 60 characters to the node edit form. The intent is probably to match the value in use on the UserInterface::USERNAME_MAX_LENGTH. However the autocomplete selection adds the (nid) to the selected username. If the value is greater than the limit it prevents submit the node edit form.

Steps to reproduce

Set a entity type as translatable. Create a user with a very long username (ex: 59 characters).
Create an entity with this user and save it.
Create a translation and try to save it.

Proposed resolution

Remove the maxlength attribute on the field.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

When we try to render display mode it always adds by default "title". So in case that there is by default "page title" block enabled you will see your page title twice and no possible to hide it (just disable block currently).

1.Create any Article node.
2. Visit the page - you can see title taken from "page title" block - normal behavior:

3. Now try to force to render any display mode like "teaser" with php (mymodule.module):

<?php

use Drupal\Core\Entity\EntityInterface;

/**
* Implements hook_entity_view_mode_alter().
*/
function mymodule_entity_view_mode_alter(string &$view_mode, EntityInterface $entity): void {
$view_mode = 'teaser';
}

4. Enable custom module and visit Article page again:

This bug was tested with ECA module first and it was proved here it is a core bug instead.

Problem/Motivation

Drupal\views\Plugin\views\sort\Date::query() has a switch() statement that could be rewritten as a match().

match() is easier to read, and has less potential for bugs because of the lack of break; statements. This is particularly relevant in this case, as the switch() mixes breaks and returns.

This is postponed on #3246454: Add weekly granularity to views date sort which is also making changes here.

Steps to reproduce

Proposed resolution

Replace switch() with something like:

$formula = match (...) {
  // seconds and default case produce NULL
}

if ($formula) {
    $this->query->addOrderBy(NULL, $formula, $this->options['order'], $this->tableAlias . '_' . $this->field . '_' . $this->options['granularity']);
}
else {
    $this->query->addOrderBy($this->tableAlias, $this->realField, $this->options['order']);
}

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

[CKEditor] Update image URL failed after saving

Steps to reproduce

1、Create a node

2、Add a CKEditor paragraph with text format without HTML filter enabled.

3、Click "Insert image" button and input URL

4、Save as Published

5、Edit the page and Select the image

6、Click "Insert image" button and Update URL

7、Save the page

8、Check the image

Image not changed

Proposed resolution

Modify the call of ReplaceImageSourceCommand in image.js and add an update to the htmlImgAttributes attribute

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Im trying to deny certain combination of user roles while creating or editing a user.

For this purpose I created a Constraint that should check whether the entered combination of roles is allowed. After implementing this, I experienced that the ConstraintValidator is executed, but the violation is not honoured by the underlying routines.

Steps to reproduce

To verify that my Contraint implemantation is correct, I added the same Constraint to the name and mail field in the same form. On this fields the Constraint works as expected. Im not sure whether I missed something, but my implementation seems to be correct as it's working on the other fields.

---- htdocs/modules/my_module/src/Plugin/Validation/Constraint/UserRolesConstraint.php ----
<?php

namespace Drupal\my_module\Plugin\Validation\Constraint;

use Symfony\Component\Validator\Constraint;

/**
 * Class UserRolesConstraint
 *
 * @Constraint(
 *   id = "UserRoles",
 *   label = @Translation("User roles restrictions",context = "Validation")
 * )
 *
 */
class UserRolesConstraint extends Constraint{
  public $ClientMustHaveOnlyOneGroup = 'Invalid roles selection.';
}

---- htdocs/modules/my_module/src/Plugin/Validation/Constraint/UserRolesConstraintValidator.php ----
<?php

namespace Drupal\my_module\Plugin\Validation\Constraint;

use Symfony\Component\Validator\Constraint;
use Symfony\Component\Validator\ConstraintValidator;

/**
 * Class UserGroupConstraintValidator
 *
 * @package Drupal\my_module\Plugin\Validation\Constraint
 */
class UserRolesConstraintValidator extends ConstraintValidator {

    /**
   * @inheritdoc
   */
  public function validate($value, Constraint $constraint) {
    $this->context->addViolation( $constraint->ClientMustHaveOnlyOneGroup);
  }
}

---- htdocs/modules/my_module/my_module.module ----
/**
 * Implements hook_entity_base_field_info_alter().
 */
function my_module_entity_base_field_info_alter(&$fields, EntityTypeInterface $entityType) {
  if ($entityType->id() == 'user') {
    $fields['roles']->addConstraint('UserRoles');
    $fields['name']->addConstraint('UserRoles');
    $fields['mail']->addConstraint('UserRoles');
  }
}

Attached is a screen shot of the result, I would have expected the the 'Roles' were marked as error as well.

Proposed resolution

Trigger Constraint violations for Roles on a user's account form

Remaining tasks

1. Write a merge request
2. Review
3. Commit

User interface changes

Errors are now shown when there are constraint violations that apply to the assigned roles for a user.

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

None

Stable blockers + should haves

Stable blockers

#3331078: Add php-tuf/composer-stager to core dependencies — for experimental Automatic Updates & Project Browser modules
#3525345: Move some Package Manager validation into the pre-require and status check event listeners
#3511972: Allow Composer and rsync location to be configured via the UI
#3408901: [policy, no patch] Decide if and when automatic updates should rely only on packagist data to determine installability of modules
#3358504: [PP-1] Require PHP-TUF's Composer integration plugin
#3352210: Security review of secure signing components for package manager
Governance: #3474816: Governance for projects on Github
#3474292: Package Manager should disallow cweagans/composer-patches by default

To be categorized as beta/stable blockers or post stable clean-up:

#3463662: When it is installed, Package Manager should try to detect the paths of Composer and rsync

Usability

1. #3321972: Make readiness check failure messages clear, consistent, and actionable - Needs summary update to actually define the problem and see if it is really a blocker
2. #3346644: If an error occurs during an attended process, delete the stage on behalf of the user

Not yet categorized

1. #3336867: Identify & vet commonly used composer plugins in the Drupal ecosystem
2. #3338651: Drupal core's coding standards forbid translated exceptions, but does that anyway — f.e. FileValidationException
3. #3345649: Update every ComposerValidator-dependent validator to have explicit test coverage that that dependency works
4. #3342790: Validate PHP version to be used by the Composer process calls
5. #3354011: Support scanning Composer Stager library for translatable strings
6. #3335918: [Policy, no patch] Projects depending on composer plugins will have to update the additional_trusted_composer_plugins setting in package_manager.settings

Core stable blockers for Package Manager

• #3358504: [PP-1] Require PHP-TUF's Composer integration plugin
• #3477553: Manually test TUF-enabled Composer projects

Policy Questions

1. #3408901: [policy, no patch] Decide if and when automatic updates should rely only on packagist data to determine installability of modules

Core Beta Experimental blockers for Package Manager

• #3474876: Rename classes that reference a "stage" to be clearer and use the term "sandbox" instead
• #3474292: Package Manager should disallow cweagans/composer-patches by default

Core Alpha Experimental blockers for Package Manager

These issues block #3346707: Add Alpha level Experimental Package Manager module.

#3483481: Hide and restrict package_manager (and update_manager) behind a dev/prod toggle so that they can be alpha stability in tagged releases

Dependencies

#3483411: Increase composer-stager constraint to the current stable release
1. ⚠️ core issue⚠️#3331078: Add php-tuf/composer-stager to core dependencies — for experimental Automatic Updates & Project Browser modules
2. ⚠️ core issue⚠️#3370269: [policy] Add php-tuf/php-tuf to core governance — for experimental Automatic Updates & Project Browser modules
3. ⚠️ infrastructure issue⚠️#3343490: Deploy rugged for TUF signing to production
4. ⚠️ infrastructure issue⚠️#3352216: Securely sign Drupal core packages, even though they are hosted on GitHub/packagist directly (or alternative solution for drupal/core to be TUF protected)

Security ^(gate)

1. ⚠️ core issue⚠️#3352210: Security review of secure signing components for package manager
2. #3358504: [PP-1] Require PHP-TUF's Composer integration plugin

Policy Questions

1. ⚠️ core issue⚠️#3349368: [policy, no patch] How much of The Update Framework integration is needed for alpha-level review/commit of Package Manager?
2. ⚠️ core issue⚠️#3385644: [policy, no patch] Consider whether to keep Package Manager and Automatic Updates in a separate repo/package than core in order to facilitate releasing updates to the updater
3. #3421925: [policy, no patch] Decide if a production level TUF is a requirement for beta-levelcommit of Package Manager

API

Currently none! 🎉

Miscellaneous issues

Currently none! 🎉

Usability revoew

While not a blocker the sooner this work begins the better it is to be successful. This needs an issue to start that process.

Core Alpha Experimental blockers for Automatic Updates

These issues, plus the ones above, block #3253158: Add Alpha level Experimental Update Manager module.

1. #3377458: Remove work arounds for 10.0.x support
2. #3392196: Exceptions in batch no longer are shown on the page when Javascript is disabled - Core bug in 11.x, our AU tests will not pass without it.
3. #3397228: Possible random failure in build tests for cron updates

Core Merge request planning

This is section deals with issues that won't necessary results in changes to the core versions of the module but will make it easier to ensure that contrib version is easy to automatically convert to the versions in the core merge requests and that these merge requests will pass tests.

We are currently relying on Drupalci to test the contrib module. Although Core uses gitlab only now switching to gitlab in the contrib module would not necessarily make things easier for us because core and contrib modules are set up differently for gitlab testing. We can use drupalci until July. If we are not in core by June we can convert our tests to gitlab.

We are currently using our .gitlab-ci.yml to:

1. convert the module to the core version, using them same composer core-convert command we use to make the merge requests
2. Run the all tests besides the Build tests on the core converted version

Alnought .gitlab-ci.yml attempts to make sure we don't break the core onversion it is not exactly like test in in the core merge requests. For this reason we have a core issue #3411111: Automatic Updates Gitlab Conversion test issue that we can use to test out the conversion. We can use this avoid noise on the core merge request issues that will be reviewed especially when we are making changes to the converter itself or want to test out the conversion in the middle of contrib issue exactly how it will be in core.

Here are the remaining issue that need to be addressed

1. #3411110: Test Automatic Updates and Package Manager as part of Drupal core 11.x on GitLab CI. we can't test in 11.x, our target core version, in DrupalCi.
2. #3411240: Run core code quality checks on the core converted version of the module
3. #3411241: Expand ConverterCommand documentation to make it easier to run.

Problem/Motivation

I was profiling some stuff and noticed that route preloading takes up a considerable amount of memory, about 1.5MB in my project.

As a logged in user with navigation module enabled, I also saw 9 calls to preloading routes. (note: 9 calls that actually called into the cache)

2 of those are in early bootstrap from #3503841: RouteNormalizerRequestSubscriber causes two extra route cache lookups.

Then there is a huge list from preloading, 168 routes in my case. Lots of things from layout builder (23 in total) , entity browser, many entity routes such as edit, delete, revision view/revert/delete, autocomplete callbacks, sitemap and more.

Then several more calls from navigation module because it loads each section separately from the menu tree. I believe that this would go away once we improve caching there, as we can properly cache the full navigation section, so not focusing on that here.

Steps to reproduce

Proposed resolution

I kind of see two options. One is to lower the amount of routes we preload, add some more checks, maybe check the is_admin flag instead.

But I'm wondering if there's a different solution. It's only a vague idea at this point, but what if we instead of a full preload, only flag those routes to use a ChainedFast bin (bootstrap?) when requested, but then only load them when actually used?

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

On a 404, we make a subrequest to the configured 404 page.

Because route preloading happens in a request subscriber it runs twice.

Steps to reproduce

Proposed resolution

Add an ::isMainRequest() check to route preloading so it only ever runs once.

Alternatively see if we can move it somewhere on-demand in the routing system, just before we try to lookup a route.

This is potentially testable with a performance test - we should see one less cache get on a 404 (without page_cache running or on a miss).

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

When we get a 404 (and possibly a 403), ExceptionDetectNeedsInstallSubscriber checks if a database table exists. This is completely unnecessary on http exceptions, so it should check if we're dealing with one of those and only run if we don't have one.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Redirecting to /core/install.php is a great feature for people playing with Drupal as they can quickly understand what's going on.

But on the contrary, it's very bad in production with a (big) database problem ! (Even worse when it falls in the varnish cache hush!) 

I was thinking of a configuration key in backoffice, section "Error pages", but since we have no database, it should be a variable in settings.php.

I would like to have the community opinion first ?

=============================
In Drupal\Core\EventSubscriber\ExceptionDetectNeedsInstallSubscriber :

/**
   * Handles errors for this subscriber.
   *
   * @param \Symfony\Component\HttpKernel\Event\GetResponseForExceptionEvent $event
   *   The event to process.
   */
  public function onException(GetResponseForExceptionEvent $event) {
    $exception = $event->getException();
    if ($this->shouldRedirectToInstaller($exception, $this->connection)) {
      // Only redirect if this is an HTML response (i.e., a user trying to view
      // the site in a web browser before installing it).
      $request = $event->getRequest();
      $format = $request->query->get(MainContentViewSubscriber::WRAPPER_FORMAT, $request->getRequestFormat());
      if ($format == 'html') {
        $event->setResponse(new RedirectResponse($request->getBasePath() . '/core/install.php', 302, ['Cache-Control' => 'no-cache']));
      }
    }
  }

Problem/Motivation

When creating a custom admin theme based on Claro it's not picking up Claros block configuration as per:

https://www.drupal.org/docs/theming-drupal/creating-sub-themes#s-inherit...

"If a sub-theme does not supply its own block configurations, Drupal will inherit these block configurations and region placement from the base theme."

I'm instead getting blocks that belong to the sites default end user theme, such as site_branding and powered. The only way around this is to copy Claro's config/ directory to my custom admin theme and manually change any references from claro to the name of my custom theme.

Steps to reproduce

Create a brand new Drupal 10.x site, and create a theme called custom_admin_theme, with the following custom_admin_theme.info.yml file:

name: 'Custom Admin Theme'
type: theme
base theme: claro
core_version_requirement: ^10

regions:
  header: 'Header'
  pre_content: 'Pre-content'
  breadcrumb: Breadcrumb
  highlighted: Highlighted
  help: Help
  content: Content
  page_top: 'Page top'
  page_bottom: 'Page bottom'
  sidebar_first: 'First sidebar'
regions_hidden:
  - sidebar_first

Enable this theme, and do a config export or head to /admin/structure/block/list/custom_admin_theme and you'll see the block configuration doesn't match what is provided by Claro.

Proposed resolution

As I'm not declaring a config directory in my custom theme, use the block config from the base theme Claro as per documentation.

Problem/Motivation

BigPipe is a primary user of the Ajax API. To gain a common understanding of how we can use HTMX in Drupal, we will refactor BigPipe to use HTMX

Proposed resolution

Create a commandQueue and commands within big_pipe module that re-implement the current architecture using htmx where possible.
Create BigPipeCommand classes that preserve the output produced by AjaxCommand classes so that BigPipe is not dependent on classes we intend to deprecate.

Remaining tasks

TBD

User interface changes

No UI features in BigPipe.

Introduced terminology

None

API changes

TBD

Data model changes

TBD

Release notes snippet

Problem/Motivation

Drupal is using its own code to discover tests to be executed, which along time lead to discrepancies in the tests executed betwen PHPUnit CLI and run-tests.sh.

PHPUnit 10 (Feb 2023) introduced an API to discover the test suites, that can be used instead. Also, PHPUnit 10 introduced attributes to replace the annotations that were previously used to indicate test configuration to PHPUnit. PHPUnit 11 (Feb 2024) is triggering deprecations if it detects tests that use annotations. PHPUnit 12 (Feb 2025) no longer supports annotations.

Drupal's TestDiscovery class, that builds the tests to be executed by run-tests.sh, mandates tests to use @group annotations. It fails if only #[Group(...)] attributes are used.

Proposed resolution

• Deprecate TestDiscovery::getTestClasses() and related methods.
• Introduce a like-for-like replacement that uses PHPUnit's API for the discovery, and enriches the information returned by the API to provide same info as TestDiscovery::getTestInfo().
• Make the new code ready for PHpUnit's 10+ attributes instead of annotations.
• In the process, fix some bugs of TestDiscovery::getTestClasses() that were identified:
  • for each test class, it only reports groups present in the class-level annotations: this means that method level annotations do not qualify test classes for a group, potentially missing the execution of some tests. PHPUnit is more accurate in bubbling up method-level annotations/attributes to the class
  • it does not check duplication of @group annotations that specify the same group. PHPUnit make them unique.
  • when filtering by test suite, it reports some test groups with an empty array, since in any case it iterates all test directories and files. PHPUnit only scans the directories indicated in phpunit.xml for each test suite, providing more accurate results.
• Very interesting side effect of this - since PHPUnit discovery actually executes the dataproviders, and includes in the discovery list as many test cases as the number of datasets provided for a test method, we can now be precise in the number of test cases run for each test class, and use that information in run-tests.sh instead of the current approximate count.

Remaining tasks

User interface changes

nope

API changes

nope

Data model changes

nope

Release notes snippet

Drupal tests now can use PHPUnit's 10+ attributes instead of the legacy annotations. New tests MUST use attributes.

Problem/Motivation

Testing installing a module via project browser, I noticed 10 separate calls to ModuleInstaller::install(). The project browser request to install the recipe required a total of over 160mb of memory and took 14 seconds.

This is from RecipeRunner::processInstall() which installs modules one by one.

It means it can't take advantage of #3416522: Add the ability to install multiple modules and only do a single container rebuild to ModuleInstaller, at all, which by itself will be a significant improvement from 11.2 onwards, but ModuleInstaller::install() in 11.1 already has some optimisations when multiple modules are installed at once. e.g. the router is rebuilt 10 times in that request, taking over 2.5 seconds, instead of once.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Problem/Motivation

Steps to reproduce

Proposed resolution

MR 12063 has postcss and compiled CSS updated to latest.

MR 12216 is the same as 12063, except with prettier nesting rules set to "2021" to remove all the :is() selectors. See #7 and #9.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

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)
• Follow on issues: #3501138: Add support for 3rd-party symfony mailer transports, #3500885: Make symfony mail delivery layer more useful to contrib
• #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

Labelling this as a bug for now, but feel free to change it. It certainly feels like a bug to me but #3052042: If an inline block has been edited outside of layout builder it can't be edited in layout builder and the code that explicitly allows this says otherwise.

The problem is, when a block is created via Layout builder (making it inline/non-reusable) and the block is referenced by a node (or whatever entity type) revision that the user can also edit, that user is able to edit the block through the entity.block_content.canonical route.

The code path that lets this happen is from the access control handler into the inline block dependency subscriber

Why is this a bug? It just doesn't seem to fit with what the rest of the solution around inline blocks is trying to achieve. For instance:

1) The block is explicitly filtered out of the block content collection
2) When the block is edited via that UI, the user is then taken to previously mentioned collection screen where the block isn't listed
3) If the user tries to edit the block again they get access denied because now the new revision is no longer referenced by the node revision they can access and the event subscriber doesn't return a dependency which returns access denied
4) The changes the user made are NEVER seen because nothing references that revision.
5) It causes bugs like #3052042: If an inline block has been edited outside of layout builder it can't be edited in layout builder

Proposed resolution

Deny access from editing inline blocks via any UI except layout builder.

Remaining tasks

1. Agree this is a bug
2. Fix 'er up

User interface changes

Remove ability to edit inline blocks via the block content UI.

API changes

TBD

Data model changes

Hopefully none.

Release notes snippet

TBD

Problem/Motivation

The \Drupal\layout_builder\Plugin\Block\InlineBlock plugin has a dependency on code from the Block Content module but the Layout module does not have a dependency on block_content.

Steps to reproduce

1. Install minimal
2. Create a module that implements hook_modules_installed() that looks like this:
   

   function hook_modules_installed(array $modules, bool $is_syncing): void {
     if (in_array('layout_builder', $modules)) {
       \Drupal::service('plugin.manager.block')->getDefinitions();
       \Drupal::service('module_installer')->install(['block_content']);
     }
   }
   

3. Enable the new module
4. Enable layout_builder
5. Observe fatal error

Output:

PHP Fatal error:  Class Drupal\block_content\Entity\BlockContent contains 3 abstract methods and must therefore be declared abstract or implement the remaining methods (Drupal\block_content\Access\RefinableDependentAccessInterface::setAccessDependency, Drupal\block_content\Access\RefinableDependentAccessInterface::addAccessDependency, Drupal\block_content\Access\DependentAccessInterface::getAccessDependency) in core/modules/block_content/src/Entity/BlockContent.php on line 99

Proposed resolution

Move Drupal\block_content\Access\* to Drupal\Core\Access

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet