Making WordPress.org


Ignore:
Timestamp:
05/18/2017 05:54:12 AM (8 years ago)
Author:
iandunn
Message:

Events: Stop using fuzzy locations for 4.8-beta2

See #2823

File:
1 edited

Legend:

Unmodified
Added
Removed
  • sites/trunk/api.wordpress.org/public_html/events/1.0/index.php

    r5497 r5499  
    2323    $location_args = parse_request();
    2424    $location      = get_location( $location_args );
    25     $response      = build_response( $location );
     25    $response      = build_response( $location, $location_args );
    2626
    2727    send_response( $response, $ttl );
     
    9999 *
    100100 * @param array $location
     101 * @param array $location_args
    101102 *
    102103 * @return array
    103104 */
    104 function build_response( $location ) {
     105function build_response( $location, $location_args ) {
    105106    $events = array();
    106107
     
    125126        $events = get_events( $event_args );
    126127
    127         if ( empty( $location['description'] ) || ( isset( $location['internal'] ) && $location['internal'] ) ) {
    128             $location = rebuild_location_from_event_source( $events );
    129         }
    130     }
    131 
    132     if ( false === $location ) {
     128        /*
     129         * There are two conditions which can cause a location to not have a description:
     130         * 1) When the request only passed latitude/longtude coordinates. We don't lookup
     131         *    a location here because it's too expensive. See r5497.
     132         * 2) When the location was determined by geolocating the IP. We don't return the
     133         *    location here because it would violate the ip2location EULA. See r5491.
     134         *
     135         * For WP 4.8-beta1 those conditions were handled by setting "fuzzy" locations
     136         * instead; the location of the first upcoming event was used, since it will be
     137         * within driving distance of the location that was geolocated.
     138         *
     139         * After beta1 was released, though, there was a lot of feedback about the locations
     140         * being too inaccurate, so we're going to try a different approach for beta2. See
     141         * #40702-core.
     142         *
     143         * @todo Update the user-agent strings if 40702-geoip.2.diff doesn't make it into beta2
     144         * @todo Remove this back-compat code after beta2 has been out for a few days
     145         */
     146        $use_fuzzy_locations = false !== strpos( $_SERVER['HTTP_USER_AGENT'], '4.7' ) || false !== strpos( $_SERVER['HTTP_USER_AGENT'], '4.8-beta1' );
     147        if ( $use_fuzzy_locations ) {
     148            if ( empty( $location['description'] ) || ( isset( $location['internal'] ) && $location['internal'] ) ) {
     149                $location = rebuild_location_from_event_source( $events );
     150            }
     151        } elseif ( isset( $location['internal'] ) && $location['internal'] ) {
     152            // Let the client know that a location was successfully determined based on their IP
     153            $location = array( 'ip' => $location_args['ip'] );
     154        }
     155    } else {
    133156        $error = 'no_location_available';
    134157    }
Note: See TracChangeset for help on using the changeset viewer.