Making WordPress.org

Changeset 6179


Ignore:
Timestamp:
11/27/2017 08:47:41 PM (7 years ago)
Author:
iandunn
Message:

Events: Remove dead code for fuzzy locations because no longer needed.

File:
1 edited

Legend:

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

    r6078 r6179  
    150150        $events = add_regional_wordcamps( $events, $_SERVER['HTTP_USER_AGENT'] );
    151151
    152         /*
    153          * There are two conditions which can cause a location to not have a description:
    154          * 1) When the request only passed latitude/longtude coordinates. We don't lookup
    155          *    a location here because it's too expensive. See r5497.
    156          * 2) When the location was determined by geolocating the IP. We don't return the
    157          *    location here because it would violate the ip2location EULA. See r5491.
    158          *
    159          * For WP 4.8-beta1 those conditions were handled by setting "fuzzy" locations
    160          * instead; the location of the first upcoming event was used, since it will be
    161          * within driving distance of the location that was geolocated.
    162          *
    163          * After beta1 was released, though, there was a lot of feedback about the locations
    164          * being too inaccurate, so we're going to try a different approach for beta2. See
    165          * #40702-core.
    166          *
    167          * @todo Update the user-agent strings if 40702-geoip.2.diff doesn't make it into beta2
    168          * @todo Remove this back-compat code after 4.8.0 has been out for a few days, to avoid
    169          *       impacting the feature plugin in 4.7 installs. rebuild_location_from_event_source()
    170          *       can probably be removed at that time too.
    171          */
    172         $use_fuzzy_locations = false !== strpos( $_SERVER['HTTP_USER_AGENT'], '4.7' ) || false !== strpos( $_SERVER['HTTP_USER_AGENT'], '4.8-beta1' );
    173         if ( $use_fuzzy_locations ) {
    174             if ( empty( $location['description'] ) || ( isset( $location['internal'] ) && $location['internal'] ) ) {
    175                 $location = rebuild_location_from_event_source( $events );
    176             }
    177         } elseif ( isset( $location['internal'] ) && $location['internal'] ) {
     152        // Internal location data cannot be exposed in the response, see get_location().
     153        if ( isset( $location['internal'] ) && $location['internal'] ) {
    178154            // Let the client know that a location was successfully determined based on their IP
    179155            $location = array( 'ip' => $location_args['ip'] );
     
    418394
    419395/**
    420  * Rebuild the location given to the client from the event source data
    421  *
    422  * We cannot publicly expose location data that we retrieve from the `ip2location` database, because that would
    423  * violate their licensing terms. We can only use the information internally, for the purposes of completing the
    424  * program's business logic (determining nearby events).
    425  *
    426  * Once we have nearby events, though, we can take advantage of the data that's available in the `wporg_events` table.
    427  * That table contains the locations details for the event's venue, which was sourced from the respective APIs
    428  * (WordCamp.org, Meetup.com, etc). We can return the venue's location data without violating any terms.
    429  *
    430  * See https://meta.trac.wordpress.org/ticket/2823#comment:15
    431  * See https://meta.trac.wordpress.org/ticket/2823#comment:21
    432  *
    433  * This isn't ideal, since the location it picks is potentially an hour's driving time from the user. If we get a
    434  * lot of complaints, we could potentially change this to search the `geonames` database for the name of the city
    435  * that was returned by the `ip2location` database. That should be more accurate, but it would require an extra
    436  * database lookup, and could potentially fail to return any results.
    437  *
    438  * @param array $events
    439  *
    440  * @return array|false
    441  */
    442 function rebuild_location_from_event_source( $events ) {
    443     $location = false;
    444 
    445     foreach ( $events as $event ) {
    446         if ( ! empty( $event['location']['location'] ) && ! empty( $event['location']['latitude'] ) ) {
    447             $location = $event['location'];
    448             $location['description'] = $location['location'];
    449             unset( $location['location'] );
    450 
    451             /*
    452              * If the event is a WordCamp, continue searching until a meetup is found. Meetups have a much smaller
    453              * search radius in `get_events()`, so they'll be closer to the user's location. Some cities will only
    454              * have WordCamps scheduled at the moment, though, so we can fall back to those.
    455              */
    456             if ( 'meetup' === $event['type'] ) {
    457                 break;
    458             }
    459         }
    460     }
    461 
    462     return $location;
    463 }
    464 
    465 /**
    466396 * Determine a location for the given parameters
    467397 *
     
    554484                'longitude'   => $guess->ip_longitude,
    555485                'country'     => $guess->country_short,
    556                 'internal'    => true, // this location cannot be shared publicly, see `rebuild_location_from_geonames()`
     486
     487                /*
     488                 * ip2location's EULA forbids exposing the derived location publicly, so flag the
     489                 * data for internal use only.
     490                 */
     491                'internal' => true,
    557492            );
    558493        }
Note: See TracChangeset for help on using the changeset viewer.