Un altro leggero miglioramento dalla risposta di @sMyles.
Ho avuto casi in cui gli ID sono stati memorizzati sia come stringhe (come quando presi da un input di modulo) sia come numeri interi (ad es update_post_meta($post_id, authorized_users', array(get_current_user_id()));
.). Questo è un po 'come il noto problema con wp_set_object_terms()
cui è possibile utilizzare gli ID termine per impostare i termini, ma se non li si lancia come numeri primi si ha una probabilità del 50% di creare nuovi termini con quei numeri come nomi anziché.
Ciò può comportare che vengano archiviati in modo piuttosto diverso in un array serializzato, come si può vedere dagli estratti di un caso del genere dal database del mio sito di test:
a:1:{i:0;s:1:"1";} // 's' for 'string', also note the double quotes
a:1:{i:0;i:1;} // 'i' for 'integer', no quotes
Entrambi i precedenti, quando alimentati print_r()
renderanno come
Array
(
[0] => 1
)
Per risolvere questo problema, ho apportato una leggera modifica meta_query
all'aggiunta di una relation
e un'altra versione della query che ha lanciato il valore come numero intero anziché come stringa.
Ecco il risultato finale:
'meta_query' => array(
'relation' => 'OR', // Lets it know that either of the following is acceptable
array(
'key' => 'bcm_enm_authorized_users',
'value' => serialize(strval(get_current_user_id())), // Saved as string
'compare' => 'LIKE'
),
array(
'key' => 'bcm_enm_authorized_users',
'value' => serialize(intval(get_current_user_id())), // Saved as integer
'compare' => 'LIKE'
),
),
EDIT: Ho appena realizzato che questo metodo potrebbe correre il rischio di collisioni con indici di array, il che potrebbe consentire a qualcuno di accedere illecitamente ai materiali se non sono nell'array, ma il loro ID utente appare come un indice. Pertanto, mentre questo funziona se si discute del problema, è consigliabile assicurarsi che tutti i valori che si desidera cercare vengano sottoposti a cast come stringhe prima di salvarli in modo da poter utilizzare invece il metodo @sMyles.