[wp-trac] [WordPress Trac] #41083: IP with port number triggers warnings in WP_Community_Events

WordPress Trac noreply at wordpress.org
Wed Aug 30 21:48:26 UTC 2017


#41083: IP with port number triggers warnings in WP_Community_Events
--------------------------------------+-----------------------------
 Reporter:  EatonZ                    |       Owner:  iandunn
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  4.9
Component:  Administration            |     Version:  4.8
 Severity:  normal                    |  Resolution:
 Keywords:  good-first-bug has-patch  |     Focuses:  administration
--------------------------------------+-----------------------------

Comment (by iandunn):

 Nevermind, I missed that `parse_url()` doesn't handle IPv6 addresses that
 don't contain port numbers. We could add support for that to
 `wp_parse_url()`, but that doesn't seem like a good idea, since I think
 the intention of functions like those  is really just only to smooth out
 compatibility issues between PHP versions, not extend PHP's functionality.
 I could be wrong there, though.

 `filter_var()` would be nice because it's the most reliable way to parse
 IPs, but it's typically avoided in Core because the PHP extension can be
 disabled. It might be ok in this case if there weren't an alternative,
 because in this situation we can fallback gracefully, by short-circuiting
 geolocation and letting the user manually enter an address. I think I
 found an alternative approach, though.

 Since we really only need to know if the input is formatted as an IPv4
 address or an IPv6 address, we can use a quick and dirty method, like in
 [attachment:41083.2.diff].

 Another idea would be to update `WP_Http::is_ip_address()` to support port
 numbers, but that could turn into a rabbit hole with  unintended
 consequences, especially since it's outside the class (by the REST API and
 plugins).

 Yet another idea would be using `@` to suppress the warnings, but that's
 pretty hacky, and could unintentionally hide errors that we'd want to fix.

 So, I'm left thinking that the approach in [attachment:41083.2.diff] might
 be the least-bad one. I'm leery of adding so much code just to do
 something that seems as simple as stripping off a port number, though.

 Does anyone see a more elegant solution?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/41083#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list