Base de datos
Es posible hacer muchas cosas en Drupal simplemente haciendo consultas SQL, ya sea a través de Drupal o externamente. En general, nunca quieres adoptar este enfoque. Hay algunos casos en los que puede funcionar bien, pero la mayoría de las veces no hay razón para hacerlo de esta manera.
API
Drupal tiene una API rica, esto es cierto para Drupal 6, 7 y 8, ya que siempre ha sido una característica clave en Drupal. En su ejemplo exacto, podría usar taxonomy_term_loady taxonomy_term_savepara facilitar la actualización de un término. Al hacerlo de esta manera, puede editar cualquier parte de datos, incluido el vid. El hecho de que lo haga con API haciendo cosas prohibidas no funcionará automáticamente, pero la posibilidad de que las cosas salgan bien mejora drásticamente.
En este ejemplo concreto, la API no hace nada que sea necesariamente necesario. Establece algunos datos internos sobre el término e invoca el módulo de letras de ganchos que se ha actualizado.
Debe tener en cuenta que las cosas pueden romperse si el término que desea cambiar es parte de una jerarquía. Las cosas también pueden romperse para los nodos que hacen referencia al término, si el campo no puede hacer referencia a términos en el nuevo vocabulario.
Migración
La migración de datos es la solución a prueba de balas y, a menos que tenga un gran conjunto de datos, puede desarrollarse y ejecutarse con bastante facilidad. La idea es crear un nuevo término y migrar el contenido que desea migrar y luego eliminar el término anterior. Como enlace de actualización, el código de muestra podría verse así:
/**
* 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);
}
Tenga en cuenta que el código anterior es un código de ejemplo puro, escrito de memoria. Puede tener un error de sintaxis u otros errores y hace muchas suposiciones. Esto es solo para ilustrar una idea y demostrar que una migración podría no ser un gran problema.
No recomendaría cambiar ese término de la forma en que lo describió en su pregunta. En cambio, usaría un enfoque alternativo para lograr un resultado similar (en el orden especificado), que se detalla más adelante.
Paso 1: comience a usar el nuevo término en futuras actualizaciones de nodos
Cree un nuevo campo de término de taxonomía, de modo que "a partir de ahora" cualquier futura actualización de nodo (o nuevos nodos que se creen) utilizará ese nuevo campo. Supongo que estos términos se usan para nodos (si lo usa para algún otro tipo de entidad, como usuarios, etc.), también se puede usar el mismo enfoque para esas entidades.
Use el módulo Reglas para crear una regla así:
before saving content.entity has field, con campo = el campo antiguo.entity has field, con campo = el nuevo campo).set Drupal messageque contiene algunas instrucciones de que el campo anterior debe ser borrado, y el nuevo campo debe contener los valores apropiados.Paso 2: usa las reglas para acelerar el proceso
Obviamente, el enfoque en el Paso 1 tomará "algún" tiempo si esto tiene que hacerse manualmente, 1 nodo a la vez. Pero usando Vistas (para crear una lista de nodos similares para actualizar) y VBO (para actualizar en masa tales listas) es posible (¡debería!) Acelerar un poco este proceso.
Especialmente si usaría Reglas para crear una operación masiva personalizada para dicha vista VBO, como se explica en la respuesta a " ¿Cómo usar las Reglas para crear una operación masiva personalizada para una vista VBO? ". Aquí hay un prototipo de un componente de reglas que debería ayudar a implementar dicha operación masiva personalizada (en formato de exportación de reglas):
Algunos detalles más para explicar el prototipo anterior:
Estas son las condiciones de las reglas:
field_sample_tags.field_demo_tags.field_demo_tagscorresponde al término que queremos reemplazar (en este ejemplo, el término tiene id =1). Tenga en cuenta que si no se cumple esta condición, no se realizarán acciones de reglas.Estas son las acciones de reglas:
field_sample_tagsigual al término con el término id =31(que es el término en el vocabulario recién creado que coincide con el término en el vocabulario que se va a reemplazar).Term updated in node with id = 72, mientras que72es la identificación del nodo del nodo actualizado.Si lo desea, adapte los nombres de máquina de los nombres de campo en el prototipo anterior y los ID de término utilizados. Luego impórtelo en su propio sitio (usando la interfaz de usuario de reglas) y realice una prueba de control de calidad con el enlace "ejecutar" a la derecha del componente de reglas importado (e ingrese alguna identificación de nodo para probarlo, después de cambiar a "entrada directa" modo "para poder especificar un id de nodo). Si durante la prueba no recibe ese
Term updated in node ...mensaje, debe ser porque el nodo que seleccionó no usó el término valor especificado en su condición de reglas.Paso 3: usa VBO como toque final
Una vez que haya finalizado la prueba de control de calidad de este componente de reglas desde el paso 2, cree una vista VBO de los nodos que se procesarán, en la que se referirá al prototipo de reglas anterior (o una variación del mismo para satisfacer sus necesidades).
Beneficio de este enfoque
Con este enfoque, minimiza el riesgo de introducir inconsistencias de datos (en comparación con la actualización directa de la base de datos), con cero código personalizado (solo usaría la UI de Vistas y la UI de Reglas).
fuente
Sé que dices programáticamente, pero si quieres usar un módulo puedes usar Taxonomy Manager
fuente