Base de dados
É possível fazer muitas coisas no Drupal simplesmente fazendo consultas SQL, seja através do Drupal ou externamente. Geralmente, você nunca deseja adotar essa abordagem. Em alguns casos, ele pode funcionar bem, mas na maioria das vezes não há motivos para fazê-lo dessa maneira.
API
O Drupal possui uma API rica, isso é verdade para o Drupal 6, 7 e 8, pois sempre foi um recurso importante no Drupal. No seu exemplo de concreate, você pode usar taxonomy_term_loade taxonomy_term_savefacilitar uma atualização de um termo. Fazendo dessa maneira, você pode editar qualquer parte dos dados, incluindo o vid. Só porque você faz isso com a API, fazendo coisas proibidas não funcionará automaticamente, mas a chance de as coisas correrem bem é drasticamente melhorada.
Neste exemplo concreto, a API não faz o necessário. Ele define alguns dados internos sobre o termo e chama o módulo de letra de ganchos, que sabe que foi atualizado.
Você deve observar que as coisas podem quebrar, se o termo que você deseja alterar fizer parte de uma hierarquia. As coisas também podem ser interrompidas para nós que referenciam o termo, se o campo não puder fazer referência a termos no novo vocabulário.
Migração
A migração de dados é a solução à prova de balas e, a menos que você tenha um grande conjunto de dados, ele pode ser desenvolvido e executado com bastante facilidade. A idéia é criar um novo termo e migrar o conteúdo que você deseja migrar e excluir o termo antigo. Como um gancho de atualização, o código de exemplo pode ficar assim:
/**
* Put in modules .install file, replace xxxx with 7000 or higher
*/
function MODULE_NAME_update_XXXX(&$sandbox) {
$term = taxonomy_term_load(CONSTANT_WITH_TID);
$new_term = clone $term;
unset($new_term->tid);
unset($new_term->tid);
$new_term->vid = CONSTANT_WITH_VID;
taxonomy_term_save($term);
// Find all nodes we want to update and update them.
// If there is a lot of nodes, can use $sandbox to make this a batch job.
$query = new EntityFieldQuery();
$query->entityCondition('entity_type', 'node')
->fieldCondition('field_which_is_term_reference', 'tid', $term->tid);
$result = $query->execute();
foreach (node_load_multiple(array_keys($result['node'])) as $node) {
$node->field_which_is_term_reference[LANGUAGE_NONE][0]['tid'] = $term->tid;
node_save($node);
}
// Migration all done - delete the old term.
taxonomy_term_delete($term->tid);
}
Observe que o código acima é um exemplo de código puro, escrito de cor. Pode ter erro de sintaxe ou outros erros e faz muitas suposições. Isso é apenas para ilustrar uma idéia e demonstrar que uma migração pode não ser um grande problema.
Eu não recomendaria alterar esse termo da maneira que você o descreveu em sua pergunta. Em vez disso, usaria uma abordagem alternativa para obter um resultado semelhante (na ordem especificada), que é mais detalhada abaixo.
Etapa 1 - Comece a usar o novo termo em futuras atualizações de nós
Crie um novo campo de termo de taxonomia, para que "a partir de agora" quaisquer atualizações futuras do nó (ou novos nós sendo criados) usem esse novo campo. Suponho que esses termos sejam usados para nós (se você usá-lo para algum outro tipo de entidade, como usuários, etc.), a mesma abordagem também poderá ser usada para essas entidades.
Use o módulo Rules para criar uma regra assim:
before saving content.entity has field, com campo = o campo antigo.entity has field, com campo = o novo campo).set Drupal messageque contém algumas instruções de que o campo antigo deve ser apagado e o novo campo deve conter os valores apropriados.Etapa 2 - Use as Regras para acelerar o processo
Obviamente, a abordagem na Etapa 1 levará "algum" tempo se isso tiver que ser feito manualmente, 1 nó por vez. Mas, usando o Views (para criar uma lista de nós semelhantes a serem atualizados) e o VBO (para atualizar em massa essas listas), você pode (deve!) Acelerar o processo um pouco.
Especialmente se você usasse o Rules para criar uma operação em massa personalizada para essa visualização VBO, conforme explicado na resposta a " Como usar o Rules para criar uma operação em massa personalizada para uma visualização VBO? ". Aqui está um protótipo de um componente de regras que deve ajudar a implementar essa operação em massa personalizada (no formato de exportação de regras):
Mais alguns detalhes para explicar o protótipo acima:
Estas são as condições das regras:
field_sample_tags.field_demo_tags.field_demo_tagscorresponde ao termo que queremos substituir (neste exemplo, o termo tem id =1). Observe que, se essa condição não for atendida, nenhuma ação de regra será executada.Estas são as ações de regras:
field_sample_tagsigual ao termo com o termo id =31(que é o termo no vocabulário recém-criado que corresponde ao termo no vocabulário a ser substituído).Term updated in node with id = 72, considerando que72é o ID do nó atualizado.Se desejar, adapte os nomes de máquina dos nomes de campo no protótipo acima e os IDs de termo usados. Em seguida, importe-o em seu próprio site (usando a UI de regras) e faça o controle de qualidade usando o link "execute" à direita do Componente de regras importado (e insira um ID de nó para testá-lo, depois de mudar para "entrada direta" mode "para poder especificar um ID do nó). Se durante o teste você não receber essa
Term updated in node ...mensagem, deve ser porque o nó selecionado não usou o valor do termo especificado em suas regras Condição.Etapa 3 - use o VBO como toque final
Depois de concluir o teste de controle de qualidade deste componente de regras da Etapa 2, crie uma visualização VBO dos nós a serem processados, na qual você se refere ao protótipo de regras acima (ou uma variação dele para atender às suas necessidades).
Benefício desta abordagem
Usando essa abordagem, você minimiza o risco de introduzir inconsistências de dados (em comparação com a atualização direta do banco de dados), com zero código personalizado envolvido (você usaria apenas a interface do usuário Views e a UI das regras).
fonte
Eu sei que você diz programaticamente, mas se você quiser usar um módulo, pode usar o Taxonomy Manager
fonte