Deprecated: preg_split(): Passing null in argument_validator

Thanks for the report. Why is the variable null? We have had so many reports like this and in many cases we don't accept workaround patches but rather seek to find out why bad data is arriving at the library function.

Can you replicate this by installing a new Drupal site?

I am coming across the same issue; and as far as I can tell it is not an issue with custom code.

This is my scenario:

I have a view that includes 2 arguments. The first (and problematic) one is 'Has taxonomy term ID'. I have default values set for this; but if none are found (i.e. there is no valid taxonomy term), then the resulting value is NULL. It looks like that is because of this line of code:

$arg = (isset($this->args[$position]) && $this->args[$position] !== '') ? $this->args[$position] : NULL;

Which can be found in the _buildArguments() function in the ViewExecutable.php class.

Changing this value to:

$arg = (isset($this->args[$position]) && $this->args[$position] !== '') ? $this->args[$position] : '';

Fixes the issue for me... But I'm not sure what the knock on effects may be for a change like this. If there are no foreseeable issues, then I can provide a patch with this change.

The following line of code may also need updating (possibly removing?), in case the code is ever executed (in which case the NULL value will again break functionality):

$arg = $arg !== '' ? $arg : NULL;

This is also in the same function, a few lines below the aforementioned one.

Upon further investigation, it seems that changing that line of code breaks other arguments.

It seems that this code:

$arg = $arg !== '' ? $arg : NULL;

Should be changed to something like:

$arg = $arg !== '' ? $arg : -1;

That fixes it on my side without breaking anything else (from what I can see).

This is on line 1094

Also FWIW, this is not specific to Drupal 10 and instead relates to PHP 8.1. I have tested this on Drupal 9.4.8 and 9.4.11 with the same results.

Hi i have the same issue on a view with several contextual filters,
the warning only occurs on backoffice previews, or on frontend if ajax is enabled.

The issue also makes ajax filtering returning no results whereas the results are ok with ajax turned off.
Here is a patch against core 9.5.4.

if ($argument !== null) {
  $args = preg_split('/\s+/', $argument, -1, PREG_SPLIT_NO_EMPTY);
}

This will prevent the deprecated warning from being triggered when $argument is null.

Thanks for providing the steps to reproduce this, indeed easy enough to trigger this.

Easy Steps:
* Install Umami
* Edit the content View
* Add a contextual filter on ID
* Set default to 'Taxonomy ID from URL'
* Check 'Specify validation criteria'
* Set 'Validator' to taxonomy term
* Choose option 'One or more IDs separated by , or +'
* Try to save and reload the Preview
* Check spam in watchdog

Ok, so now we know that NULL is a valid value for validation, we can add a test and the check for NULL! Adding a full blown functional test for this seems overkill in this issue, so lets just do a unit test

This adds a test for with and without multiple set and passing in NULL

The test only patch is the interdiff.

Ignore those patches, here are the correct ones!

The last submitted patch, 11: 3338973-10-TEST_ONLY.patch, failed testing. View results →

The last submitted patch, 11: 3338973-10.patch, failed testing. View results →

Unrelated fail

Does this mean we need to add an update hook to change views that currently have NULL as a value? If we don't need that, this change looks great and has sufficient test coverage.

This is only for contextual filter value validation, so the value should be contextual and not be set in the View, so I don't think there would be anything to update here.

In that case, I think we can get this in.

The last submitted patch, 8: 3338973-8.patch, failed testing. View results →

The last submitted patch, 8: 3338973-8.patch, failed testing. View results →

+1 RTBC. While reviewing site logs found a lot of these errors. Patch #11 fixed the issue.

Committed c4bbc93 and pushed to 11.x. Thanks!

Backported to 10.1.x because the risk of disruption here is zero and this is a bug.

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