¿Es aceptable cambiar la columna vid de un término mediante programación en la base de datos?


8

Necesito mover algunos términos de un vocabulario a otro conservando todos sus datos: traducciones, alias y referencias de nodos.

¿Es aceptable cambiar su vidvalor de columna directamente en la base de datos? Los términos no tienen relaciones jerárquicas que deben manejarse.

Respuestas:


11

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.


4

No es aconsejable realizar cambios directos en la base de datos cuando se trabaja con Drupal. Pero sí, si sabemos dónde puede afectar y hacer los cambios necesarios en consecuencia, está bien hacer cambios directos en la base de datos. Porque en este caso esto no es posible a través de la interfaz de usuario. NOTA: Si tiene nodos asociados con Término, también tendrá que manejarlo manualmente.

Consulte este enlace que explica cómo podemos cambiar el vocabulario del término en Drupal 7: cambiar el vocabulario de un término de taxonomía en Drupal 7 utilizando la base de datos .


Un único problema que estoy viendo en esto es: si en el caso, hay campos adjuntos a un término con algunos valores y usted cambia su vid, entonces los datos almacenados en el campo se perderán.
Ashish Deynap

Sí, es por eso que también mencioné que, si hay nodos conectados, esos también deben manejarse .
Yogesh

Pero, ¿algún dato también se adjunta al término por vid? no solo por tid key?
Molfar

No, cualquier dato adjunto al término está relacionado con tid. vid se usa para hacer referencia solo a la identificación de vocabulario, nada más.
Yogesh

4

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í:

  • Reglas del evento: before saving content.
  • Condiciones de reglas:
    • entity has field, con campo = el campo antiguo.
    • Y NO ( entity has field, con campo = el nuevo campo).
  • Acción de reglas: 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):

{ "rules_replace_a_term_field_by_another_term_field" : {
    "LABEL" : "Replace a term field by another term field",
    "PLUGIN" : "rule",
    "OWNER" : "rules",
    "REQUIRES" : [ "rules" ],
    "USES VARIABLES" : { "node" : { "label" : "Node", "type" : "node" } },
    "IF" : [
      { "entity_has_field" : { "entity" : [ "node" ], "field" : "field_sample_tags" } },
      { "entity_has_field" : { "entity" : [ "node" ], "field" : "field_demo_tags" } },
      { "data_is" : { "data" : [ "node:field-demo-tags" ], "value" : "1" } }
    ],
    "DO" : [
      { "data_set" : { "data" : [ "node:field-sample-tags" ], "value" : "31" } },
      { "drupal_message" : { "message" : "Term updated in node with id = [node:nid]" } }
    ]
  }
}

Algunos detalles más para explicar el prototipo anterior:

  • Utiliza un nodo como parámetro.
  • Estas son las condiciones de las reglas:

    • compruebe si la entidad (= nodo) tiene un campo field_sample_tags.
    • compruebe si la entidad (= nodo) tiene un campo field_demo_tags.
    • verifique si el valor del campo 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:

    • Establezca el valor del campo 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).
    • Mostrar un mensaje en el sitio como Term updated in node with id = 72, mientras que 72es 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).


Asume que las vistas, VBO y las reglas ya están instaladas, de lo contrario, necesita instalar 3 módulos para esta solución. Además, el "código" de configuración que necesita implementar no es menos complejo de lo que sería necesario hacer en un enlace de actualización. Mi punto es que usar reglas y vistas no es tan simple como lo haces sonar. También vale la pena recordar que si bien puedes hacer casi cualquier cosa con Vistas y Reglas, hacerlo no siempre es una buena idea.
googletorp

1
Sí, de hecho: para usar Vistas, Reglas o VBO, el módulo debe estar instalado (+ habilitado). Pero de los aproximadamente 990K sitios D7, hay alrededor de 810K sitios que también tienen Vistas , eso es más del 80%. Y para los sitios que no tienen una razón para usar Reglas o VBO: esos módulos solo son necesarios para realizar dicha conversión (cuando se hace, se pueden eliminar si lo desea). Sobre la simplicidad: la OMI es más bien un problema de experiencia. La ventaja de este enfoque es que solo requiere habilidades de creación de sitios (un desarrollador PHP experimentado puede no estar disponible / no ser asequible).
Pierre.Vriens

2

Sé que dices programáticamente, pero si quieres usar un módulo puedes usar Taxonomy Manager

Este módulo proporciona una interfaz poderosa para administrar taxonomías. Se muestra un vocabulario en una vista de árbol dinámica, donde los términos principales se pueden expandir para enumerar sus términos secundarios anidados o se pueden contraer.

El Administrador de Taxonomía tiene las siguientes operaciones y características clave:

  • vista de árbol dinámico
  • eliminación masiva
  • adición masiva de nuevos términos
  • movimiento de términos en jerarquías fusión de términos (usando el módulo de fusión de términos en 7.x)
  • cambio de peso rápido con flechas hacia arriba y hacia abajo (y ahorro de AJAX)
  • Formulario de edición de términos con tecnología AJAX
  • interfaz de búsqueda simple
  • Exportación de términos CSV
  • Soporte de i18n para vocabularios multilingües (por términos de idioma)
  • Interfaz de doble árbol para mover términos en jerarquías, agregar nuevas traducciones y cambiar términos entre diferentes vocabularios
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.