Deprecate wp_parse_url() in favour of native parse_url()

[johnbillion]

The wp_parse_url() function exists to handle inconsistencies in the return value of PHP's native parse_url() function across different versions of PHP.

According to its inline docs:

PHP 5.4.7 expanded parse_url()'s ability to handle non-absolute url's, including schemeless and relative url's with :// in the path. This function works around those limitations providing a standard output on PHP 5.2~5.4+.

Error suppression is used as prior to PHP 5.3.3, an E_WARNING would be generated when URL parsing failed.

Now that core only supports PHP 5.6+, it should be possible to deprecate this function and replace usage of it with the native parse_url() function. However, to ensure that nothing breaks we'll need tests which determines that parse_url() functions identically to wp_parse_url() on PHP 5.6 and above.

[afragen]

Yes, please.

[ayeshrajans]

A couple weeks ago, I did try to short-circuit wp_parse_url() by immediately passing it to parse_url(). (​https://github.com/Ayesh/wordpress-develop/commit/7cf2ad95c260).

One test fails in PHP 5.6 and 5.6 alone: ​https://travis-ci.org/Ayesh/wordpress-develop/jobs/587819504#L2697

I suppose we need the same tests passed (which would be a BC otherwise), plus some extra tests to make sure the error suppression has gone away. I will work on patches in coming days.

[ayeshrajans]

The PHP 5.6 test failure is because until PHP 7.0.22, PHP detected a colon in the query string as a port number. See ​https://bugs.php.net/bug.php?id=74780.

[dd32]

I would highly suggest against deprecating wp_parse_url() but would be in favour of removing any older PHP workarounds it contains.

It seems highly likely that there'll be cases that need working around or filling in in the future too, based on history, and also the potential for security implications in URL parsing in the future.

[johnbillion]

Good points above. If there are PHP bugs that wp_parse_url() doesn't currently account for, please open s ticket!

[Cybr]

This function was added because of a bug in PHP, and plugin developers are now compelled to implement this useless method because of Plugin Check (as is wp_json_encode()).

If we'd like to keep this function because of the slippery slope fallacy that a bug will happen because there used to be one, then I recommend adding a companion function for everything in PHP. /s

It's never too late to clean up after oneself.