web-dev-qa-db-fra.com

Méta-requête facultative

J'ai des lieux stockés sous forme de posts dans la table des posts de WP.

Je fais un peu de géolocalisation en utilisant Geo Data Store ( http://wordpress.org/plugins/geo-data-store/ ). Cela fonctionne très bien pour moi, car je peux actuellement obtenir les résultats de n’importe quel rayon que je choisis à partir d’un point de départ (une ville convertie en coordonnées).

J'utilisais auparavant une correspondance exacte sur la ville - lorsqu'un utilisateur cliquait sur une ville, il chargeait les résultats avec des publications qui tenaient postmeta correspondant exactement à la ville sélectionnée - je clique sur Asheville, des lieux se trouvent à Asheville.

Le problème posé par le passage à la géolocalisation est que maintenant, lorsqu'un utilisateur clique sur une ville, certains résultats de cette ville ne sont pas affichés car ils ne se trouvent pas dans le rayon donné du centre-ville, même si postmeta est exactement le même. ville cliquée.

La partie pertinente de ma requête ressemble à ceci:

$coordinates = ConvertCityStateToCoords($city.', '.$state);
$lat = (double)$coordinates['lat'];
$long = (double)$coordinates['long'];
$posts = (array) $geoDataStore->getPostIDsOfInRange('place', $radius, $lat, $long);
$posts = array_map('intval',$posts);
$args['post__in']=$posts;
$places= new WP_Query($args);

Alors que ça ressemblait à ça:

$args['meta_query'][] = array(
    'key' => 'place_state',
    'value' => $state,
);
$args['meta_query'][] = array(
    'key' => 'place_city',
    'value' => $city
);
$places= new WP_Query( $args );

Ma question est la suivante: devrai-je abandonner WP_Query (ce que je préférerais ne pas faire car je l'utilise également pour la pagination et la commande) en faveur de SQL qui me permettra d’interroger un champ 'optionnel' - SQL qui inclurait des posts dans le rayon ainsi que des posts avec la ville exacte, mais pas exclusivement l’un ou l’autre.

1
Josh Levinson

Tout le travail réel ici est effectué par $geoDataStore->getPostIDsOfInRange. C'est là que la recherche est effectuée et c'est ce qui ne donne pas les résultats souhaités.

WP_Query extrait simplement la publication spécifiée IDs. Il n'y a aucune raison pour que vous deviez abandonner cette partie du code, bien que vous souhaitiez peut-être ajouter 'orderby' => 'posts__in' pour conserver l'ordre du post IDs transmis à la requête.

Si $geoDataStore->getPostIDsOfInRange ne renvoie pas toutes les IDs que vous voulez, vous devrez examiner comment cela fonctionne.

Maintenant, cela ressemble au code que votre classe $geoDataStore utilise pour effectuer la requête. Il n'y a pas de crochets que vous pourriez manipuler.

Il n'y a que deux choses auxquelles je peux penser.

  1. Étendez cette classe et remplacez cette fonction afin qu'elle recherche vos méta-informations.
  2. Ou exécutez une autre requête pour vérifier vos méta-informations et inclure les endroits situés en dehors du rayon généré , comme ceci .

En d'autres termes...

$posts = (array) $geoDataStore->getPostIDsOfInRange('place', $radius, $lat, $long);
$posts2 = new WP_Query(array(
  // query for the others
  'fields' => 'ids',
  // other parameters
  // Much like your original meta_query but
  // I do think you need the 'OR' relationship
));
$posts = array_unique($posts + $posts2);
$args['post__in'] = $posts;
$places = new WP_Query($args);
1
s_ha_dum

Vous devez déclarer une relation OR entre les requêtes, car AND est la valeur par défaut.

Exemple tiré de http://codex.wordpress.org/Class_Reference/WP_Query#Custom_Field_Parameters

$args = array(
    'post_type' => 'product',
    'meta_query' => array(
        'relation' => 'OR',
        array(
            'key' => 'color',
            'value' => 'blue',
            'compare' => 'NOT LIKE'
        ),
        array(
            'key' => 'price',
            'value' => array( 20, 100 ),
            'type' => 'numeric',
            'compare' => 'BETWEEN'
        )
    )
);
0
GhostToast