PHP 8.1 Deprecations

Thanks a lot for your work on this so far, and thanks for pinging me about it.

Your changes so far are looking good, just one comment:

</code><code>
+++ b/src/Utility/Utility.php
@@ -139,7 +139,7 @@ class Utility {
-    $pos = $function($property_path, $separator);
+    $pos = $function((string) $property_path, $separator);

By the method’s contract, $property_path already has to be a string, so we should fix the caller instead. (In a second step, we might of course want to add proper type hints.)

I also managed to fix some of the remaining warnings.

Unfortunately, though, my distro doesn’t include PHP 8.1 yet, and I didn’t manage to get MySQL working in my manual build. So especially the autocomplete fail, which I couldn’t reproduce, may just be specific to MySQL.

Furthermore, for the problems in system_requirements() and \Drupal\Core\Extension\ModuleDependencyMessageTrait::checkDependencyMessage() it seems to me like this might be Core’s fault: it sets the default for 'version' to NULL in \Drupal\Core\Extension\ModuleExtensionList::$defaults, which then leads to those errors. Changing this default to '' fixes the warnings for me.

Here's a fix for the core issue - #3239287: Fix \Drupal\Core\Extension\ModuleDependencyMessageTrait to not cause deprecations in PHP 8.1

I can't reproduce the autocomplete fail locally on PHP 8.1 / 9.3.x and mysql / sqlite or psql ... looks like something specific to mysql on DrupalCI... that's not fun.

I think that maybe order is not something that we need to care about here so perhaps the simplest thing to do is change the assert.

Okay so I far as I can see the fail in \Drupal\Tests\search_api_db\Kernel\AutocompleteTest::testAutocompletion is related to DrupalCI mysql 5.7. If I get the docker container and use that in local testing then this test fails regardless of PHP version.

I'm going to open another issue to fix this. The change in #9 is wrong so reverting.

Here's the existing issue. :) #3091198: Investigate problems on MySQL 5.6/5.7

+++ b/src/Item/Field.php
@@ -665,7 +665,7 @@ class Field implements \IteratorAggregate, FieldInterface {
-  public function getIterator() {
+  public function getIterator(): \Traversable {

+++ b/src/Item/Item.php
@@ -455,7 +455,7 @@ class Item implements \IteratorAggregate, ItemInterface {
-  public function getIterator() {
+  public function getIterator(): \Traversable {

+++ b/src/Query/ResultSet.php
@@ -224,7 +224,7 @@ class ResultSet implements \IteratorAggregate, ResultSetInterface {
-  public function getIterator() {
+  public function getIterator(): \Traversable {

If you know of upstream projects that extend these classes and override these methods it might be friendlier to add the [#\ReturnTypeWillChange] PHP attribute instead.

We can change the return types in the upcoming 2.0.x version of Search API

Awesome, thanks a lot for your help! Great we even got the Core issue fixed …

I’m pretty sure no-one overrides any of those classes, but you’re right, it’s cleaner not to introduce a BC break for this.

So, no objections to your last patch. Committed. Thanks again!

@drunken monkey Facets module is reporting PHP8.1 deprecations since it depends on Search API. Is there a plan for a minor release?

[edit] See https://www.drupal.org/node/2348769/qa

Filed follow-up for facets #3255241: Add compatibility with PHP 8.1

@drunken monkey Facets module is reporting PHP8.1 deprecations since it depends on Search API. Is there a plan for a minor release?

Huh, strange … I though automated tests will use the latest dev version by default, not the latest stable release.
Anyways, yes, I’ll create a new release shortly, so should be resolved soon.

there are plan to incorporate this patch on the 8.x branch?

This issue was released in 8.x-1.22, see https://www.drupal.org/project/search_api/releases/8.x-1.22

with php 8.1 and v8.x-1.25 i still have deprecation errors
Deprecated function: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\search_api\Utility\Utility::splitPropertyPath()

this is the patch i have used to solve the issue

#22 That particular code wasn't touched in the code committed in this issue. I suggest you file a new follow-up issue and upload your patch file there, since this issue is now Closed.