Make the Search API module compatible with Drupal 11

Hi @drunken monkey,
I have fixed this issue "Make module compatible with Drupal 11" and also attached patch,
please review and verify .

Fixed the invalid code in SearchApiBulkForm and created an MR to test the changes.
However, we first need all dependencies to declare Drupal 11 compatibility before we can properly test this.

OK, thinking about this a bit more, this is a bit of a chicken/egg situation, where we also cannot test dependencies against Drupal 11 until this module is compatible. So, I guess we’ll have to just go ahead and hope for the best, and fix any test errors/bugs that might show up once it’s possible to run the test suite against Drupal 11.

Merged this, but keeping it open so I remember to active testing against Drupal 11 once that is available (i.e., all test dependencies support it as well).

Marking this “Fixed”, further work will be done in 📌 Automated Drupal 11 compatibility fixes for search_api_saved_searches Needs review .

Nvm, that was for the wrong module. Seems Update Bot can’t find any faults in this one, which is encouraging.

Still waiting on 📌 Make language_fallback_fix compatible with Drupal 11 Needs review . Adding that as a related issue.

I now just committed that issue myself and triggered a pipeline with Drupal 11 testing. Unfortunately, it showed that there is currently a fatal error, as Core added return type hints to the __sleep() and __wakeup() methods of

I created an MR that will hopefully fix this. Unfortunately, it will break all classes that override those methods (i.e., some of the modules providing backend plugins) even with Drupal 10, so this will probably not go in right away. First, as many of the sub classes should be fixed as possible.

I’ve deactivated weekly testing against D11 again for now.

Huh, seems the Action module was removed in D11 ( 📌 Remove Action UI module Postponed ) and some of our tests depend on that. So, another thing to fix …

Wow, seems there’s still a lot to do …

Fortunately for us, it seems like Drupal 11 won’t be coming out in July after all, so we still have quite a bit of time left.

My question now would be whether we should keep the core_version_requirement: ^10.1 || ^11 line in our .info.yml file? Reverting that to just ^10.1 after we had already declared ^11 in several stable releases seems risky, but on the other hand declaring compatibility while there are still fatal errors when doing almost anything with the module is also highly misleading. And since that is the case, it doesn’t seem likely anyone would have been using this module with Drupal 11 anyways, so we wouldn’t be breaking anything by reverting the Drupal core version requirement.

In any case, I now added a note about this to the 1.34 release notes → .

Please note that Drupal 11 is still very much on track to be released on July 29th: https://www.drupal.org/about/core/blog/drupal-1100-alpha-1-will-be-relea... →

Decisions will be made by the end of this week.

It's been confirmed that Drupal 11 will most likely be released in the week of July 29th.

The current MR doesn't apply anymore. I've rebased the MR against the latest state of 8.x-1.x-dev and fixed the merge conflicts.

Pipeline is green, so to not hold this up further (especially since we’re already advertising that the module supports Drupal 11) I merged the MR right away. In case other problems pop up we can always open a new issue for those.
Anyways, thanks again everyone for your help!

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

It fixed the problem on Drupal 11 alright, how about a release with a fix?