Corriger Invalid default value for comment_date dans LocalWP

Vous importez une ancienne base WordPress dans LocalWP, Adminer échoue, vous passez par le shell, l’import démarre… puis MySQL bloque avec cette erreur :

ERROR 1067 (42000): Invalid default value for 'comment_date'Langage du code : JavaScript (javascript)

Bonne nouvelle : votre dump SQL n’est pas forcément corrompu. Mauvaise nouvelle : MySQL applique probablement un mode SQL plus strict que celui utilisé par l’ancien site. Résultat, il refuse certaines anciennes valeurs de dates WordPress, notamment dans la table des commentaires.

Dans cet article, on corrige précisément cette erreur dans LocalWP, sans refaire tout le tutoriel d’import général. Si vous cherchez la méthode complète pour importer une base SQL dans Local depuis le shell, commencez par ce guide : importer une base de données dans Local depuis le shell.

Le symptôme : Adminer échoue ou MySQL bloque pendant l’import

Dans LocalWP, vous pouvez importer une base WordPress via Adminer. Pour une petite base, cela passe souvent très bien. Pour une grosse base, ou une base ancienne, Adminer peut mouliner, perdre l’affichage, dépasser les limites PHP, ou ne rien importer du tout.

Le réflexe logique consiste alors à ouvrir le shell du site :

1. ouvrez LocalWP ;
2. sélectionnez le site concerné ;
3. faites un clic droit sur le site ;
4. cliquez sur Open Site Shell.

Vous tentez ensuite un import avec WP-CLI :

wp db import ./adminer.sqlLangage du code : JavaScript (javascript)

Ou avec MySQL directement :

mysql -u root -proot local < ./adminer.sql

Et MySQL finit par répondre :

ERROR 1067 (42000) at line 23841 in file: './adminer.sql': Invalid default value for 'comment_date'Langage du code : JavaScript (javascript)

La ligne exacte varie selon votre dump. Le problème, lui, reste le même : MySQL refuse une valeur par défaut considérée comme invalide pour une colonne de date.

Pourquoi cette erreur apparaît dans WordPress

Historiquement, WordPress et beaucoup d’anciennes bases MySQL ont utilisé des valeurs de date comme :

0000-00-00 00:00:00Langage du code : CSS (css)

On les retrouve notamment dans des colonnes comme comment_date, comment_date_gmt, post_date, post_date_gmt, ou dans certaines tables créées par des extensions.

Le souci arrive quand MySQL fonctionne avec un sql_mode strict incluant NO_ZERO_DATE et NO_ZERO_IN_DATE. Ces modes contrôlent l’acceptation des dates à zéro ou partiellement à zéro. Avec le mode strict, MySQL peut refuser l’import au lieu d’accepter l’ancienne définition de table ou l’ancienne valeur. La documentation MySQL précise que NO_ZERO_DATE concerne les dates comme 0000-00-00, tandis que NO_ZERO_IN_DATE concerne les dates dont le mois ou le jour vaut zéro. :contentReference[oaicite:1]{index=1}

MySQL 8.0 inclut par défaut plusieurs modes stricts, dont STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO et NO_ENGINE_SUBSTITUTION. C’est pour cela que d’anciens dumps WordPress peuvent échouer dans un environnement moderne. :contentReference[oaicite:2]{index=2}

Vérifier le sql_mode dans LocalWP

Commencez par ouvrir le shell du site dans LocalWP. Ensuite, connectez-vous à MySQL. Dans beaucoup d’environnements Local, l’utilisateur est root, le mot de passe est root, et la base s’appelle local :

mysql -u root -proot

Si cette commande échoue, utilisez les informations affichées dans l’onglet Database de LocalWP. Selon la version de Local, le socket MySQL peut aussi être nécessaire.

Une fois connecté à MySQL, affichez les modes SQL globaux et ceux de la session courante :

SELECT @@GLOBAL.sql_mode;
SELECT @@SESSION.sql_mode;Langage du code : CSS (css)

Vous pouvez obtenir quelque chose de ce genre :

ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

Les deux valeurs qui nous intéressent ici sont :

• NO_ZERO_DATE
• NO_ZERO_IN_DATE

Ce sont elles qui provoquent souvent l’erreur sur les anciennes dates WordPress.

Solution rapide : modifier sql_mode pour la session MySQL

La solution la plus propre en local consiste à modifier le sql_mode seulement pour la session MySQL utilisée pendant l’import.

Connectez-vous à MySQL :

mysql -u root -proot

Puis retirez temporairement NO_ZERO_DATE et NO_ZERO_IN_DATE de la session :

SET @@SESSION.sql_mode = REPLACE(@@SESSION.sql_mode, 'NO_ZERO_DATE', '');
SET @@SESSION.sql_mode = REPLACE(@@SESSION.sql_mode, 'NO_ZERO_IN_DATE', '');
SET @@SESSION.sql_mode = REPLACE(@@SESSION.sql_mode, ',,', ',');
SET @@SESSION.sql_mode = TRIM(BOTH ',' FROM @@SESSION.sql_mode);Langage du code : CSS (css)

Vérifiez le résultat :

SELECT @@SESSION.sql_mode;Langage du code : CSS (css)

La session ne doit plus contenir NO_ZERO_DATE ni NO_ZERO_IN_DATE.

Cette modification est temporaire. Elle s’applique à la connexion MySQL courante. C’est exactement ce qu’on veut pour un import local : corriger le blocage sans changer durablement toute la configuration de MySQL.

Importer la base dans la même session MySQL

Comme le réglage précédent s’applique à la session courante, le plus simple consiste à importer le fichier SQL directement depuis le prompt MySQL avec SOURCE.

Sélectionnez d’abord la base locale :

USE local;Langage du code : PHP (php)

Puis importez votre dump :

SOURCE ./adminer.sql;

Si votre fichier se trouve dans le dossier parent, adaptez le chemin :

SOURCE ../adminer.sql;

Sur macOS, si le chemin contient des espaces, placez le fichier SQL directement dans le dossier du projet pour éviter les chemins interminables du type /Users/matt/Local Sites/.... Le terminal adore les espaces dans les chemins autant qu’un développeur adore les bugs intermittents.

Alternative : modifier sql_mode globalement dans LocalWP

Si vous préférez lancer l’import avec une commande shell classique, vous pouvez modifier temporairement le mode global, puis reconnecter MySQL ou relancer l’import.

SET @@GLOBAL.sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';Langage du code : CSS (css)

Ensuite, quittez MySQL :

exitLangage du code : PHP (php)

Puis relancez l’import depuis le shell :

mysql -u root -proot local < ./adminer.sql

Cette méthode fonctionne, mais je préfère la modification de session avec SOURCE. Elle limite l’effet au terminal courant et évite de modifier le comportement global de MySQL plus longtemps que nécessaire.

Cas particulier : WP-CLI demande un socket MySQL

Dans certains environnements LocalWP, un import avec WP-CLI peut échouer avec une erreur de socket :

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'Langage du code : JavaScript (javascript)

Dans ce cas, récupérez le chemin du socket dans l’onglet Database de LocalWP, puis passez-le à WP-CLI :

wp db import ./adminer.sql --socket="/Users/matt/Library/Application Support/Local/run/xxxx/mysql/mysqld.sock"Langage du code : JavaScript (javascript)

WP-CLI importe les bases via les identifiants définis dans wp-config.php. Sa documentation indique que wp db import utilise DB_HOST, DB_NAME, DB_USER et DB_PASSWORD, et qu’il exécute simplement les requêtes contenues dans le fichier SQL. :contentReference[oaicite:3]{index=3}

Si l’erreur Invalid default value for 'comment_date' revient malgré le socket, utilisez plutôt la méthode MySQL avec modification de sql_mode dans la session. Elle donne plus de contrôle pendant l’import.

Faut-il modifier le dump SQL directement ?

Vous pouvez corriger le dump SQL, mais je ne le ferais pas en première intention.

Un fichier SQL volumineux peut contenir des milliers de lignes, des chaînes sérialisées, des données d’extensions, des commentaires, des commandes WooCommerce, des logs et des tables personnalisées. Une modification globale mal ciblée peut créer plus de problèmes qu’elle n’en résout.

Si vous devez vraiment modifier le dump, travaillez sur une copie :

cp adminer.sql adminer.fixed.sqlLangage du code : CSS (css)

Puis cherchez les définitions problématiques :

grep -n "comment_date" adminer.fixed.sql | headLangage du code : JavaScript (javascript)

Dans beaucoup de cas, il est plus simple et moins risqué de laisser le dump intact, d’assouplir temporairement sql_mode pour l’import local, puis de corriger les données dans WordPress après import si nécessaire.

Après l’import : remplacer les URLs de production

Une fois la base importée, elle contient souvent encore l’URL de production. Vérifiez d’abord les options principales :

wp option get home
wp option get siteurlLangage du code : JavaScript (javascript)

Si elles pointent encore vers le site en ligne, lancez un remplacement avec WP-CLI. Commencez toujours par un test à blanc :

wp search-replace 'https://www.example.com' 'https://example.local' --dry-runLangage du code : JavaScript (javascript)

Puis lancez le remplacement réel :

wp search-replace 'https://www.example.com' 'https://example.local'Langage du code : JavaScript (javascript)

WP-CLI gère les données sérialisées, ce qui évite les dégâts classiques d’un remplacement SQL brut. Pour la procédure complète, voir l’article dédié : importer une base de données dans Local depuis le shell.

Après l’import : régénérer les permaliens

Après un import de base WordPress, régénérez les règles de réécriture :

wp rewrite flush

Puis testez quelques URLs dans le navigateur :

• la page d’accueil ;
• un article ;
• une page ;
• une catégorie ;
• l’administration WordPress ;
• le panier et le checkout si WooCommerce est installé.

Si les contenus renvoient des 404, vérifiez la structure des permaliens dans Réglages > Permaliens, puis enregistrez une fois les réglages sans forcément les modifier.

Nettoyer le fichier SQL après import

Un dump SQL WordPress peut contenir beaucoup de données sensibles : emails, comptes utilisateurs, commandes WooCommerce, adresses, tokens, réglages d’extensions, formulaires, voire clés API.

Ne laissez pas le fichier SQL dans le dossier public du site local. Une fois l’import terminé, supprimez-le :

rm adminer.sqlLangage du code : CSS (css)

Si vous avez aussi une archive compressée :

rm adminer.sql.gzLangage du code : CSS (css)

En local, le risque paraît faible. Mais prendre de bonnes habitudes évite de laisser un dump complet au mauvais endroit le jour où vous travaillez sur un staging public.

Besoin d’aide pour réparer un import WordPress ?

Checklist de dépannage

• Ouvrir le site dans LocalWP.
• Lancer Open Site Shell.
• Vérifier que le fichier SQL est accessible.
• Tester l’import avec WP-CLI ou MySQL.
• Si l’erreur Invalid default value for 'comment_date' apparaît, vérifier @@SESSION.sql_mode.
• Retirer temporairement NO_ZERO_DATE et NO_ZERO_IN_DATE.
• Importer le dump dans la même session MySQL avec SOURCE.
• Remplacer l’URL de production avec wp search-replace.
• Régénérer les permaliens avec wp rewrite flush.
• Tester le site local.
• Supprimer le dump SQL après import.

FAQ : erreur Invalid default value for comment_date dans LocalWP

Pourquoi LocalWP affiche Invalid default value for comment_date ?

LocalWP utilise un environnement MySQL plus strict que certains anciens hébergements. Si votre dump WordPress contient des dates à zéro comme 0000-00-00 00:00:00, MySQL peut refuser l’import avec cette erreur.

Est-ce que ma base WordPress est corrompue ?

Pas forcément. L’erreur indique souvent une incompatibilité entre l’ancien dump SQL et le mode strict de MySQL. Le dump peut être importable après ajustement temporaire de sql_mode.

Faut-il désactiver définitivement le mode strict MySQL ?

Non. Pour un import local, modifiez plutôt sql_mode temporairement dans la session MySQL. Cela suffit à importer le dump sans affaiblir durablement la configuration.

Pourquoi WP-CLI affiche aussi une erreur de socket MySQL ?

WP-CLI peut chercher MySQL via /tmp/mysql.sock, alors que LocalWP utilise un socket interne différent. Récupérez le chemin du socket dans l’onglet Database de LocalWP, ou utilisez MySQL directement depuis Open Site Shell.

Puis-je corriger le fichier SQL avec un rechercher-remplacer ?

Oui, mais seulement avec prudence et sur une copie. Dans la plupart des cas, il vaut mieux ajuster temporairement sql_mode, importer la base, puis corriger les données dans WordPress si nécessaire.

Que faire après l’import de la base dans LocalWP ?

Remplacez l’URL de production par l’URL locale avec wp search-replace, régénérez les permaliens avec wp rewrite flush, testez le site, puis supprimez le dump SQL du dossier public.

Sources

• Documentation MySQL : Server SQL Modes
• Documentation MySQL 8.0 : SQL Mode FAQ
• Documentation WP-CLI : wp db import
• Documentation WP-CLI : wp search-replace
• Documentation WP-CLI : wp rewrite flush
• SkyMinds : importer une base de données dans Local depuis le shell

Report a typo