Fatal error: Maximum execution time of 30 seconds exceeded in /wp-content/plugins/woocommerce/includes/export/class-wc-csv-batch-exporter.php. Ce message apparaît toujours au même stade d’un export de commandes volumineux, sur un hébergement mutualisé où la commande WP-CLI n’est pas disponible et où l’accès à php.ini est verrouillé par l’hébergeur.
Le réflexe habituel — augmenter max_execution_time dans un fichier de configuration — se heurte ici à un mur : sur un mutualisé standard, ce réglage est souvent forcé côté serveur et ignore silencieusement toute tentative de surcharge locale. Voici où se situe réellement la limite dans ce contexte, et comment contourner le blocage sans jamais avoir la main sur la configuration PHP, sans entrer dans l’optimisation de la requête SQL sous-jacente elle-même.
Symptôme : l’export s’arrête toujours au même volume de lignes
Le comportement est identique à chaque tentative : l’export démarre normalement, la barre de progression avance, puis le processus s’interrompt brutalement autour de 2 000 à 3 000 commandes exportées selon la complexité des métadonnées associées à chaque commande. Le fichier CSV généré est incomplet, tronqué au milieu d’une ligne.
- L’export fonctionne sans problème sur un petit volume de test
- Le blocage survient toujours après une durée constante, jamais un volume fixe
- Aucune erreur n’apparaît côté navigateur avant le timeout complet
- Le journal d’erreurs PHP confirme un dépassement de
max_execution_time
Diagnostic : où se cache réellement la limite
Sur un hébergement mutualisé, la limite d’exécution PHP n’est presque jamais un simple paramètre modifiable via ini_set() dans le code de l’extension. WooCommerce tente bien d’appeler set_time_limit(0) pendant l’export par lots, mais de nombreux hébergeurs désactivent cette fonction ou la surchargent au niveau du pool PHP-FPM lui-même, rendant l’appel inopérant.
Il faut donc vérifier, avant toute chose, si set_time_limit figure dans la liste des disable_functions de l’hébergeur. Une simple vérification via une page de diagnostic (jamais publiée en production, uniquement en test) permet de confirmer l’hypothèse.
<?php
echo ini_get('disable_functions');
echo ini_get('max_execution_time');
Correctif : découper l’export en lots plus petits
WooCommerce réalise déjà ses exports par lots (batches) en arrière-plan via des requêtes AJAX successives, chaque appel traitant un nombre limité de commandes. Le problème survient quand la taille de lot par défaut reste trop élevée pour la limite de temps réellement appliquée par l’hébergeur. Réduire cette taille de lot via un filtre dédié permet de rester systématiquement sous le seuil.
add_filter( 'woocommerce_export_batch_size', function( $taille ) {
return 100; // au lieu des 500 par défaut
});
Cette réduction ralentit l’export global, puisqu’il nécessite davantage d’allers-retours, mais chaque lot individuel reste largement sous la limite de 30 secondes, ce qui élimine le blocage sans jamais toucher à la configuration serveur.
Alternative : passer par WP-CLI si disponible
Quand l’hébergeur propose un accès SSH avec WP-CLI, même limité, l’export en ligne de commande contourne totalement la limite d’exécution du navigateur, puisqu’il n’y a plus de requête HTTP en jeu. La limite de temps PHP en CLI est généralement bien plus permissive, voire absente, sur la plupart des configurations serveur.
wp wc order list --format=csv --fields=id,status,total,date_created > export_commandes.csv
Attention toutefois : cette commande native de WP-CLI ne reproduit pas exactement le même format que l’exportateur CSV natif de WooCommerce, ce qui peut nécessiter un ajustement du script d’import cible si celui-ci attend une structure de colonnes précise.
Prévention : anticiper avant que le volume ne devienne critique
Un site dont le volume de commandes croît régulièrement finira, tôt ou tard, par heurter cette limite si rien n’est anticipé. Documenter la taille de lot adaptée dès la mise en production, plutôt que d’attendre l’échec en conditions réelles, évite une intervention en urgence au moment où l’export devient réellement nécessaire, souvent en fin de mois pour la comptabilité.
Sur les sites que nous suivons, nous fixons systématiquement une taille de lot d’export inférieure à la limite théorique de l’hébergement, avec une marge de sécurité d’au moins 30 %, plutôt que d’attendre l’incident pour ajuster.
En résumé
Sur un hébergement mutualisé, la limite d’exécution PHP se contourne rarement en modifiant une configuration inaccessible : elle se contourne en réduisant la taille des lots traités à chaque appel, ou en passant par WP-CLI quand l’accès est disponible. Le vrai correctif n’est jamais de forcer un paramètre serveur verrouillé, mais d’adapter le comportement applicatif à la contrainte existante.
