Migration de la base de données

[Lenny Obez]

Bonjour,

 

Je dispose d'une base de données OVH sur mon hébergement mutualisé et c'est là-dessus que repose mon CMS PrestaShop, j'ai essayé ce matin de migrer vers la base de données privée qui est sur un hébergement dédié, j'ai mis le CMS en maintenance, fait une sauvegarde de la BDD en mode "rapide", j'ai importer cette sauvegarde sur la nouvelle BDD en conservant le même nom d'utilisateur, de tables, ... La seule chose qui change est donc l'adresse.

 

Je change cette adresse dans "settings.inc.php" via la requête '_DB_SERVER_', une fois enregistré et le CMS hors maintenance, tous mes plugins disparaissent. J'ai ré-essayé plusieurs fois la manipulation mais c'est le-même résultat.

 

Lorsque je vais sur le back-office, c'est bon, même pour les modules. Ce n'est que sur le front-office que tout disparaît.

 

Pouvez-vous m'aider à comprendre ce qu'il se passe?

[Lenny Obez]

Tout d'abord, merci pour ta réponse rapide

 

Les groupes avaient le droit 5 (755) et je viens de le passer à 7 (775), la désactivation des modules n'y changent rien. Par contre, lorsque je désactive les modules sur la bonne base de données, j'ai EXACTEMENT le-même résultat que si je suis sur la nouvelle base de données.

 

ancienne BDD = bon affichage

nouvelle BDD = mauvais affichage (aucun module)

ancienne BDD + désactiver les modules non PrestaShop = identique (mauvais affichage (aucun module))

[Lenny Obez]

 

 

Je parle des groupes prestashop. 

 

Oui, tu parles bien des groupes PrestaShop sur le FTP, non?

 

 

 

Tu veux dire que tu as une page blanche ?

 

Non, il me reste encore le logo ainsi qu'un en-tête et un pied de page que j'ai fait moi-même grâce à un thème enfant.

 

 

À gauche, sur l'ancienne base, à droite, sur la nouvelle base. À savoir que sur le back-office, la position, les modules et le contenu des modules sont à l'identique.

[Lenny Obez]

Les groupes ont bel et bien les droits adéquats et je viens d'activer les erreurs (j'ai oublié de réaliser cette étape très importante):

 

Fatal error: Uncaught Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column '*.h.name' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by<br /><br /><pre>SELECT h.`name` as hook, m.`id_module`, h.`id_hook`, m.`name` as module, h.`live_edit` FROM `ps_module` m INNER JOIN ps_module_shop module_shop ON (module_shop.id_module = m.id_module AND module_shop.id_shop = 1 AND module_shop.enable_device & 1) INNER JOIN `ps_module_shop` ms ON ms.`id_module` = m.`id_module` INNER JOIN `ps_hook_module` hm ON hm.`id_module` = m.`id_module` INNER JOIN `ps_hook` h ON hm.`id_hook` = h.`id_hook` LEFT JOIN `ps_module_group` `mg` ON mg.`id_module` = m.`id_module` WHERE (h.name != "displayPayment") AND (hm.id_shop = 1) AND (mg.id_shop = 1 AND mg.`id_group` IN (1)) GROUP BY hm.id_hook, hm.id_module ORDER BY hm.`position` </pre> thrown in /home/*/www/classes/db/Db.php on line 635

 

J'ai remplacé par un astérisque les informations "à risque" (dans le lien en gras et dans la partie: "nonaggregated column '*.h.name'")

Edited November 25, 2016 by Lenny Obez (see edit history)

[Lenny Obez]

Je migre bel et bien de MySQL 5.5 à MySQL 5.7. Je vais rechercher sur le web s'il y a un code miracle ou un mini-changement que je peux réaliser afin de régler le soucis.

[Lenny Obez]

Je vérifie ça à la maison alors En fait, quand je dois poster une question sur un forum, je prends l'habitude de reporter le travail en question et de passer à autre chose histoire d'avoir du différé, d'un côté, je continue à travailler sur un autre To Do et de l'autre, je reçois la réponse de super membres Ça m'évite de devoir attendre 4 heures la réponse sans rien faire pendant les heures de pointes ^^

 

Et comme je suis dans autre chose, je ne saurais "réfléchir"

 

À tout à l'heure (je reviendrais dire quoi) et merci beaucoup