Estoy tratando de mostrar todas las propiedades de alquiler, primero por todas las propiedades que no se han alquilado, y luego por todas las propiedades que se alquilan actualmente. Hay un tipo de publicación personalizada 'rent' con meta de publicación personalizada para el precio alquilado (_price_rented) que es una casilla de verificación (devuelve verdadero o falso ... verdadero si se ha alquilado). Necesito cambiar la consulta para mostrar todas las propiedades con las propiedades disponibles (no alquiladas) que aparecen primero y luego las propiedades alquiladas.
Aquí está mi consulta:
$ts_properties = new WP_Query(
array(
'post_type' => 'rent',
'paged' => $paged,
'posts_per_page' => -1,
'meta_key' => '_price_rented',
'orderby' => 'meta_value',
'order' => 'DESC',
'meta_query' => array(
array(
'key' => '_price_rented',
'value' => false,
'type' => 'BOOLEAN',
),
)
)
);
Por alguna razón, esta consulta muestra todas las propiedades que SE HAN alquilado. Cuando cambio el valor de 'falso' a 'verdadero' en meta_query, no muestra ninguna propiedad.
Entonces, pensé, el valor de retorno es falso (para propiedades que SE ALQUILAN) o NULL (para propiedades que NO se alquilan), pero no estoy seguro de cómo consultar un resultado NULL (no falso), agregué un ' compare 'argumento con meta_query y establezca el valor en'! = 'pero tampoco funcionó.
EDITAR: var_dump devuelve lo siguiente para un apartamento disponible, no alquilado: string(0) ""
y para un apartamento no disponible, alquilado:string(1) "1"
fuente
_price_rented
configurado para ambostrue
yfalse
valores, o solo está configurado paratrue
? Consulte la base de datos por favor. Pregunté porque no se pasa ninguna casilla de verificación sin marcar, porPOST
lo que me pregunto si el valor está establecido para esos casos.Respuestas:
WP_Meta_Query
es una parte de alguna manera "no tan estable" en el núcleo y si no prestas mucha atención, puede fácilmente ser confundido.Cuando está haciendo ay
new WP_Query()
tienemeta_query => array()
argumentos o sus pares equivalentes de clave / valor, luegonew WP_Meta_Query()
salta, instantáneamente seguido de análisis.Valores permitidos
Cuando consulta metadatos, entonces hay una
bool
opción. Y si lo usara, entonces recurriría aCHAR
, cuyo valor predeterminado como la matriz de valores permitidos es:donde
NUMERIC
se restablecerá aSIGNED
.Depuración
Existen numerosos filtros que pueden afectar el proceso de guardado posterior, por lo que lo primero que debe hacer es verificar los diferentes valores dentro de algún bucle:
Luego, dependiendo del valor de retorno, deberá usar
SIGNED
, si el resultado es0
o1
,"true"
o"false"
si el resultado es una cadena. Si realmente es booleano, aún sugeriría usarstring
solo para asegurarse de que pase$GLOBALS['wpdb']
, que solo puede pasar%s
cadenas y%d
dígitos.Notas adicionales
Como acabo de ser informado de la entrada del Codex para el
WP_Meta_Query
día de hoy, he visto que hay un montón de diferentes salidas (la adición de numerosas cantidades de que no sean necesariosJOINS
, que se discuten en Tracaquíy aquí confueraun solo parche movido en el núcleo) posible. (Ticket de seguimiento para lasAND
partes aquí ) El punto es que es posible usar una combinación demeta_*
argumentos junto con lameta_query
matriz y sus submatrices. El resultado es bastante desconocido a menos que lo descargue , por lo que en mi humilde opinión , es mejor usar una u otra forma de agregar entradas. Especialmente cuando solo eresutilizandometa_key
, ya que esto da como resultado una "consulta de solo clave" en algunos casos.Solución
Como se señala en los comentarios:
Ahora el
meta_query
tiene que usarSi desea obtener los "apartamentos alquilados no disponibles" o utilizar
'!='
para recuperar los apartamentos "no alquilados".Nota: Los valores posibles para
meta_compare
son'=', '!=', '>', '>=', '<', '<=', 'LIKE', 'NOT LIKE', 'IN', 'NOT IN', 'BETWEEN', 'NOT BETWEEN', 'NOT EXISTS', 'REGEXP', 'NOT REGEXP'
o'RLIKE'
. El valor por defecto es'='
.fuente
Me enfrenté al mismo problema y después de una hora de búsqueda encontré el
"NOT EXISTS"
y"EXISTS"
valor( only in WP >= 3.5 )
. Por lo tanto, no es necesario solicitar un metavalor, solo verifique si existe la meta_key:Me está funcionando perfectamente.
fuente
Más detalles:
Aquí hay dos problemas de representación de datos: uno es qué valores de datos se utilizan para representar verdadero / falso y el otro es si el campo se está almacenando o no si es el valor predeterminado (generalmente falso).
Parte 1: Miré el SQL generado por las
WP_Meta_Query
comparaciones entre verdadero y falso, y descubrí que para verdadero sustituye '1' y falso '' (la cadena vacía). Entonces, lo que escriba en la base de datos debe estar de acuerdo con eso si va a hacer consultas en comparación con los valores reales verdaderos y falsos. En particular, no desea escribir '0' para falso. En su lugar, podría ser más infalible escribir y probar para 0 y 1 (y muchos creadores de formularios lo hacen). Pero verifique lo que se está escribiendo en la base de datos y tenga esto en cuenta al crear su consulta.Parte 2: Suponiendo que falso es el valor predeterminado, es fácil encontrar registros cuyo valor sea verdadero:
... 'meta_key' => 'my_key', 'meta_value' => 1
(o cierto)Pero el otro lado es desafiante: puede haber un valor falso o puede que no haya ningún valor. Esto puede suceder si el valor se incluyó como opcional en un formulario --- entonces, mientras el usuario no lo establezca o lo cambie explícitamente, no se agregará a la base de datos. Tenga en cuenta que si solo lo está utilizando
get_post_meta
, funcionará bien de esta manera: devolver un valor falso y no devolver ningún valor logrará lo mismo.Pero cuando estás usando
WP_Query
, no es tan fácil. (O si es así, aún no he descubierto cómo).Tienes dos (o quizás tres) opciones:
Asegúrese de que el campo siempre se inicializa explícitamente a un valor real. En algunos creadores de formularios, puede hacer esto haciendo que el campo sea obligatorio y dándole un valor predeterminado. Entonces puedes probar de
...'meta_value' => 0
manera confiable.Haga dos consultas, la primera que prueba un valor falso y la segunda que no prueba ningún valor. Estos se pueden combinar en una sola WP_Query como esta:
Probablemente esta no sea una consulta eficiente. Dependiendo de muchos factores, podría ser mejor devolver todos los objetos y filtrarlos en su propio código.
En ese caso, una sola
'NOT EXISTS'
consulta devolverá de forma confiable los objetos correctos. (No creo que muchos creadores de formularios o complementos admitan este comportamiento, por lo que solo lo usaría en código puramente personalizado).fuente