Base de données
Il est possible de faire beaucoup de choses dans Drupal simplement en faisant des requêtes SQL, soit via Drupal soit en externe. Généralement, vous ne voulez jamais adopter cette approche. Il y a des cas où cela peut très bien fonctionner, mais la plupart du temps il n'y a aucune raison de le faire de cette façon.
API
Drupal possède une API riche, cela est vrai pour Drupal 6, 7 et 8, car ils ont toujours été une caractéristique clé de Drupal. Dans votre exemple concré, vous pourriez utiliser taxonomy_term_loadet taxonomy_term_savepour faciliter la mise à jour d'un terme. De cette façon, vous pouvez modifier n'importe quelle partie de données, y compris le vid. Tout simplement parce que vous le faites avec des API faisant des choses interdites, cela ne fonctionnera pas automatiquement, mais les chances que les choses se passent bien sont considérablement améliorées.
Dans cet exemple concret, l'API ne fait rien de nécessaire. Il définit certaines données internes sur le terme et appelle le module de lettre des crochets sachant qu'il a été mis à jour.
Vous devez noter que les choses peuvent se casser si le terme que vous souhaitez modifier fait partie d'une hiérarchie. Les choses peuvent également se briser pour les nœuds référençant le terme, si le champ n'est pas autorisé à référencer des termes dans le nouveau vocabulaire.
Migration
La migration des données est la solution à toute épreuve, et à moins que vous n'ayez un énorme ensemble de données, il peut être développé et exécuté assez facilement. L'idée est de créer un nouveau terme et de migrer le contenu que vous souhaitez migrer, puis de supprimer l'ancien terme. En tant que hook de mise à jour, un exemple de code pourrait ressembler à ceci:
/**
* 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);
}
Veuillez noter que le code ci-dessus est un exemple de code pur, écrit par cœur. Peut avoir une erreur de syntaxe ou d'autres erreurs et fait beaucoup d'hypothèses. Il s'agit simplement d'illustrer une idée et de démontrer qu'une migration pourrait ne pas être un gros problème.
Je ne recommanderais pas de changer ce terme comme vous l'avez décrit dans votre question. Au lieu de cela, j'utiliserais une approche alternative pour obtenir un résultat similaire (dans l'ordre spécifié), qui est détaillé ci-dessous.
Étape 1 - Commencez à utiliser le nouveau terme dans les futures mises à jour des nœuds
Créez un nouveau champ de terme de taxonomie, de sorte que "désormais" toutes les futures mises à jour de nœuds (ou nouveaux nœuds en cours de création) utiliseront ce nouveau champ. Je suppose que ces termes sont utilisés pour les nœuds (si vous l'utilisez pour un autre type d'entité, comme les utilisateurs, etc.), la même approche peut également être utilisée pour ces entités.
Utilisez le module Règles pour créer une règle comme ceci:
before saving content.entity has field, avec champ = l'ancien champ.entity has field, avec champ = le nouveau champ).set Drupal messagequi contient des instructions indiquant que l'ancien champ doit être supprimé et que le nouveau champ doit contenir la ou les valeurs appropriées.Étape 2 - Utilisez des règles pour accélérer le processus
De toute évidence, l'approche de l'étape 1 prendra "un certain" temps si cela doit être fait manuellement, 1 nœud à la fois. Mais en utilisant Views (pour créer une liste de nœuds similaires à mettre à jour) et VBO (pour mettre à jour en masse ces listes), vous pourriez (devriez!) Accélérer un peu ce processus.
Surtout si vous souhaitez utiliser des règles pour créer une opération en bloc personnalisée pour une telle vue VBO, comme expliqué dans la réponse à " Comment utiliser des règles pour créer une opération en bloc personnalisée pour une vue VBO? ". Voici un prototype d'un composant de règles qui devrait aider à implémenter une telle opération en bloc personnalisée (au format d'exportation de règles):
Quelques détails supplémentaires pour expliquer le prototype ci-dessus:
Ce sont les conditions des règles:
field_sample_tags.field_demo_tags.field_demo_tagscorrespond au terme que nous voulons remplacer (dans cet exemple, le terme a id =1). Notez que si cette condition n'est pas remplie, aucune action de règles ne sera effectuée.Ce sont les actions de règles:
field_sample_tagségale au terme avec le terme id =31(qui est le terme du vocabulaire nouvellement créé qui correspond au terme du vocabulaire à remplacer).Term updated in node with id = 72, alors que72c'est l'ID de nœud du nœud mis à jour.Si vous le souhaitez, adaptez les noms de machine des noms de champ dans le prototype ci-dessus et les ID de terme utilisés. Ensuite, importez-le dans votre propre site (à l'aide de l'interface utilisateur des règles) et testez-le en utilisant le lien "exécuter" à droite du composant de règles importé (et entrez un identifiant de nœud pour le tester, après avoir basculé sur "entrée directe" mode "pour pouvoir spécifier un identifiant de nœud). Si pendant votre test, vous n'obtenez pas un tel
Term updated in node ...message, cela doit être dû au fait que le nœud que vous avez sélectionné n'a pas utilisé la valeur de terme spécifiée dans vos règles Condition.Étape 3 - Utilisez VBO comme touche finale
Une fois que vous avez terminé de tester le contrôle qualité de ce composant de règles à partir de l'étape 2, créez une vue VBO des nœuds à traiter, dans laquelle vous vous référez au prototype de règles ci-dessus (ou une variante de celui-ci pour répondre à vos besoins).
Bénéfice de cette approche
En utilisant cette approche, vous minimisez le risque d'introduire des incohérences de données (par rapport à la mise à jour directe de la base de données), sans aucun code personnalisé impliqué (vous n'utiliseriez que l'interface utilisateur des vues et l'interface utilisateur des règles).
la source
Je sais que vous dites par programmation mais si vous voulez utiliser un module, vous pouvez utiliser Taxonomy Manager
la source