Drupal 11 compatibility

Hi @mark_fullmer,
I have fixed this issue "Drupal 11 compatibility" and also attached patch
kindly review and verify .

Hi,
MR!35 is ready for a review
To support symfony 7 version for the package simplesamlphp I've raised a issue and got response from the maintainer that he will wait till Nov 2025 @see: https://github.com/simplesamlphp/simplesamlphp/issues/2164

There isn't really a point in doing this until upstream is compatible, we can't claim to be D11 compatible without that. Working with upstream has already been very painful for D10/Symfony 6, and it's clearly repeating again.

You could look into how much work it is to add Symfony 7 compatibility, you might be able to convince them otherwise with an MR that does the hopefully minimal changes and remains backwards compatible, but there's a fairly high chance that they are not interested in that.

@berdir So I forked the repo and bumped the symfony packages to version 7 and ran the composer update to update the changes in composer.lock and I have encountered with php fatal error.

Fatal error: Uncaught Symfony\Component\Console\Exception\LogicException: The command defined in "SimpleSAML\Command\UpdateBinaryTranslationsCommand" cannot have an empty name. in /Users/ankit.pathak/Documents/Projects/drupalissues/simplesamlphp/vendor/symfony/console/Application.php:533
Stack trace:
#0 /Users/ankit.pathak/Documents/Projects/drupalissues/simplesamlphp/bin/translations(16): Symfony\Component\Console\Application->add(Object(SimpleSAML\Command\UpdateBinaryTranslationsCommand))
#1 {main}
  thrown in /Users/ankit.pathak/Documents/Projects/drupalissues/simplesamlphp/vendor/symfony/console/Application.php on line 533

Will try to find same way out when I get some time.

Meanwhile if anyone else can give a shot then below is the require section of simplesamlphp package of which I had tried to update the composer.lock

 "require": {
        "php": "^8.1",
        "ext-date": "*",
        "ext-dom": "*",
        "ext-fileinfo": "*",
        "ext-filter": "*",
        "ext-hash": "*",
        "ext-json": "*",
        "ext-libxml": "*",
        "ext-mbstring": "*",
        "ext-openssl": "*",
        "ext-posix": "*",
        "ext-pcre": "*",
        "ext-session": "*",
        "ext-simplexml": "*",
        "ext-SPL": "*",
        "ext-xml": "*",
        "ext-zlib": "*",

        "beste/clock": "^3.0",
        "gettext/gettext": "^5.7",
        "gettext/translator": "^1.1",
        "phpmailer/phpmailer": "^6.9",
        "psr/log": "^3.0",
        "robrichards/xmlseclibs": "^3.1.1",
        "simplesamlphp/assert": "^1.1",
        "simplesamlphp/composer-module-installer": "^1.3",
        "simplesamlphp/saml2": "^5.0.0-alpha.14",
        "simplesamlphp/saml2-legacy": "^4.6",
        "simplesamlphp/simplesamlphp-assets-base": "^2.2",
        "simplesamlphp/simplesamlphp-module-adfs": "^2.1",
        "simplesamlphp/xml-common": "^1.16",
        "symfony/cache": "^6.4.0 || ^7.0",
        "symfony/config": "^6.4.0 || ^7.0 ",
        "symfony/console": "^6.4.0 || ^7.0",
        "symfony/dependency-injection": "^6.4.0 || ^7.0",
        "symfony/filesystem": "^6.4.0 || ^7.0",
        "symfony/finder": "^6.4.0 || ^7.0",
        "symfony/framework-bundle": "^6.4.0 || ^7.0",
        "symfony/http-foundation": "^6.4.0 || ^7.0",
        "symfony/http-kernel": "^6.4.0 || ^7.0",
        "symfony/intl": "^6.4.0 || ^7.0",
        "symfony/password-hasher": "^6.4.0 || ^7.0",
        "symfony/polyfill-intl-icu": "^1.30",
        "symfony/psr-http-message-bridge": "^6.4.0 || ^7.0",
        "symfony/routing": "^6.4.0 || ^7.0",
        "symfony/translation-contracts": "^3.0",
        "symfony/twig-bridge": "^6.4.0 || ^7.0",
        "symfony/var-exporter": "^6.4.0 || ^7.0",
        "twig/intl-extra": "^3.10",
        "twig/twig": "^3.10",
        "symfony/yaml": "^6.4 || ^7.0"
    },

According to the following conversions with simplesamlphp repository in Github:

https://github.com/simplesamlphp/simplesamlphp/issues/2008#issuecomment-...

https://github.com/simplesamlphp/simplesamlphp/issues/2164#issuecomment-...

Pretty much, the answer from them on Symfony 7 is no.

By the way, will the Drupal 10.4 stick with Symfony 6 to the end?

Yes, exactly what I expected, they are quite set on how they handle things and it likely won't budge.

Yes, Drupal 10 will stick with Symfony 6 LTS, so from a security perspective, it should be ok. Maybe someone will fork a version that provides Symfony 7 compatibility, plenty of people are interested in it after all.

Hi, everyone!
I'm currently in the middle of a job that needs the availability of this package to Drupal 11, and would like to participate and help in the best way I can.

Since yesterday, I was checking on the simplesamlphp package, and making some very raw tests with Composer updates (I think I'm a newbie on this matter) in a local clone of the repo (branch 'simplesamlphp-2.4').

On doing some experimentation. I found the following:
→ By updating almost all Symfony requirements at composer.json and running composer update "symfony/*", I got a somewhat clean update (just 2 vulnerabilities about Twig, but I didn't explore).
→ The only Symfony package that I couldn't change was symfony/finder.
→→ This package is tied to simplesamlphp/xml-security ^1.7 which, in turn, is tied to simplesamlphp/xml-common ^1.18.
→→ Now, simplesamlphp/xml-common ^1.18 is, then, tied to symfony/finder ^6.4.
→ Maybe, if we had a new fork of simplesamlphp/xml-common that supports symfony/finder ^7.0, and also a fork of simplesamlphp/simplesamlphp that would use this first fork, we could then get a version of SimpleSAML PHP package that works with Symfony 7.

Investigation about this matter is still in progress.

So, I read the comments from the maintainer of SSP, and while it is disappointing, I just search for D10 EOL, and this article → from 2023 says it will be supported until 11/26, which means we should all have plenty of security support for d10 well past the Symphony 7 LTS date in 11/25.

Have I misunderstood something? If d10 will get security support past 11/25, then I don't think nearly as many people will have a problem waiting until then to upgrade to d11. I know I'd really prefer to get on d11 ASAP, but waiting for LTS with security patches is much preferred to trying to migrate away from SSP.

Have I misunderstood something? If d10 will get security support past 11/25, then I don't think nearly as many people will have a problem waiting until then to upgrade to d11.

That's my understanding, too. Our team is looking at likely delaying our update to Drupal 11 for the single reason of the simplesamlphp incompatibility with Symfony 7.

One of the comments on their issue says:

Also, you don't have to include SimpleSAMLphp in your Laravel-project. It's perfectly possible to install it as a separate project next to your Laravel-project so the different Symfony-versions can work independently.

Is that at all possible in a Drupal setup?

Yes, Drupal 10 is LTS and supported until 26 for the same reason that SimpleSAMLphp doesn't want to switch earlier to Symfony 7, the Symfony LTS support cycle.

And no, you can't install it separately, not how this module is currently implemented. You can kind of install it without composer, but you're guaranteed to get into version conflicts like this recent issue: 🐛 twig conflict Active . You'll end up loading a mix of different conflicting versions of Twig/Symfony, exactly what composer is designed to prevent. Maybe it could be implemented differently, I don't know.

Regarding bypassing the version constraints by Composer, you can use the Composer's aliasing feature to allow you to complete the installation by using Composer. For example, in your local composer.json file you can add the following lines into the require section.

"symfony/cache": "7.2 as 6.4.0",
        "symfony/config": "7.2 as 6.4.0",
        "symfony/console": "7.2 as 6.4.0",
        "symfony/dependency-injection": "7.2 as 6.4.0",
        "symfony/filesystem": "7.2 as 6.4.0",
        "symfony/finder": "7.2 as 6.4.0",
        "symfony/framework-bundle": "7.2 as 6.4.0",
        "symfony/http-foundation": "7.2 as 6.4.0",
        "symfony/http-kernel": "7.2 as 6.4.0",
        "symfony/intl": "7.2 as 6.4.0",
        "symfony/password-hasher": "7.2 as 6.4.0",
        "symfony/polyfill-intl-icu": "^1.28",
        "symfony/psr-http-message-bridge": "7.2 as 6.4.0",
        "symfony/routing": "7.2 as 6.4.0",
        "symfony/twig-bridge": "7.2 as 6.4.0",
        "symfony/var-exporter": "7.2 as 6.4.0",
        "symfony/yaml": "7.2 as 6.4.0",

Please be advised that this is for testing purpose and not recommended for production. It aliases Symfony 7.2 components as if they were 6.4.0 to allow you bypassing version checks during the composer's install process. After that, you can test out if there is any compatibility issues with Drupal 11.