È accettabile modificare la colonna video di un termine a livello di codice nel database?

Devo spostare alcuni termini da un vocabolario all'altro mantenendo tutti i loro dati: traduzioni, alias e riferimenti ai nodi.

È accettabile modificare il vidvalore della sua colonna direttamente nel database? I termini non hanno relazioni gerarchiche che devono essere gestite.

Banca dati

È possibile eseguire molte operazioni in Drupal semplicemente eseguendo query SQL, tramite Drupal o esternamente. In generale, non vuoi mai adottare questo approccio. Ci sono alcuni casi in cui può funzionare bene, ma la maggior parte delle volte non c'è motivo di farlo in questo modo.

API

Drupal ha una ricca API, questo vale per Drupal 6, 7 e 8, poiché sono sempre stati una caratteristica chiave di Drupal. Nel tuo esempio concreato, puoi usare taxonomy_term_loade taxonomy_term_savefacilitare un aggiornamento di un termine. In questo modo, è possibile modificare qualsiasi parte di dati incluso il vid. Solo perché lo fai con le API, le cose proibite non funzioneranno automaticamente, ma la possibilità che le cose vadano bene è drasticamente migliorata.

In questo esempio concreto l'API non fa nulla di ciò che è necessariamente necessario. Imposta alcuni dati interni sul termine e invoca il modulo lettera hook sapendo che è stato aggiornato.

Dovresti notare che le cose possono rompersi, se il termine che vuoi cambiare fa parte di una gerarchia. Le cose possono anche rompersi per i nodi che fanno riferimento al termine, se al campo non è consentito fare riferimento ai termini nel nuovo vocabolario.

Migrazione

La migrazione dei dati è la soluzione a prova di proiettile e, a meno che non si disponga di un enorme set di dati, può essere sviluppato ed eseguito abbastanza facilmente. L'idea è quella di creare un nuovo termine e migrare il contenuto che si desidera migrare e quindi eliminare il vecchio termine. Come hook di aggiornamento, il codice di esempio potrebbe essere simile al seguente:

/**
 * 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);
}

Si noti che il codice sopra riportato è puro esempio di codice, scritto a memoria. Potrebbe avere errori di sintassi o altri errori e fare molte ipotesi. Questo è solo per illustrare un'idea e dimostrare che una migrazione potrebbe non essere un grosso problema.

Non è consigliabile apportare modifiche dirette al database quando si lavora con Drupal. Sì, se sappiamo dove tutto ciò può influire e apportiamo le modifiche necessarie di conseguenza, è OK apportare modifiche dirette al database. Perché in questo caso ciò non è possibile tramite l'interfaccia utente. NOTA: se hai nodi associati a Term, dovrai gestirlo anche manualmente.

Dai un'occhiata a questo link che spiega come possiamo cambiare il termine vocabolario in Drupal 7: Cambia il vocabolario di un termine tassonomico in Drupal 7 usando il database .

Non consiglierei di cambiare quel termine nel modo in cui l'hai descritto nella tua domanda. Invece userei un approccio alternativo per ottenere un risultato simile (nell'ordine specificato), che è ulteriormente dettagliato di seguito.

Passaggio 1: iniziare a utilizzare il nuovo termine nei futuri aggiornamenti del nodo

Creare un nuovo campo del termine tassonomia, in modo che "d'ora in poi" eventuali futuri aggiornamenti del nodo (o nuovi nodi creati) utilizzino quel nuovo campo. Presumo che questi termini vengano utilizzati per i nodi (se lo si utilizza per qualche altro tipo di entità, come utenti, ecc.), Lo stesso approccio può essere utilizzato anche per tali entità.

Utilizzare il modulo Regole per creare una regola in questo modo:

• Regole eventi: before saving content.
• Condizioni delle regole:
  • entity has field, con field = il vecchio campo.
  • E NON ( entity has field, con field = il nuovo campo).
• Regole Azione: set Drupal messageche contiene alcune istruzioni per cancellare il vecchio campo e il nuovo campo deve contenere i valori appropriati.

Passaggio 2: utilizzare le regole per accelerare il processo

Ovviamente, l'approccio nel passaggio 1 richiederà "un po '" di tempo se ciò deve essere fatto manualmente, 1 nodo alla volta. Ma usando Views (per creare un elenco di nodi simili da aggiornare) e VBO (per aggiornare in massa tali elenchi) potresti (dovresti!) Essere in grado di accelerare un po 'questo processo.

Soprattutto se si utilizzassero le Regole per creare un'operazione di massa personalizzata per tale vista VBO, come spiegato nella risposta a " Come usare le Regole per creare un'operazione di massa personalizzata per una vista VBO? ". Ecco un prototipo di un componente di regole che dovrebbe aiutare a implementare tale operazione in blocco personalizzata (nel formato di esportazione delle regole):

{ "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]" } }
    ]
  }
}

Alcuni ulteriori dettagli per spiegare il prototipo sopra:

• Utilizza un nodo come parametro.

• Queste sono le Condizioni Condizioni:

  • controlla se l'entità (= nodo) ha un campo field_sample_tags.
  • controlla se l'entità (= nodo) ha un campo field_demo_tags.
  • controlla se il valore del campo field_demo_tagscorrisponde al termine che vogliamo sostituire (in questo esempio il termine ha id = 1). Se questa condizione non è soddisfatta, non verranno eseguite azioni sulle regole.

• Queste sono le azioni sulle regole:

  • Impostare il valore del campo field_sample_tagsuguale al termine con il termine id = 31(che è il termine nel vocabolario appena creato che corrisponde al termine nel vocabolario che deve essere sostituito).
  • Visualizza un messaggio sul sito come Term updated in node with id = 72, mentre 72è l'id del nodo aggiornato.

Se lo si desidera, adattare i nomi dei computer dei nomi dei campi nel prototipo sopra e i termini ID utilizzati. Quindi importalo nel tuo sito (usando l'interfaccia utente delle regole) e QA-test con il link "esegui" a destra del componente delle regole importato (e inserisci un id nodo per testarlo, dopo essere passato a "input diretto modalità "per poter specificare un ID nodo). Se durante il test non ricevi questo Term updated in node ...messaggio, ciò è dovuto al fatto che il nodo selezionato non ha utilizzato il termine valore specificato nelle Condizioni delle regole.

Passaggio 3: utilizzare VBO come tocco finale

Dopo aver terminato il test QA di questo componente delle regole dal passaggio 2, creare una vista VBO dei nodi da elaborare, in cui si fa riferimento al prototipo delle regole sopra (o una variante di esso per adattarsi alle proprie esigenze).

Beneficio di questo approccio

Utilizzando questo approccio, riduci al minimo il rischio di introdurre incoerenze nei dati (rispetto all'aggiornamento diretto del database), con zero codice personalizzato coinvolto (utilizzeresti solo l'interfaccia utente di Views e l'interfaccia utente delle regole).

So che dici a livello di codice ma se vuoi usare un modulo puoi usare Taxonomy Manager

Questo modulo fornisce una potente interfaccia per la gestione delle tassonomie. Un vocabolario viene visualizzato in una vista ad albero dinamica, in cui i termini principali possono essere espansi per elencare i loro termini figlio nidificati o possono essere compressi.

Il Taxonomy Manager ha le seguenti operazioni e caratteristiche chiave:

• treeview dinamico
• eliminazione di massa
• aggiunta di massa di nuovi termini
• spostamento dei termini nelle gerarchie fusione dei termini (utilizzando il modulo Unione termini in 7.x)
• cambio peso rapido con frecce su e giù (e risparmio AJAX)
• Modulo di modifica dei termini basato su AJAX
• semplice interfaccia di ricerca
• CSV Esportazione di termini
• Supporto i18n per vocabolari multilingue (per termini linguistici)
• Interfaccia Double Tree per lo spostamento di termini nelle gerarchie, l'aggiunta di nuove traduzioni e il cambio di termini tra diversi vocabolari