Regression: Type error in views with view of nodes

[indigoxela]

Description of the bug

As I already suspected: some added type hints might cause trouble.
Follow up to coding standard fixes in core/includes/c* (common.inc)

Steps To Reproduce

1. Generate a bunch of nodes with devel
2. Create a view of teasers but suppress link display
3. Save it and try to preview or visit the page

Actual behavior

TypeError: hide(): Argument #1 ($element) must be of type array, null given, called in .../core/modules/node/templates/node.tpl.php on line 109 in hide() (line 7261 of ...core/includes/common.inc).

hide(): Argument #1 ($element) must be of type array, null given, called in ...core/modules/node/templates/node.tpl.php on line 109 

The view (page) is broken.

Expected behavior

No type error.

Additional information

Add any other information that could help, such as:

• Backdrop CMS version: latest dev
• PHP version: 8.5

Caused by Issue: #7031: Coding standards - core/includes/c* - merged only recently, so not released, yet.

PR was: backdrop/backdrop#5170

We need to fix doc block and type hint. Element can be null (in this case caused by calling hide() in a template in combination with suppressed links).

[indigoxela]

Here's a PR that fixes the immediate problem by making $element optional. We could also remove the type hint completely. What do you think @herbdool - to hint or not to hint?

[argiepiano]

Is this issue happening with the current dev version of BAckdrop? I can't reproduce following these steps. I'm testing with PHP 8.3 and all errors enabled. There are no errors in the log either.

EDIT:

OK, saving the view did not produce an error, BUT I'm seeing that fatal error when visiting the view page. Confirmed.

[argiepiano]

The patch solved the issue for me. WFM.

[herbdool]

So that works, but I am too wondering if we should be even more cautious here, like @indigoxela mentioned. I already had to take the type declaration off of render(&$element) since it could be either an array or string (and maybe null?). So could hide(&$element) also get a string? If so let's just remove the type declaration.

[indigoxela]

If so let's just remove the type declaration.

@herbdool I didn't find any evidence, that element could be a string anywhere in core. But I agree, let's be extra cautious here to not break contrib or custom code. Especially as the PR went into both, 1.x and 1.32.x. Type hint removed.

@argiepiano I clarified the STR in issue description, as they were a bit ambiguous.

[herbdool]

In my testing $element could be a string when passed to render() so it might be possible with hide() too.