Transfert serveur, problèmes avec les tables Kunena

[louisseize]

Bonjour,
Ou plutôt bonsoir,

J'ai mis à jour un vieux Joomla vers 5.1 à partir d'un clone installé sur mon hébergement O2Switch. Vu que tout est correct, je fais un backup avec Akeeba et vais l'installer sur l'hébergement du site en ligne, dans un autre dossier, toujours sur un O2Switch.
Et là, boum patatras, Akeeba me signale un problème avec une table kunena. Je passe, les fichiers sont installés. Je fais alors un export manuel de la base de données du site de dev et l'importe manuellement sur l'autre hébergement. Ca tourne, ça tourne, et au bout d'un moment ça plante. La bdd fait dans les 300Mo non zippée.
Je passe alors par le terminal. Pareil, il m'indique une erreur.
Je supprime dans la bdd cible les tables kunena, j'exporte du site origine uniquement ces tables, et j'ai une erreur qui dit que l'index est trop long dans la table aliases de kunena. De fait, les données sont bien importées, mais pas de clé primaire, pas d'index etc dans les tables du composant. Vérification sur la base d'origine : tous les champs de cette table sont des champs index.

Ayant accès à l'admin, j'ai essayé de réinstaller kunena mais cela donne cette erreur : Class "Kunena\Forum\Libraries\Config\KunenaConfig" not found
Que j'ai maintenant sur toutes les pages de l'admin.

Et en front (debug actif), j'ai ceci : Attempted to load class "Helper" from namespace "HelixUltimate\Framework\Platform".
Did you forget a "use" statement for another namespace?

J'utilise très souvent Akeeba, depuis des années, c'est la première fois que j'ai ce genre de souci.
Comment puis-je réparer cela ?
Du côté des fichiers, fait un backup "classique" par FTP puis tout rebalancer ?
Et niveau bdd ?

Merci d'avance pour les pistes que vous pourrez me donner, je sens que la nuit va être longue ...

[RobertG]

Bonsoir,

Tu peux essayer avec Akeeba de faire un export des fichiers sans les tables, et avec phpMyAdmin un export seulement de leur structure puis de leurs données, en désactivant la vérification des clés étrangères et en gzippant le fichier des données.

[louisseize]

Merci pour ton aide. Mais j'ai fait un export/import par FTP des fichiers + export:import des tables sans données, sans succès, même erreur. J'ai dû modifier le varchar du champ alias de la table kunena_aliases pour que ça passe. Ensuite, j'ai essayé de le remettre à 255 mais il accepte 200, pas plus sinon erreur index trop long. Pourtant, même hébergeur (pas le même hébergement). Je m'arrache les cheveux !
Dans ma base de données, j'ai pu remettre le varchar à 255. C'est chez O2Switch. J'ai vérifié, sur les deux hébergements, la version de mysql est la même, interclassement identique, php 8.1 par htaccess et php.ini des deux côtés (car d'autres sites non compatibles sur les 2). Malgré que l'import des tables ait enfin fonctionné avec le changement de varchar, j'ai toujours la même erreur due à kunena en admin, même pire depuis que j'ai essayé de le réinstaller, il n'y a plus de menus dans la colonne de gauche. Je vais tout recommencer sur une autre "lune" de l'hébergement. Et en front je ne comprends pas l'erreur helix

[louisseize]

Suite des opérations. J'ai refait une sauvegarde Akeeba, installée, même erreur due à l'index trop long dans kunena_aliases, retiré cette table, et la suite s'est bien déroulée, normalement, et front + admin sont ok. Par curiosité, j'ai fait une install sur mon propre hébergement O2Switch. Et là il y a juste eu une erreur sur une autre table (duplicate entry) mais comme je n'en vais pas besoin, je l'ai retirée. Et tout s'est installé sans erreur concernant kunena. Alors là j'y comprends que dalle. Pourquoi dans mon propre hébergement O2Switch, ça marche. Et pas dans l'hébergement cible, aussi chez O2Switch ??? Car là, je vais essayer de refaire comme cette nuit, modifier le varchar du champ de la table, importer, puis modifier avec max 200, je suppose que kunena supportera. Mais c'est vraiment bizarre. Je vais contacter l'hébergeur.