Automated Drupal 11 compatibility fixes for symfony_mailer

This is an automated patch generated using Upgrade Status and Drupal Rector. Please see the issue summary for more details. A merge request (MR) is also openend and updated.

It is important that any automated tests available are run and that you manually test the changes.

Drupal 11 Compatibility

According to the Upgrade Status module → , even with these changes, this module is not yet compatible with Drupal 11.

Currently Drupal Rector, version 0.20.1, cannot fix all Drupal 11 compatibility problems.

Therefore, these changes did not update the info.yml file for Drupal 11 compatibility.

The compatibility issues that Upgrade Status found after the Drupal Rector fixes were applied are attached to help you resolve them manually.

Leaving this issue open, even after committing the current patch or merging the MR, will allow the Project Update Bot → to post additional Drupal 11 compatibility fixes as they become available in Drupal Rector.

Debug information

These packages were used to generate the fixes:

1. drupal/upgrade_status: 4.3.1
2. mglaman/phpstan-drupal: 1.2.11
3. palantirnet/drupal-rector: 0.20.1

deepakkm → changed the visibility of the branch project-update-bot-only to hidden.

Thanks, I made some comments

Thanks for reviewing!!
Done with required changes, let me know if we can merge and do a D11 release.

I think the tests are failing after the changes , will look into this and fix the pipeline.

Fixed the small copy/paste mistakes.

It can be improved by using the deprecation helper but so far it looks good to me to release a D11 compatible version.

Thank you everyone for your work! The changes seem working so it's good to be RTBC by me. The only unresolved thread is regarding the `.gitlab-ci.yml` variables.

I just want to add some really kind and gentle pressure on this in order to say that websites using this module (32500+ currently) will not be able to upgrade to Drupal 11 without a stable version containing these changes. Drupal Lenient composer plugin won't solve the problem since we still have the dependency issue coming from the "symfony/mailer": "^5.3 || ^6.0" requirement and Lenient only fixes "drupal/core" requirements.

A possible workaround I have found is to change my composer.json's repositories property to the following, while also adding the diff from the MR as patch of course:

{
            "type": "package",
            "package": {
                "version": "1.4.2",
                "name": "drupal/symfony_mailer",
                "description": "Symfony Mailer",
                "type": "drupal-module",
                "license": "GPL-2.0-or-later",
                "require": {
                    "html2text/html2text": "^4.0.1",
                    "symfony/mailer": "^5.3 || ^6.0 || ^7.1@beta",
                    "tijsverkoyen/css-to-inline-styles": "^2.2"
                },
                "extra": {
                    "drush": {
                        "services": {
                            "drush.services.yml": "^11"
                        }
                    }
                }
            }
        },
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8"
        }

I feel that the key is to limit the range of supported core versions. We should not need to call version_compare! Instead we can remove the old code and increase the minimum core version.

1. Using the Random class makes D11 work but breaks D9.
2. The change from renderPlain() to renderInIsolation() makes D12 work, but breaks D10.2.

So core_version_requirement should be 10.3 || ^11. I'll bump the minor version to 1.5, and anyone still on D10.2 will stay on 1.4. Easy😃.

Done with all the feedback changes, hence moving into review.

Great thanks it looks good just one thread is unresolved still

I was able to install & enable this in Drupal 11. Great work!

Yes thanks but please see #15.

I see a potential problem with the "Broaden test coverage" part. It seems to me that in future the tests are likely to break when code is added to 11.x-dev e.g. new deprecations. Or CORE_PHP_MAX will eventually jump to a new version which we don't necessarily yet support. Also it just slows down every test run.

What's the downside if we remove these lines? Well someone could accidentally write code that uses something that has been removed from 11.x, and we wouldn't notice. But then anyway it was likely deprecated in 10.3? To me this feels much less of a problem than the above.

Hello AdamPS → , I have updated MR with the requested changes and also created a separate issue 📌 Broaden test coverage. Active for broaden test coverage. Hence requesting review.

renderPlain is deprecated in D10.2 so I would suggest to keep minimum support of ^10.2 in info.yml and I'm not seeing any other deprecation fixes other then renderPlain.
What are your thoughts?

Great thanks

I believe the minimum support is because renderInIsolation was only added in 10.3

Automatically closed - issue fixed for 2 weeks with no activity.