Problem/Motivation

PHP 8.1, Drupal 9.3, Webform 6.2.0-beta1 returns

Deprecated function: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\webform_ui\PathProcessor\WebformUiPathProcessor->processOutbound() (line 22 of modules/contrib/webform/modules/webform_ui/src/PathProcessor/WebformUiPathProcessor.php).

CommentFileSizeAuthor
#16 3257109-16.patch756 bytesconnbi
#9 3257109-9.patch1.33 KBjrockowitz
#6 3257109-6.patch802 bytesjrockowitz

Issue fork webform-3257109

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

bletch created an issue. See original summary.

anagomes’s picture

Hi @bletch! Can you provide the steps to reproduce this error?

bletch’s picture

I did not replace strpos with str_contains because it looks like webform is still supporting PHP 7 in this version. If it is not, and you want to use str_contains please let me know and I will update. Apart from that, this is a pretty straightforward check to stop the deprecation notice.

jrockowitz’s picture

Would it be simpler to just make sure the query string is not NULL?

$query_string = $request->getQueryString() ?? '';

jrockowitz’s picture

Status: Active » Needs review
StatusFileSize
new802 bytes

This might be the simplest approach.

bletch’s picture

I prefer not doing the multiple null checks as I find it less elegant. I also renamed $querystring as it is not a string but an array. Small detail but just improvements in readability (at least from my perspective). Everyone has different opinions on this though, so module maintainers should do whatever they feel is most appropriate for their modules.

murilohp’s picture

Hey @jrockowitz first time here, and giving my two cents on this. Your patch is definitely a simplest approach, I would actually suggest something like:

if (strpos((string) $request->getQueryString(), '_wrapper_format=') === FALSE) {

Looking deeper at the Request component on SF, the getQueryString() method will always return NULL or string, this way we just cast it and it will be ''. But I'm also ok with the solution on #6.

About #7, I agree with @bletch about renaming the $querystring, it's the best for keeping things consistent. But I don't think this is part of the scope of the issue, I know it's something minor, but the idea here is fix the deprecation message. I think IMHO, we should create a new issue to address this.

What do you think?

jrockowitz’s picture

Version: 6.2.0-beta1 » 6.1.x-dev
StatusFileSize
new1.33 KB

I think exiting \Drupal\webform_ui\PathProcessor\WebformUiPathProcessor::processOutbound as early as possible is the best solutions.

Renaming $querystring to just $query makes sense and aligns with Drupal core's use of $query.

murilohp’s picture

Status: Needs review » Reviewed & tested by the community

No worries @jrockowitz! The patch looks good and $query seems to be the best naming option.

  • jrockowitz authored 3cff1c9 on 6.1.x
    Issue #3257109 by bletch, jrockowitz: Deprecated function: strpos():...
jrockowitz’s picture

Status: Reviewed & tested by the community » Fixed

  • jrockowitz authored 3cff1c9 on 6.x
    Issue #3257109 by bletch, jrockowitz: Deprecated function: strpos():...

  • jrockowitz authored 3cff1c9 on 6.2.x
    Issue #3257109 by bletch, jrockowitz: Deprecated function: strpos():...

Status: Fixed » Closed (fixed)

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

connbi’s picture

StatusFileSize
new756 bytes
joseph.olstad’s picture

Patch #16 is good, this is needed @jrockowitz

nathan tsai’s picture

Getting dozens of:

Deprecated function: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\webform_ui\PathProcessor\WebformUiPathProcessor->processOutbound() (line 22 of

Just applied the patch and it appears to fix the issue.

One question: should the check simply be falsey or something like !empty($path) or !is_null($path).

camilo.escobar’s picture

This was an issue until version 6.1.4, where the patch in #16 had to be applied. Updating to 6.1.5 will solve this problem and the patch will not be necessary, since the same issue was tackled with a different approach in https://www.drupal.org/project/webform/issues/3333461 and https://www.drupal.org/project/webform/issues/3344996.