Make WordPress Core

Opened 12 months ago

Last modified 11 months ago

#48242 new enhancement

Deprecate wp_parse_url() in favour of native parse_url()

Reported by: johnbillion Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.2
Component: General Keywords: needs-patch needs-unit-tests
Focuses: coding-standards Cc:


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.

Change History (4)

#1 @afragen
12 months ago

Yes, please.

#2 @ayeshrajans
12 months ago

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.

#3 @ayeshrajans
12 months ago

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.

#4 @dd32
11 months ago

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.

Note: See TracTickets for help on using tickets.