Contexto :
Temos o Domain Access instalado em um site Drupal 7 e temos 8 subdomínios diferentes, todos com temas diferentes e lógicas de negócios ligeiramente diferentes. Dependemos muito do acesso ao domínio para determinar quais nós têm permissão para mostrar em qual subdomínio.
Especificamente para nossa implementação, nos beneficiamos dos seguintes recursos de Acesso ao Domínio que se tornam disponíveis ao criar / editar um nó:
- Publicar em – caixas de seleção para selecionar quais domínios têm acesso a um nó específico.
- Domínio de origem – definido como “Usar domínio ativo” ou como um subdomínio específico. Vamos decidir se a visualização em um nó em um subdomínio deve redirecionar para um diferente, ou se você pode apenas visualizá-lo no subdomínio atualmente acessado.
Problema e solução :
parece que, quando importamos um monte de nós de um tipo específico (~ 1000), os dados não eram perfeitos e o “domínio de origem” para alguns desses nós foi definido como um subdomínio específico quando era suposto para ser definido como “Usar domínio ativo” para todos eles.
É claro que não temos idéia de quantos nós estão configurados incorretamente até que possamos escrever uma consulta inteligente para descobrir ou verificá-la manualmente (mas ninguém faz isso). Se o número for alto (que acabou sendo 103 de 1013), não queremos ter que apontar manualmente, clicar e salvar para alterar todas essas configurações para cada nó. Em vez disso, gostaríamos de escrever um gancho de atualização para consultar todos os nós desse tipo que têm o valor incorreto definido para o domínio de origem e atualizá-lo para o desejado.
Dado que este é o Drupal 7, e eu gosto de ser o mais elegante possível, decidi usar EntityFieldQuery (uma classe Drupal incrível que você pode usar para escrever mySQL, mas sem realmente ter que escrevê-la). De agora em diante, irei me referir a ele como EFQ para ser sucinto.
Ia usar EFQ para capturar todos os nós de um tipo específico onde o campo domain_source NÃO está definido como -5 (o valor inteiro que representa o valor “usar domínio ativo”) e, em seguida, definir esse valor como -5.
Tim Cosgrove, da Treehouse Agency, escreveu um artigo muito útil sobre os blocos de construção da EFQ, que foi um dos meus recursos para aprender como fazê-lo. Achei que o seguinte funcionaria de acordo com a API Drupal :
$query->entityCondition('entity_type', 'node')->entityCondition('bundle', 'my_node_type_name')->fieldCondition('domain_source', 'domain_id', '-5', '=')->execute();Ele gerou alguns erros fatais que não foram realmente úteis para determinar a causa e meu depurador / rastreamento de pilha também não forneceu informações úteis.
Infelizmente, depois de muita pesquisa dolorosa e conversas com meus colegas, parece que o EFQ só pode interagir com campos “padrão” do Drupal e porque o Domain Access adiciona uma tabela no banco de dados chamada ” fonte de domínio ” em vez da maneira padrão que outros campos são implementados no banco de dados (como ** nome do campo **), EFQ não consegue encontrá-lo.
Acabei realizando minha consulta de uma maneira um pouco menos elegante usando a classe SelectQuery padrão , mas ainda funciona bem:
$query = db_select('node', 'n');
$query->innerJoin('domain_source', 'd', 'n.nid = d.nid');
$query->addField('n', 'nid');
$query->addField('n', 'type');
$query->addField('d', 'domain_id');
$query->condition('n.type', 'my_node_type_name', '=');
$query->condition('d.domain_id', '-5', '!=');
$result = $query->execute();Próximas etapas :
vou revisar a fila de problemas de acesso ao domínio e ver se há algum problema pendente relacionado a isso, ou talvez eu esteja apenas fazendo errado e já é possível.
Se alguém souber como fazer isso usando EFQ, por favor me avise. Caso contrário, posso considerar descobrir se um patch pode ser lançado para o acesso ao domínio ou para o núcleo que pode resolver isso.