TagsTableTag::_getNode(1, ) failed

**RobertG** · 07/05/2019, 16h23

Bonjour,

N'aurais-tu pas été informé récemment d'une mise à jour ou d'un changement de serveur pour ton hébergement ? Il n'est pas normal que la table se soit vidée.
Tu devrais récupérer une sauvegarde récente de la base pour la vérifier en local, au cas où ce serait ça qui aurait créé ce problème.

**Patrice** · 07/05/2019, 16h35

à peine je viens de publier ce message que je m'aperçois que JCE vient de publier une nouvelle version 2.7.13 suite à des bugs signalés. Le menu Tags a été ajouter à la fonction insérer des liens, et après installation de cette nouvelle version, mon problème de tags subsiste.

**woluweb** · 07/05/2019, 21h17

oui, JCE permet maintenant de faire un hyperlien vers un tag "X" ou "Y", mais logiquement ça n'affecte pas en soi les Tags, qui vivent leur vie par ailleurs

bizarre que la table soit vide

je pense que chez OVH il y a un backup de la base de données à jour-1, semaine -1 etc.
Essayez rapidement de retrouver ces backups pour voir ce qu'il y avait dans cette table (et le réinjecter depuis phpmyadmin p ex)

**Patrice** · 08/05/2019, 11h31

Merci à RobertG (et ce n'est pas la première fois que je le remercie...) et Woluweb pour vos réponses.

Effectivement, il y a eu une migration de serveur chez OVH concernant mon site. Mais celle-ci est intervenue le 26 avril et j'avais depuis créé des articles (notamment le 4 et le 6 mai) et j'avais parallèlement modifié la date de publication d'anciens articles pour les faire réapparaître dans le modules "derniers article" et tout cela s'était passé sans soucis. Les tags étaient encore accessibles à ce moment là. Et je n'avais pas ces messages d'erreur à l'enregistrement des articles.

Il ne m'est - hélas - pas possible de vérifier une ancienne base de données. OVH ne garde que sur une semaine... Et depuis le 26 avril, cela fait plus d'une semaine. J'avais pensé récupérer une de mes sauvegardes de base de données faite par LazyBackup... J'en avais une du 5 mai... donc juste avant les problèmes... Et je viens de me rendre compte que les sauvegardes de LazyBackup ne font que 20 octets... Donc problème.

La sauvegarde qui pourrait éventuellement donner une idée date du 17 avril (faite avec Akeeba avant de passer à la version 3.9.5 de Joomla!)..

Pour ce qui est de JCE... Je m'interroge quand même... Le message d'erreur intervient à l'enregistrement des articles créés avec JCE... Et actuellement sur le site est proposée au téléchargement la version 2.7.13 et la 2.7.12 a purement et simplement disparu... Ce qui m'interpelle car c'est comme si elle n'avais jamais existé.

Ceci étant dit.

Voici à présent mes questions... en rappelant que j'ai su mettre en ligne et gérer jusqu'à présent le site de mon club mais que ça s'arrête là. Dès qu'il s'agit de mettre les mains dans une base de données, je n'en ai pas les connaissances...(à part, les fonctions : réparer et éventuellement vider...)

- première question : Je viens de voir qu'une nouvelle version de Joomla vient de sortir 3.9.6. Si je l'installe, est-ce que cela va réparer la base de données pour les tags ? (ou, que faudrait-il faire pour cela)
.
- deuxième question : si j'arrive (avec beaucoup de persévérance et d'aide, peut-être) à installer en local ma bdd du 17 avril, est-il possible de ne restaurer sur le serveur de mon site que la base Tags ?

Merci pour vos réponses.

**RobertG** · 08/05/2019, 12h28

Bonjour Patrice,

Les versions de JCE sont bien là pour les "core" https://www.joomlacontenteditor.net/...ds/editor/core et pour les versions pro, sur la page équivalente une fois identifié.
Chaque nouvelle version corrige des erreurs.

Pour ce qui est de la table des tags, a priori, remplacer l'actuelle vide par une version précédente devrait corriger ton problème. Il faudrait tester sur une copie du site.

Quant à LazyDbBackup, peux-tu me contacter par MP ou depuis un de mes sites afin que j'essaie de comprendre pourquoi tes sauvegardes sont incorrectes (version de LazyDbBackup et éventuellement copie d'une sauvegarde incomplète notamment) ?

**Patrice** · 08/05/2019, 13h21

Effectivement la version 2.7.12 apparaît toujours dans la page des téléchargement Pro - je n'avais pas fait défiler l'écran et je ne voyais au départ que la version 2.4.13 et la 2.6.38...

Avant de tenter ne restauration de la table Tags par une ancienne, est-ce que la mise à jour de Joomla! en 3.9.5 remettrait les choses en ordre - même en ayant une table Tags vide (mais fonctionnelle), ce qui n'est pas trop un problème pour l'instant, l'essentiel étant de pouvoir - à nouveau - créer des tags.

Pour LazyDbBackup, je vois ça au plus tôt. J'ai également LDbChecker installé (version 3.5.0)... La version de LazyDbBackup date du temps où j'avais déjà eu des soucis que tu m'avais aidé à résoudre, c'est la 3.1.3a et je viens de me rendre compte que quand on veut intervenir sur ce plugin, il verrouille la table "extensions" et renvoie le message d'erreur "0 Call to undefined function mysql_connect()".

**RobertG** · 08/05/2019, 15h14

Non, la mise à jour ne récupérera pas les données de la table si elle a été vidée. Il faudra remettre une copie saine de cette table avant ou après le passage en 3.9.6
Il faudra aussi vérifier si la table _contentitem_tag_map ne s'est pas vidée elle aussi

Pour LazyDbBackup, il faut installer la version la plus récente (sauf erreur la 3.8.5 PDO chez OVH). La 3.1.3 date de 2014 et n'est donc pas compatible avec les versions récentes de PHP et Joomla!

**Patrice** · 08/05/2019, 18h14

La table _contentitem_tag_map ne s'est pas vidée, elle comporte 1043 lignes.

Concernant ma table tags, j'ai récupéré une table sauvegardée par Akeeba en date du 17 avril qui comporte 118 lignes. Donc, c'est déjà une bonne chose.

Mon soucis à présent est de mettre cette table (qui est en local) à la place de celle qui est sur le serveur OVH... J'ai utilisé le même nom pour la base de données en local et celle sur le serveur.

J'utilise Phpmyadmin et j'ai donc sélectionné en local ma table tags et uniquement elle et j'ai fait "exporter"... C'est là où ça se complique car le fichier créé comporte l'extension cs et se présente donc sous la forme maBase_tags.cs et lorsque je veux importer celle-ci sur mon serveur également par Phpmyadmin, j'ai ce message d'erreur :

Erreur
Analyse statique :
1 erreurs trouvées lors de l'analyse.

Type d'énoncé non reconnu. (near "using" at position 0)

Requête SQL :
using System
MySQL a répondu :
#1064 - Erreur de syntaxe près de 'using System' à la ligne 1

Pour comparer, j'ai fait un export de ma table tags à partir du serveur et l'extension est sql...

Du coup, j'imagine que le serveur s'attend à un fichier avec l'extension sql lors de l'import... Et je ne vois absolument pas comment créer ce fichier maBase_tags.sql à partir de ma base en local.

**RobertG** · 08/05/2019, 19h11

Ce n'est pas le nom de la base qui compte, mais celui de la table, préfixe et nom dédié (abcd_tags par exemple), et il faut n'importer que le contenu si la table existe déjà, sinon il faut soit un "DROP TABLE" et les instructions de création de la nouvelle table et sa structure avant l'import des données.
Il faut, en local, que tu t'assures que le mode d'export est bien en sql, le paramètre a dû être accidentellement changé (en csv plutôt que cs, je pense).
Si c'est bien en "csv" que tu l'as, sauf erreur tu dois pouvoir aussi le préciser à l'import, dans la section "format" de la page d'import phpMyAdmin.

**lefabdu51** · 08/05/2019, 21h01

LE format cs est pour un import microsoft.
Si tu regardes en bas du fichier les requetes sont des requetes sql microsoft.
De meme que la syntaxe du fichier 100% transact sql (c est pour ca que ca plantes, mysql ne reconnais pas les commandes)...

Second point, tu peut trouver le contenu de ta table directement dans ton fichier .jpa.
tu le decompresse avec akeeba extract wizard et ensuite tu vas dans le dossier sql.
tu recherche le nom de ta table dans les fichiers et tu trouveras une requete create table if not exist ainsi qu une requete insert into (assez longue car 118 enregistrements selon tes dires).
Tu recopies les deux requetes dans un fichier texte dont tu changes l extension pour .sql
Tu vas dans phpmyadmin, tu supprimes ta table et tu refait un import de celle ci directement dans ta bdd en important le fichier sql que tu a crée.

Pour info: dan le dossier sql se trouves l'intégralité des requêtes servant a recreer ta bdd ainsi que tout le contenu de celle ci.
Si tu souhaites un jour recreer toute ta bdd, tu les reimportes directement dans l'ordre et tu la retrouveras.....

**Patrice** · 08/05/2019, 21h06

Non, je confirme que l'extension du fichier exporté est .cs et non csv.
Et dans les paramètres par défaut d'exportation il est bien indiqué "sql". Je ne sais absolument pas d'où sort cette extension.
Après, peut-être que je n'utilise pas la bonne méthode pour l'export : je sélectionne le table tags puis je sélectionne "exporter". Là, l'écran indique "exportation des lignes de la table ...tags" et me propose "rapide" ou "personnalisé" et il y a un menu déroulant "format" : le format sélectionné par défaut est CodeGen. Dans ce menu déroulant, il y a bien CVS et CSV pour MS Excel mais pas SQL... Ca doit être là d'où vient le problème. Peut-être un problème de configuration de Wampserver. Je vais chercher des infos sur le sujet il y a apparemment un forum wampserver, par contre le site wampserver.com est inaccessible.

J'utilise en local Wamserver 64bit version 3.1.7 - avec une version Phpmyadmin 4.8.4 et Mysql 5.7.24 et Php 7.2.14

Peut-être devrais-je essayer un autre serveur local.

**Patrice** · 08/05/2019, 21h13

Concernant "akeeba extract wizard" évoqué par lefabdu51 j'ai fait une recherche pour le télécharger... La page renvoie vers la page de téléchargement de Akeeba et Akeeba extract wizard n'est pas proposé en téléchargement, uniquement Kickstart... Est-ce qu'il serait contenu dans un des fichiers proposés ?

**Patrice** · 09/05/2019, 08h07

Bon, problème apparemment réglé.

J'ai modifié ma façon de procéder pour l'export et l'import en sélectionnant ma base de données en local pour l'export et dans le mode personnalisé, je n'ai retenu que la table Tags et demandant de désactiver le contrôle des tables étrangères (j'ignore si c'était nécessaire, la table Tags étant une table InnoDb...).

J'ai obtenu un fichier sql au nom de ma base de données que j'ai renommé du nom de ma table Tags et j'ai importé ce fichier dans ma base sur le serveur.
Ce fichier a écrasé le fichier existant et mes tags sont à nouveau accessibles. Les articles antérieurs au problème comportent toujours les tags et ceux créés après n'en comportent aucun - ce qui est normal puisqu'il y avait le problème. J'ai renseigné les tags dans un de ces nouveaux articles et cela fonctionne.

Merci à ceux qui ont pris de leur temps pour se pencher sur ce problème. J'ignore comment il est survenu mais dès lors qu'il est résolu, c'est l'essentiel.

Je passe en "réglé".

**lefabdu51** · 09/05/2019, 10h25

j etait pas au courant de ceci :

Akeeba eXtract Wizard has been discontinued

https://www.akeebabackup.com/news/1724-akeeba-extract-wizard-has-been-discontinued.html

Akeeba eXtract Wizard has been discontinued since November 2018. This article explains why and what are your alternative.

Mais bon, ils donnent une solution. Effectuer la decompression via kickstar...

TagsTableTag::_getNode(1, ) failed

[RÉGLÉ] TagsTableTag::_getNode(1, ) failed

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Commentaire

Annonce

Partenaire de l'association