Outra pequena melhora em relação à resposta do @sMyles.
Eu tive casos em que os IDs foram armazenados como seqüências de caracteres (como quando extraídos de uma entrada de formulário) e como números inteiros (por exemplo update_post_meta($post_id, authorized_users', array(get_current_user_id()));
). Esse é o problema conhecido em wp_set_object_terms()
que você pode usar IDs de termo para definir os termos, mas se você não os converter como números inteiros, terá 50% de chance de criar novos termos com esses números como seus nomes. em vez de.
Isso pode resultar no armazenamento diferenciado em uma matriz serializada, como pode ser visto nos trechos de um caso desse no banco de dados do site de teste:
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
Ambos os itens acima, quando alimentados print_r()
, renderizam como
Array
(
[0] => 1
)
Para corrigir isso, fiz um pequeno ajuste no meta_query
adicionando uma relation
e outra versão da consulta que convertia o valor como um número inteiro em vez de uma string.
Aqui está o resultado final:
'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: Acabei de perceber que esse método poderia correr o risco de colisões com índices de matriz, o que poderia permitir a alguém acesso ilícito a materiais se eles não estiverem na matriz, mas seu ID de usuário aparece como um índice. Dessa forma, embora isso funcione se você tiver o problema discutido, a melhor prática é garantir que quaisquer valores que você deseja procurar sejam convertidos em seqüências de caracteres antes de salvá-los, para que você possa usar o método @sMyles '.