Querying with NULL values results in warning mb_strtolower(): Passing null to parameter is deprecated

elseif (!is_bool($condition['value'])) {
- $condition['value'] = mb_strtolower($condition['value']);
+ $condition['value'] = mb_strtolower($condition['value'] ?? "");
}

I'm not convinced that we should turn NULL into "" here.

It seems to me the better fix would be to exclude the NULL case from mbstring in the if like

> elseif (!is_bool($condition['value']) && isset($condition['value']))

?

Made changes as per comment #3, please review.

+ elseif (!is_bool($condition['value']) && isset($condition['value'])) {
$condition['value'] = mb_strtolower($condition['value']);
}
+ else {
+ $condition['value'] = NULL;
+ }

this fails if the value is bool. but when $condition['value'] is already NULL it's not necessary to assign it, so just keeping $condition['value'] and having no else {} part should be fine then?

Patch of #7 seems to be wrong if value is FALSE.
Actually, I think patch #4 is correct. if no massaging of the value is necessary, no else {} clause is necessary. Right?

agreed, so #4 is the right fix. I verified it solves the issue as well, so all good then.

It looks a little odd to me to check isset() after is_bool(), what about this?

Setting back to needs work as patch #11 fails.

Whoops this time without the syntax error.

Thanks, #13 fixed the issue on 9.4.5.

#13 fixed my issue on 9.5.0-dev

but I have faced issues after adding

TypeError: mb_strtolower(): Argument #1 ($string) must be of type string, array given in mb_strtolower() (line 174 of core/lib/Drupal/Core/Config/Entity/Query/Condition.php).

$block_ids = \Drupal::entityQuery('block')->condition('third_party_settings', Null, '<>')->execute();

Re #15 try
$block_ids = \Drupal::entityQuery('block')->condition('third_party_settings', 'IS NOT NULL')->execute(); instead?

#13 fixed testPostUpdateTaxonomyIndexFilterMultipleVocabularies() in the patch in comment #212 of issue #2784233: Allow multiple vocabularies in the taxonomy filter

It looks a little odd to me to check isset() after is_bool()

+1

#13 looks good to me.

#3301692: mb_strtolower(): Passing null to parameter #1 ($string) of type string is deprecated with PHP 8.1 is a duplicate of this?

When we had these errors while prepping for PHP 8 we tracked them back to the caller. This error is pointing something else being amiss and not as expected.

>#13 fixed testPostUpdateTaxonomyIndexFilterMultipleVocabularies() in the patch in comment #212 of issue #2784233: Allow multiple vocabularies in the taxonomy filter

FYI, found that it's the view for testing in which the `uuid` is missing, the patch here is no more required.

Judged by the issue summary, the deprecated message was raised while installing a non-core module: `ldp_translation`, per @alexpott's comment, is this a won't fix? Setting back to NR for opinions.

Closed as a duplicate https://www.drupal.org/project/drupal/issues/3301692#comment-14802752 moving over credit.

Although the patch in #13 fixed the error for me, while stepping through in debug, I noticed the array_map in line 36 is running against this value:

$condition = {array}
  field = "status"
  value = {array}
    0 => true
  operator = "IN"
  langcode = null

When value is not an array, the elseif at line 38 is checking is_bool(), and skipping the mb_strtolower() if it is. Should it be skipped in line 36 as well?

Have to be in agreement with @jungle in #19. Seems this patch was just covering a symptom but the cause has been fixed.

If anyone disagrees please reopen with an explanation why.

Thanks!

I wonder if closing won't fix is quite what we want to do? Could we complain more loudly or do something to help track down these issues? I regularly see these warnings in test runs and its a bear to figure out where the null is coming from. Being more loud in our logging of the source would be really nice.

We're seeing these warnings show up in various contexts when using exported configuration entities provided by custom modules in config/install directories that do not have UUIDs. It looks like the Drupal\Core\Config\Entity\ConfigEntityBase::preSave() method uses Drupal\Core\Entity\EntityBase::uuid() when creating query conditions which returns NULL if a UUID doesn't exist.

The attached patch changes those NULL values into empty strings in Drupal\Core\Config\Entity\ConfigEntityBase::preSave() to prevent them from getting passed as query condition values.

The issue summary should be updated with the new proposed solution.

Will also require a test case to show the problem.

Got this notice/warning in D10 using php 8.1 when switching text format from ckeditor5 to ckeditor4
patch 25 resolves the issue.

Hi!
I confirm that #13 fixed the issue for me on Drupal 9.5.9 with php 8.1.
Thank you!

Part of why this is becoming an issue, more and more is because of #3369127: 'filter.format.' . WebformHtmlEditor::DEFAULT_FILTER_FORMAT missing UUID.

kindly review the patch.

Still needs tests and issue summary update

Please review the Patch

Added a new patch. Fixing build issue. Please review

Rerolled patch #36, please review it.

Thanks!

Thank you for the interest but please read the tags. Previously tagged for issue summary update and tests.

Also the MR is on the correct branch and should continue there.

"Needs tests"

Still needs a test.

Merge request !4263 fixed my issue on Drupal 10.1.2 (PHP 8.1.14 / MySQL 5.7.29)

Thanks.

I've been unable to reproduce this by enabling modules. Attempted several contrib modules (including ckeditor 4 and 5) in fresh Drupal 10.1.x install.

@bjc2265, are you using PHP 8.0 or PHP 8.1+ ?

This fix is for PHP 8.1+

Using PHP 8.1.8 and Drupal 10.1.4

Just to confirm: message should appear in GUI after going to Extend tab, selecting a module that changes configuration (such as Configuration Translation or Content Translation) and clicking Install? Because doing that on fresh install I'm not seeing error in logs or as alert.

I don't know how to do test only patches with gitlab. I also was not able to "claim" push access to the fork

Anyway. Here is a test only patch, please feel free to add to the fork

If you click "Get push access" there's an option on the pipeline https://git.drupalcode.org/issue/drupal-3302838/-/pipelines/56031

There you can click "Test-only feature"

Current MR appears to have test failures.

Was previously tagged for issue summary too as some sections appear to be missing.

I did click the "get push access" and have done so many times before as well. But some hiccup today probably? Tried again now, and now it works :)

Let me try to rebase and get the test only thing in there as well, never tried that before.

Leaving on NW for the issue summary part

Now will say there's a bug/feature being worked out where if the MR is opened by a core committer, even getting push access you can't run the test-only feature or rerun any tests.

right. was probably just a hiccup I guess, since both work now.

Link to test-only run: https://git.drupalcode.org/issue/drupal-3302838/-/jobs/799034

Removing tests tag

updated issue summary

As per #18 this is fixing the symptom and not the cause. If a config entity is missing a UUID then a module is doing something wrong. The configuration is not valid.

I am adding another related issue as the solutions are the same.

I'm updating the MR to include the is_string validation since the function mb_strtolower expects a string as parameter.

Appears to have test failures.

Adding a related contrib issue, from CAPTCHA module.
From #3497314-6: Tests are failing for Drupal 11.1:

This last one is drupal core fault, when saving new config entity on preSave() it tries to load existing entity by uuid in core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php line 308. I didn't find the issue for this on drupal core issues. So now we just pre-fill uuid on new CaptchaPoint creation in captcha_set_form_id_setting()

diff --git a/captcha.inc b/captcha.inc
index 97610420731b23a2d7bf285bff5b0a06a8900715..72bdf9f861c4d847bc689d02ec01399409f057aa 100755
--- a/captcha.inc
+++ b/captcha.inc
@@ -34,6 +34,10 @@ function captcha_set_form_id_setting($form_id, $captcha_type) {
     $captcha_point = new CaptchaPoint([
       'formId' => $form_id,
       'captchaType' => $captcha_type,
+      // @see https://www.drupal.org/project/drupal/issues/3302838
+      // On config pre-save drupal tries to query same uuid, and deprecation
+      // is generated. So we prefill the uuid for now.
+      'uuid' => \Drupal::service('uuid')->generate(),
     ], 'captcha_point');
   }
   $captcha_point->enable();

Just adding a new patch from the latest MR.