#Drupal 11 compatibility

That would be great to commit this, I wanted to use the module but couldn't because it is not compatible Drupal 11.

There is something wrong with this issue fork. The patch in MR!15 may apply to 8.x-1.x in this issue fork, but it does not apply against the 8.x-1.0-beta6 release, nor does it apply against the latest 8.x-1.x of the actual project.

First of all, this fork's 8.x-1.x branch should be rebased against the project 8.x-1.x, as it is currently at the beta6 tag. I tried to do so, but don't have push access.

Second, there is something odd with this "project-update-bot-only" branch which prevents the MR!15 patch to be applied outside this fork. Attempting to apply the MR!15 patch to either the beta6 tag or the most recent 8.x-1.x of the module results in the following rejection to be generated. a.k.a workflow_buttons.module.rej:

@@ -105,7 +105,7 @@
       'workflow_buttons' => TRUE,
     ];
     $form_builder = \Drupal::service('entity.form_builder');
-    assert($form_builder instanceof FormBuilder);
+    assert($form_builder instanceof EntityFormBuilderInterface);
     try {
       $form = $form_builder->getForm($entity, 'default', $form_state_additions);
     }

I've tried to figure out how this discrepancy crept in, and so far have not figured things out. Basically, assert($form_builder instanceof FormBuilder); doesn't exist in either (beta6 or the module's latest 8.x-1.x), so the patch fails to find the line to remove.

Hopefully someone more familiar with this module's history can figure it out. As it is, someone trying to get their implementation of this module ready for Drupal 11 is going to have a hard time.

MR20 seems to be working fine with Drupal 11.1.5 (installed with the help of the Lenient Composer Plugin → ).

Works for me on 11.1.5

Patch is working for me on Drupal 11.1.5

Note for the maintainers: In Drupal 11, Symfony's denormalize method was using the wrong denormalizer provided by Bibcite. For example, when using the populate reference form to add a BibTeX reference, Symfony would return Bibcite's ContributorNormalizer class instead of the BibtexReferenceNormalizer class. After setting the BibtexReferenceNormalizer service to a higher priority, Symfony returned the correct class.

Additionally, calls to $this->serializer->denormalize in ReferenceNormalizer and BibtexReferenceNormalizer would fail to create contributor and keyword entities. Changing these to use Drupal's denormalizer seems to fix that issue.

If you approve of these changes, please consider creating a new release. Thanks!

Runs smoothly on D11.1.5 for me

Merge request !27
I was able to configure the module and send an email using version 2.0.0 of the module.

knyshuk.vova → changed the visibility of the branch 3451175-automated-drupal-11 to hidden.

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

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

knyshuk.vova → made their first commit to this issue’s fork.

Move to RTBC

@znaeff, does it affect D11 compatibility?

Created a 1.1.5 release now with D11 support 👍

@danrod's changes were rejected, so we are in the same position as we are in the first place, is there a similar module we can use?

Or perhaps creating a new one with less features but enough for what we need to release Wxt 6.1.0 D11

https://www.drupal.org/project/layout_builder_st/issues/3497945#comment-... 📌 Make coding standards fixes Active

If there are lots of tests that are failing, it means that this module was poorly written in the first place.

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

Pushed a commit that fixes the /api/[entity-type]/[bundle]/resource/schema routes.

This Drupal core change record describes the change that was necessary: https://www.drupal.org/node/3359695 →

Back to Needs Review!

Hello @_kom__,
Thank you for waiting.

Our developers have checked this issue. This notification does not affect performance/stability/security, we use it because we must support users on versions less than 10.1.x.

The root /api/schema endpoint and collection endpoints (/api/[entity-type]/[bundle]/collection/schema) seem to be working.

Not working yet...

I tried to view a schema endpoint (/api/[entity-type]/[bundle]/resource/schema) in my browser and the following error occurs:

Uncaught PHP Exception Symfony\\Component\\Serializer\\Exception\\NotNormalizableValueException: "Could not normalize object of type "Drupal\\Core\\Field\\BaseFieldDefinition", no supporting normalizer found." at /opt/drupal/vendor/symfony/serializer/Serializer.php line 181

Opened a merge request with @volha_si's commit from 🐛 PHP8.3 compatibility issues Active (I updated the commit message to be more descriptive of its purpose, but kept the author credit).

I also added a commit that drops support for Drupal 8, 9, and 10. So this will need to be a new major release (not on the 8.x-1.x branch) - pending @bradjones1's response to my question above (#10).

I will do more testing locally and report back if I find any other issues.

@m.stena Probably related to this: https://www.drupal.org/project/jsonapi_schema/issues/3504440 🐛 PHP8.3 compatibility issues Active

Thanks @alexander-tallqvist!

This error is actually a result of changes in the upstream Symfony class that we extend from. So I don't think it's specific to PHP 8.3.

We can probably close 🐛 PHP8.3 compatibility issues Active as a duplicate of this issue, and incorporate the MR changes into here. I'll start a new MR and cherry-pick them over.

Fatal error: Declaration of Drupal\jsonapi_schema\Normalizer\DataDefinitionNormalizer::normalize($entity, $format = null, array $context = []) must be compatible with Symfony\Component\Serializer\Normalizer\NormalizerInterface::normalize(mixed $data, ?string $format = null, array $context = [])

I think fixing this is going to necessitate dropping support for Drupal 10.

@bradjones1: I see that you have started a 2.x (and 2.0.x) branch that makes some of these changes already. Should I base a MR off of one of those? I can't find any mention of them in the issue queue, and there are a number of other changes. Any guidance you can provide on your intentions would be appreciated! I want to help push this forward, but don't want to step on toes or duplicate efforts.

@m.stena Probably related to this: https://www.drupal.org/project/jsonapi_schema/issues/3504440 🐛 PHP8.3 compatibility issues Active

I tested installing on Drupal 11.1.5 and it failed with the following error:

$ drush en jsonapi_schema

Fatal error: Declaration of Drupal\jsonapi_schema\Normalizer\DataDefinitionNormalizer::normalize($entity, $format = null, array $context = []) must be compatible with Symfony\Component\Serializer\Normalizer\NormalizerInterface::normalize(mixed $data, ?string $format = null, array $context = []): ArrayObject|array|string|int|float|bool|null in /opt/repos/jsonapi_schema/src/Normalizer/DataDefinitionNormalizer.php on line 53
 [warning] Drush command terminated abnormally.

I had to fix this in farmOS as well, so I'm familiar with the solution. I'll work on this...

Thanks.
The module has added support for Drupal 11.

Thanks for testing @onfire84 and @alexander-tallqvist.

Let's get confirmation that this works on Drupal 11. Setting back to Needs Review.

Tested the automated patch with a site running Drupal 10.3.14. Everything seems to be working fine!

Tested the automated patch on a site running Drupal 10.3.14. Everything seems to be working normally.

Tested MR!5 on a Drupal 10.3.14 site. Everything seems to be working fine.

Patch seems to be working for me on a Drupal 10.3.14 site.

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

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

The issue summary suggests that also src/Plugin/RulesAction/UserEmailVerificationVerifyUserEmail.php should be changed, but the merge request does not change that file.
The composer.json file is not necessary for compatibility with Drupal 11.

The issue summary needs to be updated: It just says which files should be changed, but it does not describe what needs to be fixed, and why.

Could this be a duplicate of 📌 Create Custom Permissions 8.x-2.2 release for Drupal 11 support Active ?

If you would like to help moving this issue forward and get the module compatible with Drupal 11, please help us test and fix the following issues first:

• 🐛 Permissions that depend on disabled modules prevent any editing/creation of other permissions Needs review
• 🐛 Module does not work with routes that implement _entity_access Needs review

Thanks in advance!

I reviewed this issue and the changes looks good to me as there are no errors after applying MR-8.
Thus moving to RTBC!!

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

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

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

Drupal 11 compatible stable release created, see: 3.1.0 → .

Thanks everyone for the great help and in advance for your testing and feedback.

For testing purposes, I have allowed entity_browser_block 2.0. I have not tested that this actually works.

It's trying to install on Drupal 11, but composer.json lists a dependency on a version of entity_browser_block that only runs on Drupal 10.

I think we can bring the patch in. I am testing in Drupal 10.4 11.0 11.1 to finally put it to bed to this point.

However re xpath note I believe we need a better body field picker in Drupal 11.1 (similar to the other field pickers in the wizard) . New issue added ✨ Add body field picker w default to wizard & processing Active . It works in Drupal 10.4 and 11.1 with the default 'body' field but it doesn't warn the user if this situation isn't connected.

I created the MR, and it's failing. What would be the next steps?

I prefer to fix the "Unsafe usage of new static()" issue by configuring an ignore rule → .

Please use an issue fork and merge request so that tests run.

I'll have another look on this issue now.

alexdmccabe → closed merge request !2

Thanks edsoncarlos! Looks like we missed that over in 🐛 Deprecated FormElement Active . Issue filed: 🐛 Bump up minimum Drupal version to 10.3 Active

I haven't been able to figure this out.

trackleft2 → changed the visibility of the branch 3431903-automated-drupal-11-trackleft2 to hidden.

Tests pass!

There was one minor PHP CodeSniffer warning, so I pushed a commit to fix that too. :-)

I'd say this is ready for merge! Setting to RTBC...

@alexpott @pcambra please see my suggestion re: a new 2.x branch and 2.0.0 release above! Curious what you think about that.

I would like to propose that we create a new 2.x branch for these changes, since support is being dropped for older Drupal core versions, and move forward with a 2.0.0 semantic versioning release, without the -beta designation.

What do you think @alexpott @pcambra?

I'm reviewing this now...

I see that "Bot run #11-137198" has already been merged into 8.x-1.x: https://git.drupalcode.org/project/entity_reference_validators/-/commit/...

@pierrepaul's MR makes two more changes:

1. All references to </code> are replaced with . See relevant core change record: https://www.drupal.org/node/3401941 →
2. Support is added for ^11 and dropped for ^8 || ^9.

With those changes, I'm able to include entity_reference_validators via Composer.

Tests are passing when I run them locally. Now let's see if we can get them to pass on Drupal.org GitLab...

I rebased @pierrepaul's commit onto 8.x-1.x, and committed two changes to .gitlab-ci.yml:

1. Remove _TARGET_PHP: "8.1". I think we should be testing against the default.
2. Replace _TARGET_CORE: "10.0.7" with OPT_IN_TEST_CURRENT: 1 and OPT_IN_TEST_PREVIOUS_MAJOR: 1 so we can test against Drupal 10 and 11.

.

m.stenta → made their first commit to this issue’s fork.

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

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

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

Hi, if the tag 2.0.0-alpha8 uses the FormElementBase, then this new tag is incompatible with drupal/core versions lower than 10.3.0-beta1, which is when this new class was implemented.

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

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

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

I confirm the issue reported, I reviewed the related issue and it looks good, so I will add a line in this modules readme about it so users know to use it.
The code here also looks good.

Closing, working fine on D11 and no comments in 1/2 year

Quick follow-up on this issue:

Got maintainer's rights for the Toolbar Menu module \o/ 🥳

First, I wanted to make sure the module's Tests could run and pass on Drupal 11.

So, I added a Gitlab CI file to be able to run automated Tests and validation jobs for merge requests, see ( 📌 Automated testing: Configure GitLab CI Active ).
Then, I updated this merge request to be tested with all supported Core versions.

Since the PHPUNIT Tests were all passing 🟢:
https://git.drupalcode.org/project/toolbar_menu/-/pipelines/460931
So, I went ahead and merged the changes above at #9.

A new stable release compatible with Drupal 11 will be created in the coming days.

Feel free to let us know if you have any questions or concerns on any of the latest changes or the project in general, we would surely be glad to help.
Thanks again for all the help testing the module.

I don't use this any more, but if I will commit patches. Does this already work with entity_browser_block 2? Would it just take updating the require to "drupal/entity_browser_block": "^1.0 || ^2.0"?

I wonder why the automated compatibility issue has not appeared for Drupal 11.

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

Version googlelogin 8.x-9.x

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

Version fieldmask 8.0.x

Can this issue be closed?

Hi, is this module working together with adv_varnish module? Are they competitor or complimentary within Drupal 10/11? Thanks for your reply in advance, greetings,

Going to try to fix tests before I put out a release. Mid-week by latest

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

miha.wagner → changed the visibility of the branch 3428157-automated-drupal-11 to active.

miha.wagner → changed the visibility of the branch 3428157-automated-drupal-11 to hidden.

It seems good. Please merge this patch and create a release.

miha.wagner → made their first commit to this issue’s fork.

Please get this in...

Merged! Will tag a release shortly!

Works great for me! Thank you

It took you almost 1 year, I am sorry but I am out

Is it possible to merge this Drupal 11 compatibility to avoid blocking people to use this module on newer version of core? At least as a beta version

juandhr The unit tests have been updated in release 1.1.1.

Thanks everyone! MR 21 has been merged into 2.0.x and tests are now passing in a Drupal 11 environment.

Hello @_kom__,

I will ask our developers about this. We will do our best to fix it.

We will write back to you within 3 business days when we get any results.

Please wait.

Going to mark this one as fixed and updating the gitlab pipeline file to run against different version of core.

Closed as this is a duplicate of 💬 Add a release that supports Drupal 11 Active ( https://www.drupal.org/project/user_update_notify/issues/3465643 💬 Add a release that supports Drupal 11 Active )

wjackson → closed merge request !4

This is Cleantalk code check from Upgrade Status module https://www.drupal.org/project/upgrade_status → , not environment issue.
Drupal 10.4.5, PHP 8.3.19.

Hi devs!
Catch the patch that fixes the issues and gets working well module on Drupal 10.
The patch also includes D11 compatibility fixes.
It would be nice to merge it in the next module version.

Change is merged. Leaving open for more patches.

All tests are now passing in 📌 Make coding standards fixes Active .

Besides the other open issues, it runs nicely with Drupal 11. No additional problems found due to Drupal 11.

Entity embed has had Drupal 11 support since 2 February 2025 https://www.drupal.org/project/entity_embed/releases/8.x-1.7 →

Thanks @mark_fullmer I looked at the commit and confirmed there is nothing there to be alarmed about. Back to RTBC

Merged. Leaving open for project update bot.

Should be good to go now.

Merged into 2.1.x. Leaving issue open for project update bot.

Let's merge this, we were planning on deprecating config_distro_filter, but I think at this point a D11 release is more useful.

Can we please have a new release of this module with Drupal 11 compatibility?

Patch added to 1.2.5 release

Closing in favor of https://www.drupal.org/project/helper/issues/3433341 📌 Automated Drupal 11 compatibility fixes for helper Needs review

Going to merge the existing MR since it's functionally passing for D11, just regression on one test for some reason, and still passing for D10.

I've updated the MR to be mergeable into the latest changes in 8.x-1.x. Setting back to 'Needs review' -- based on the previous comment, this should be able to be set to RTBC forthwith.

dave reid → closed merge request !50

dave reid → made their first commit to this issue’s fork.

This module is now d11 ready.

jalite1991 → closed merge request !17

jalite1991 → closed merge request !18

jalite1991 → reopened merge request !18

jalite1991 → closed merge request !18

Is already D11 ready

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

@subhojit777 @rjjakes If you need some help to make that D11 release happen, I am willing to become a co-maintainer of this module.

pushed to 5.x

Any chance that this will be merged soon?

https://www.drupal.org/project/datetimehideseconds/releases/8.x-1.5 → contains a stable D11 release. Closing as outdated.

Setting my attribution.

What is holding up the release?

Important note:
The pipeline says there's one outstanding phpunit deprecation.

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

@joseph.olstad I see a test where the simulated user (I added an extra admin role to it) tries to add a translation and I get a 403:

I'll follow your advice and set up a vanilla 11.1 instance and do the tests there.

@danrod, there are only 4 test failures and they look related/similar.

Possibly that the test case is invalid. Need to set up a vanilla D10.4 / D11.1 and set up manually the test case(s) and examine the result. Something likely obvious at that point along the way. Possibly a test issue however need to do it and see.

ok @liam morland I'm looking at the Make coding standards fixes 📌 Make coding standards fixes Active issue, all tests are passing, what needs to be done there? I see a bunch of phpcs issues that needs to be addressed, is that the reason why the issue is still in "Needs work"? I can help you with if you want.

Tests are not passing in Gitlab either. I suggest that there be an issue to get tests passing in Drupal 10. Once that is committed, then this issue can get them to pass in Drupal 11. I have taken steps towards this in 📌 Make coding standards fixes Active .

I see 7 failed tests myself, maybe there's something wrong with my phpunit settings?

Can we skip these tests? I've spend an inmense amount of time with no results so far.

Checking on any timeline updates here... currently unable to use the module/form on D11, looks like there's a fix ready to go?

Do we need more testing?

Sadly, had to uninstall this module to complete our D11 upgrade.

This has been completed by @lawxen in the 3.0.x branch, closing ticket and we can open new tickets for any issues in D11.

subscribing

Can confirm the patch is compatible with D11. Waiting on for the release.

I've created a patch with recomendations from Update Status module.

For me, it helps (Drupal Version 11.1.5)