Make WordPress Core

Opened 4 months ago

Last modified 2 months ago

#52235 new defect (bug)

wp_extract_urls doesn't match localhost

Reported by: seanleavey Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.6
Component: General Keywords: has-patch
Focuses: Cc:


The wp_extract_urls function does not match URLs with localhost as the domain:

// Matches.
wp_extract_urls("<a href=\"http://localhost.com:8889/?p=9\">hi</a>");

// Doesn't match.
wp_extract_urls("<a href=\"http://localhost:8889/?p=9\">hi</a>");

I think this function should definitely match localhost because this is often used in testing environments. But if this is intended behaviour, then the documentation makes no mention that this function only matches a subset of allowed URLs.

Change History (3)

#1 @seanleavey
4 months ago

This may also be related, but it seems that WordPress's testing bootstrap doesn't set the home_url() to the contents of the constant WP_TESTS_DOMAIN, so new posts created by e.g. $this->factory->post->create() inside unit tests have their permalink set to localhost (or presumably whatever the default is for the platform). This means that creating a post in a test with post_content set to contain a link to another post (retrieved via get_permalink( $other_post )), then running wp_extract_urls on its content, results in an array that doesn't contain the other post's URL.

Actually this was a problem on my end (the stuff immediately above, not the original issue).

Last edited 4 months ago by seanleavey (previous) (diff)

This ticket was mentioned in PR #1071 on WordPress/wordpress-develop by tikifez.

2 months ago

Patch in response to "#52235 (wp_extract_urls doesn't match localhost)" at https://core.trac.wordpress.org/ticket/52235

Adds matching to strings without a dot in the initial chunk so it now matches strings like "localhost" and "http://localhost:8888".

I found that my initial solution caused unit tests for _doEnclose.php_ to fail, so it also matches strings with an opening slash like "/path/to/file" but not "path/to/file" to avoid misidentifying strings like "red/green".

#3 @tikifez
2 months ago

  • Keywords has-patch added

Tagging with has-patch

Note: See TracTickets for help on using tickets.