[Assigné] incompatibilité avec un autre plugin

Bonjour,

Merci d'avoir contacté l'équipe d'assistance WPML,

Vérifier si vous obtenez des erreurs ou des avertissements liés à WPML dans le journal de débogage de WordPress ou dans le journal d'erreurs du serveur lorsque vous rencontrez ce problème. Il se peut que vous ayez besoin du support de votre équipe d'hébergement pour accéder au fichier journal des erreurs du serveur.

Pour activer le journal de débogage de WP, ouvrez votre fichier wp-config.php et recherchez :

define('WP_DEBUG', false) ;

et remplacez-la par :

define('WP_DEBUG', true) ;

// Activer la journalisation de débogage dans le fichier /wp-content/debug.log

define('WP_DEBUG_LOG', true) ;

// Désactiver l'affichage des erreurs et des avertissements, ce qui est recommandé sur un site vivant.

define('WP_DEBUG_DISPLAY', false) ;

@ini_set('display_errors',0) ;

Ensuite, essayez de reproduire le problème et vérifiez si des erreurs ont été enregistrées dans le fichier debug.log dans le répertoire /wp-content/.

Si vous pouvez coller votre debug.log à https://pastebin.com/ et me fournir ce lien, ce serait génial !

Bonjour Nicolas,

Merci pour le suivi,

Le journal de débogage ne montre qu'un type d'erreur de notification lié au plugin « Health Check & Troubleshooting », il s'agit d'un problème connu signalé ici : https://wpml.org/errata/php-error-wp-6-7-notice-function-_load_textdomain_just_in_time-was-called/

Mais cela ne devrait pas être lié à votre cas, car je ne vois aucune erreur fatale qui pourrait expliquer ce comportement,

Vous pouvez essayer de mettre à jour le plugin WPML à la dernière version :
- WPML 4.7
- String translation 3.3

Si cela n'a pas aidé, je suppose que Download Monitor utilise trop de ressources ce qui provoque une erreur de timeout, je dirais que l'étape suivante serait de vérifier si le problème persiste dans un environnement minimal en suivant les étapes suivantes.

1- Désactiver tous les plugins à l'exception de WPML CMS et Download Monitor
2- Passez pour un moment à un thème WordPress par défaut comme Twenty Twenty-one.

Si le problème disparaît, activez les plugins un par un pour voir lequel provoque un problème d'interaction.

Veuillez sauvegarder votre base de données avant d'effectuer le test ci-dessus
Avec mes meilleures salutations,

Bonjour,

J'aimerais vous demander un accès temporaire au wp-admin et au FTP de votre site de test, ce qui me permettra de trouver ces informations pour vous,

Merci de me fournir les étapes à suivre pour reproduire le problème.

Il est important de noter que vous devez sauvegarder votre site et votre base de données avant de procéder, et vous pouvez utiliser un plugin comme Duplicator à cette fin. Voici un lien vers ce plugin : http://wordpress.org/plugins/duplicator/

Si vous ne voyez pas le formulaire ci-dessous, n'entrez pas vos informations d'identification, car elles seront exposées publiquement :

lien caché

Pour des raisons de confidentialité et de sécurité, veillez à ce que votre réponse soit privée.

Hello,

Nous avons trouvé la cause de ce comportement et il n'est pas lié à la compatibilité,

Le problème est lié au serveur, en particulier aux valeurs limites de délai configurées sur votre serveur. Comme 502 est un délai de passerelle, vous avez un serveur (comme un proxy inverse) qui attend trop longtemps et ne reçoit pas de données - ce qui entraîne le délai.

En fait, lorsque nous avons vérifié le journal des erreurs du serveur local (serveur nginx dans ce cas), nous avons trouvé l'erreur suivante enregistrée :

2025/03/07 10:47:07 [error] 32544#32840: *30 upstream sent too big header while reading response header from upstream, client: ::1, server: , request: "GET /wp-admin/edit.php?dlm_download_logs=true&nonce=713c0e6bf8&start_date=2025-02-07&end_date=2025-03-07&user_filters=%5B%5D HTTP/1.1", upstream: "<em><u>lien caché</u></em>", host: "localhost:10497", referrer: "<em><u>lien caché</u></em>"
2025/03/07 10:54:40 [error] 25524#15484: *14 upstream sent too big header while reading response header from upstream, client: ::1, server: , request: "GET /wp-admin/edit.php?dlm_download_logs=true&nonce=713c0e6bf8&start_date=2025-02-07&end_date=2025-03-07&user_filters=%5B%5D HTTP/1.1", upstream: "<em><u>lien caché</u></em>", host: "localhost:10497", referrer: "<em><u>lien caché</u></em>"

Même chose sur un serveur Apache :

ERR_RESPONSE_HEADERS_TOO_BIG

Pourriez-vous vérifier auprès de votre hébergeur :
- Les erreurs de serveur dans les logs du serveur (pas les logs WP, mais les logs PHP/apache/nginx).
- Augmentez LimitRequestFieldSize et LimitRequestLine.
- Si vous utilisez FastCGI, définissez FcgidMaxRequestLen.
- Augmentez les délais d'attente de votre serveur et Reverse Proxy.

Cordialement,

WPML forçait un changement de langue pendant l'exportation, ce qui causait probablement l'interruption de la requête pour les grands ensembles de données.

J'ai compris que lors de l'exportation d'un petit nombre de rapports, les modifications de requêtes de WPML ne causent pas de surcharge significative.
Cependant, pour plus de 1000 rapports, le traitement linguistique de WPML ajoute une complexité supplémentaire à chaque requête de base de données.
Cela surcharge la requête, ce qui peut entraîner un dépassement des limites de l'en-tête.
En conséquence, la requête échoue ou est redirigée au lieu de renvoyer le fichier CSV.

J'ai trouvé une solution à ce problème en empêchant WPML d'interférer avec votre plugin de téléchargement en ajoutant ce code au fichier functions.php du thème :

add_action('init', function() {
    if (isset($_GET['dlm_download_logs'])) {
        global $sitepress ;
        if ($sitepress) {
            remove_all_filters('wpml_current_language') ;
        }
    }
}, 1) ;

J'attends toujours la confirmation de notre deuxième niveau pour voir si ce code a des implications dont nous devrions nous préoccuper,

Je reviendrai vers vous prochainement,