Bonjour,
J’ai récemment déplacé mon site de one.com à ovh.fr.
Et depuis je ne peux plus créer de nouveaux articles, et quand je veux éditer un article, j’ai cette erreur :
« Une erreur technique a empêché l’enregistrement correct du champ ‹ date_modif › . »
Auriez-vous une idée de commander régler le problème ?
J’ai déjà essayé une réparation de la DB via la maintenance mais cela ne fonctionne pas et je n’ai pas de backup plus ancien pour régler ca.
D’avance merci
Bonjour,
Les versions de SPIP étaient-elles les même d’un hébergeur à l’autre ?
Quelle technique utilisée pour déménager la base de données ? (privilégier l’export/import SQL au plus près de la base avec phpMyAdmin par exemple)
Il est possible que la base soit «corrompue».
Bonjour,
Spip était dans une version ancienne 3, je ne sais plus a quel moment je suis passé en spip 4, avant ou après le déplacement.
J’ai fais un export import via mysql car la restauration ne fonctionnait pas via spip maintenance.
Avez-vous une idée comment réparer cette base de données ? Tout le site fonctionne bien à part la création et édition d’article. Je pense qu’il y a un problème au niveau des dates, car je ne peux pas éditer la date des articles, et ils ne sont plus affichés dans l’ordre chronologique (toujours problème de date), par contre en base de donnée les dates semblent correctes…
Le pbm ne serait-il pas lié au passage de MariaDB à mySQL 8 ? il me semble en tous cas que OVH est en mySQL, pour one.com je ne sais pas.
Je suggère ça car c’est un des points d’achoppement depuis que mariaDB et mySQL divergent, en particulier sur les champs date … sauf erreur de ma part.
Bonjour,
Quelle est la version de SPIP 4.x.x ?
Je ne pense pas, car il me semble que one.com était en mySQL aussi
Bonjour,
4.3.6
Non, one.com est apparemment en MariaDB, décrit ici.
En théorie Spip supporte les 2 mais je me demandais si la concurrence de la migration et de la mise à jour a fait que quelque chose s’est mal passé …
J’ai eu assez bien de mal à l’importer d’ailleurs, car c’était pas possible via la maintenance, il n’importait rien via la maintenance.
Je suis donc passé par mysql, et la ca semblait parfait, jusqu’à ce que je vois qu’il m’était impossible de créer ou éditer un article.
Auriez-vous une solution pour corriger le problème ou détecter d’où vient l’erreur ?
Quand je compare les DB ca semble identique…
Est-ce que le Fuseau horaire du site est bien configuré : ecrire/?exec=configurer_identite
J’ai testé ce matin justement et non aucune différence
Aucun autre idée ? Ce qui est compliqué ce de ne même pas savoir d’où vient exactement le problème 
Tu peux commencer par activer les logs verbeux cf Les aides au débuggage de squelettes - SPIP ça devrait te donner des pistes.
En général les cas ou j’ai vu ça (pas sur Spip) c’est dû au fait que l’on tente d’enregistrer une date vide au format « 0000-00-00 00:00:00 » (ou approchant) qui n’est plus valide pour sûr en mysql8 (peut-être êtes vous passé d’un MariaDB un peu plus ancien qui acceptait ça) …
On peut dire à mySQL de les accepter (SET SQL_MODE=‹ ALLOW_INVALID_DATES ›;), peut-être tenter de passer cette commande avec phpMyAdmin et tenter ensuite de faire un article depuis Spip, ça permettrait peut-être d’écarter cette option …
Je mets bcp de conditionnel car je ne connais pas assez les entrailles de Spip pour être sûr, comme je le dis j’ai vu ce type d’erreur sur d’autres projets PHP et c’était causé par ce genre de chose mais je ne sais pas si ça fait du sens dans le cadre de Spip. Dans ces autres projets on ne pouvait pas éditer un enregistrement car un des champs conservait un « 0000-00-00 00:00:00 » (même pas celui qu’on souhaitait modifier) et mySQL refusait la mise à jour de l’enregistrement.
Après il faut peut-être explorer la base et comparer la structure des champs avec une installation qui fonctionne, vérifier que le moteur (myISAM, InnoDB, …) est conforme à une installation vierge, …
PS: pas sûr que la commande évoquée puisse être passée sur le phpMyAdmin d’un mutu OVH.