PHP 8.4 | WP_HTML_Processor: fix implicitly nullable parameter [1]

PHP 8.4 deprecates implicitly nullable parameters, i.e. typed parameters with a null default value, which are not explicitly declared as nullable.

This commit the one instance of this in the WP_HTML_Processor class.

Fixed by adding the nullability operator to the type, which is supported since PHP 7.1, so we can use it now the minimum supported PHP version is PHP 7.2.

As this deprecation is thrown at compile time, it can be seen at the top of the test output when running on PHP 8.4 (which will be gone once this change has been committed). It is not possible to write a test to cover this.

Ref: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types

PHP 8.4 | Tests_HtmlApi_WpHtmlProcessorComments: fix implicitly nullable parameters [2]

PHP 8.4 deprecates implicitly nullable parameters, i.e. typed parameters with a null default value, which are not explicitly declared as nullable.

The Tests_HtmlApi_WpHtmlProcessorComments test class contains one problematic parameter in the test_comment_processing() method declaration.

While this could be fixed by adding the nullability operator, I've elected not to do this, but to remove the type declarations in the test method instead, including other type declarations for this method and the second test method, which were not affected by the deprecation.

The reason for this is quite straight-forward: using type declarations in tests is bad practice and inhibits defense-in-depth type testing.

Using type declarations in tests prevents being able to test the "code under test" with unexpected input types as the values with unexpected (scalar) types will be juggled to the expected type between the data provider and the test method and the real data value would therefore never reach the method under test.

The knock-on effects of this are:

• That the input handling of the "code under test" can not be safeguarded, whether this input handling is done via in-function type checking or via a type declaration in the "code under test".
• That if such "unexpected data type" tests are added to the data provider, they will silently pass (due to the type being juggled before reaching the "code under test"), giving a false sense of security, while in actual fact, these data sets would not be testing anything at all and if, for instance, the type declaration in the "code under test" would be removed, these tests would still pass, while by rights they should start failing.

Also note that this problem would only be exacerbated if the file would be put under strict_types.

Ref: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types

Trac ticket: https://core.trac.wordpress.org/ticket/62061

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.