Bonjour,
Un truc bizarre.
J'ai importé une base SPIP 3.2.7 avec menus 1.6.11 vers un site neuf 3.2.7 et menus 1.7.25.
Mon menu n'apparaît plus.
Quand je vais l'éditer dans l'espace privé, j'ai bien mes 7 entrées définies, mais en éditant chaque entrée, tous les champs sont vides !
Et dans la base par phpMyAdmin, j'ai bien mes données dedans...
Une piste ?
Merci
Un ?var_mode=inclure pourrait peut-être apporter un indice pour détecter la partie défaillante ?
Bonsoir,
Un truc bizarre.
J'ai importé une base SPIP 3.2.7 avec menus 1.6.11 vers un site neuf 3.2.7 et menus 1.7.25.Mon menu n'apparaît plus.
Quand je vais l'éditer dans l'espace privé, j'ai bien mes 7 entrées définies, mais en éditant chaque entrée, tous les champs sont vides !Et dans la base par phpMyAdmin, j'ai bien mes données dedans...
En fait c'est un problème d'encodage de caractères.
Dans ma base d'origine j'avais des infos de champ 'parametres' de table menu-entrees telles que :
â–¶";s:3:"url";s:61:"https://[...]";s:3:"css";s:0:"";s:8:"css_lien";s:0:"";}
A la mutation sur le nouveau site, j'ai converti toutes les tables en utf-8, ce qui a donné :
";s:3:"url";s:61:"https://[...]";s:3:"css";s:0:"";s:8:"css_lien";s:0:"";}
Le nouveau codage comprend moins de caractères, mais la chaine JSON n'a pas été mise à jour sur son champ s:27 qui aurait dû passer à s:24
Résultat : tous les champs retournent des valeurs vides, même dans l'espace privé :
arf oui c'est la plaie. c'est précisement pas de l'encodage json (qui n'est pas sensible à cela) mais de l'encodage php ((un)serialize).
Et l'encodage php est très sensible à cela, contrairement à l'encodage json.
Tu peux trouver sur internet des infos sur comment "restaurer" une serializaion mal foutu...