[wp-meta] [Making WordPress.org] #2823: Improve IP Geolocation Results

[Making WordPress.org]

#2823: Improve IP Geolocation Results
---------------------+-----------------------
 Reporter:  iandunn  |       Owner:  iandunn
     Type:  defect   |      Status:  accepted
 Priority:  normal   |   Milestone:
Component:  API      |  Resolution:
 Keywords:           |
---------------------+-----------------------

Comment (by iandunn):

 Replying to [comment:12 barry]:
 > 1) The ip2location data on WP.org is very very old.
 > 2) WP.org doesn't have a subscription/license to use the data
 > 3) I don't think there is any legitimate use case to pass an ip in the
 query string
 > 4) The query performance is very poor and probably won't scale to the
 volume that we need
 > 5) We need a way to keep the information always current if we are going
 to use it

 !#1, !#2, and !#5 are all easy to solve.

 == !#3 (EULA) ==
 On a technical level, it's easy to switch the client to request the data
 directly from api.w.org instead of proxying through their WP site.

 For anyone who's concerned about privacy with that architecture, we can
 release a plugin that will disable the Events section of the Dashboard
 widget entirely. We could replace it with a simple link to
 [https://make.wordpress.org/community/events/ the Events page on
 make/Community].

 Does anyone think that would not be enough to mitigate privacy concerns?


 == !#4 (performance) ==

 I'm going to start digging into this and looking for ways to optimize. If
 you can say which queries you're concerned the most about, that would be
 helpful.

 Almost all of the queries are there to support extra functionality and
 edge cases. Worst case scenario, the queries in the following functions
 can all be disabled without preventing the majority of users from
 successfully retrieving events: `guess_location_from_ip()`,
 `guess_location_from_geonames_fallback()`, `get_valid_country_codes()`,
 `get_country_from_name()`, and `get_city_from_coordinates()`

 That can be done at-will on the API side without breaking the client in
 Core. We could even do it automatically during traffic spikes if we have
 some kind of signal from monitoring agents to check.

--
Ticket URL: <https://meta.trac.wordpress.org/ticket/2823#comment:15>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org