WordPress et hébergement

Cette FAQ repose sur des situations réellement rencontrées dans le support quotidien autour de WordPress, PHP, hébergement, mail, sécurité et maintenance Linux.

Elle aide à reconnaître rapidement un problème, comprendre ses causes probables, utiliser les bons outils de diagnostic et choisir des pistes de résolution réalistes. Chez all2all, nous privilégions une approche durable : WordPress proche du “core”, peu de plugins, thèmes maintenus, standards ouverts, infrastructure Debian moderne et maintenance progressive plutôt que réparations d’urgence.

Une mise à jour PHP casse le site : par où commencer ?

Les symptômes typiques sont une page blanche, une erreur 500, un backend inaccessible, des menus cassés, des erreurs PHP ou certaines pages qui ne chargent plus. Les causes les plus fréquentes sont un vieux plugin, un thème obsolète, un builder ancien, du code personnalisé ou une extension PHP plus supportée.

Commencez par le log Apache/PHP, souvent dans logs/error_log ou ~/logs/error_log. Il peut être consulté via FTP/SFTP, le gestionnaire de fichiers ou Virtualmin. En shell :

tail -50 logs/error_log
tail -f logs/error_log

On peut aussi activer temporairement le debug WordPress dans wp-config.php :

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

Les erreurs apparaissent alors dans wp-content/debug.log. Les solutions possibles sont la désactivation temporaire de plugins, un retour provisoire à une version PHP plus ancienne, le remplacement de composants abandonnés, la mise à jour du thème ou la migration d’un ancien hébergement EOL vers un serveur Debian récent avec plusieurs versions PHP disponibles.

WordPress signale une version PHP obsolète : que faire ?

WordPress peut signaler que la version PHP est obsolète, ne reçoit plus de mises à jour de sécurité ou n’est plus acceptée par certains plugins. Cela indique souvent un ancien hébergement, un site très ancien ou des extensions incompatibles avec PHP moderne.

Vérifiez la version PHP, l’âge du serveur, les dates de mise à jour des plugins et la compatibilité du thème. Les serveurs récents all2all permettent souvent d’utiliser plusieurs versions maintenues, par exemple PHP 8.1, 8.2, 8.3 et 8.4. On peut ainsi tester, mettre à jour, remplacer les composants obsolètes, puis basculer proprement.

Le site est devenu lent : que vérifier d’abord ?

Les causes courantes sont un excès de plugins, des builders lourds, des images trop grandes, des statistiques temps réel, des couches de cache complexes, des synchronisations externes ou des requêtes SQL coûteuses.

Regardez ce qui a changé récemment : ajout d’un plugin, d’un builder, d’une extension WooCommerce, d’un plugin de sécurité ou de statistiques. Consultez les logs PHP pour repérer des warnings répétés. Supprimez les plugins inutiles, simplifiez le thème, optimisez les images et utilisez un cache simple. Les sites les plus maintenables restent souvent proches du WordPress natif.

Un formulaire WordPress n’envoie plus de mails : comment diagnostiquer ?

Un formulaire peut sembler fonctionner sans qu’aucun courriel n’arrive, ou les messages peuvent partir en spam. Les causes habituelles sont mail() sans authentification, SPF/DKIM/DMARC incorrects, un vieux plugin de formulaire, un SMTP refusé ou le filtrage anti-spam moderne.

Vérifiez SMTP, DNS mail, SPF, DKIM, DMARC, le plugin de formulaire et les logs éventuels. Préférez un SMTP authentifié à l’envoi PHP non authentifié. Si le mail du domaine a été déplacé hors all2all, avertissez le support afin que la gestion locale du mail soit désactivée chez nous ; sinon les mails générés sur le serveur peuvent continuer à être routés localement.

Le site affiche une page blanche : quelle cause probable ?

Une page blanche indique généralement une erreur PHP fatale masquée dans le navigateur. Consultez d’abord logs/error_log et, si le debug est activé, wp-content/debug.log. Renommer temporairement wp-content/plugins/ ou le dossier du thème actif peut aider à identifier le composant responsable.

Les solutions sont de désactiver les plugins un par un, tester un thème par défaut, changer provisoirement de version PHP ou remplacer les composants obsolètes. Lisez les logs avant de réinstaller au hasard.

Le site a été piraté ou redirige : que faire ?

Les signes fréquents sont des redirections étranges, du spam, des comptes administrateurs inconnus, des pages modifiées, une charge CPU élevée, des avertissements Google Safe Browsing ou des fichiers inconnus. Contactez d’abord support@all2all.org : nous pouvons évaluer la situation, protéger la plateforme mutualisée et, si nécessaire, créer une archive forensic.

L’infrastructure serveur est gérée par all2all ; le site, les plugins, les thèmes et le code applicatif installés dans le compte relèvent de la responsabilité du client. En pratique, all2all peut souvent mettre le site en mode protégé, inspecter les logs, repérer des processus ou fichiers suspects et contacter les responsables. Le nettoyage peut être fait par le client, un websitebeheerder/webmaster ou all2all sous forme d’intervention facturée selon disponibilité.

Si des données personnelles ont pu être exposées, si du phishing ou une fraude ont eu lieu, ou si l’incident a des conséquences légales, un signalement peut être nécessaire. Une archive et une courte analyse technique peuvent documenter les IP, fichiers modifiés et chronologie probable.

Erreur de connexion à la base de données : quoi vérifier ?

Le message “Error establishing a database connection” pointe souvent vers MariaDB/MySQL indisponible, des identifiants erronés dans wp-config.php, une base manquante, une corruption ou un plugin qui surcharge SQL.

Vérifiez le nom de base, l’utilisateur, le mot de passe et l’hôte dans wp-config.php. Dans Virtualmin, contrôlez que la base et l’utilisateur MySQL existent. Après migration, assurez-vous que wp-config.php utilise bien les nouveaux identifiants.

L’upload d’images échoue : quelles limites ou permissions vérifier ?

Les erreurs d’upload peuvent venir de permissions incorrectes dans wp-content/uploads/, d’un quota plein, de limites PHP, d’un plugin d’optimisation d’images ou d’un cache. Vérifiez le dossier d’upload, l’espace disque et error_log.

Corrigez les permissions, libérez de l’espace, augmentez si nécessaire certaines limites PHP ou désactivez temporairement les plugins d’optimisation/cache.

SSL ou HTTPS ne fonctionne plus : que contrôler ?

En cas de cadenas disparu, certificat expiré, redirections cassées ou “connexion non sécurisée”, vérifiez le DNS, la configuration SSL dans Virtualmin, les logs Let’s Encrypt et les redirections HTTP/HTTPS. Le mixed content peut aussi empêcher l’affichage correct du cadenas.

Si le site possède plusieurs noms de domaine ou alias, chaque nom inclus dans le certificat doit encore être actif et pointer vers le serveur. Un seul alias inactif peut bloquer tout le renouvellement Let’s Encrypt. Renouvelez les DNS concernés, retirez-les de la configuration du certificat ou supprimez l’alias via Virtualmin s’il n’est plus nécessaire.

Pourquoi WordPress demande-t-il un login FTP lors des mises à jour ?

Quand WordPress demande un login FTP pour installer une mise à jour, il ne peut généralement pas écrire directement dans ses fichiers. Les causes sont souvent un mauvais propriétaire, des permissions incorrectes ou un mélange d’utilisateurs FTP/SFTP et PHP/Apache.

Vérifiez le propriétaire et les permissions de wp-content. Corriger l’ownership est préférable à l’ouverture large des permissions.

Les mails WooCommerce n’arrivent pas : où l’envoi peut-il échouer ?

Les mails de commande WooCommerce peuvent échouer à cause d’un SMTP cassé, de SPF/DKIM incorrects, d’un plugin mail obsolète, d’une file d’attente bloquée ou du filtrage par les fournisseurs distants.

Testez l’envoi WordPress standard, l’authentification SMTP et les réglages propres à WooCommerce. Pour une boutique, SMTP authentifié et DNS mail corrects sont fortement recommandés.

Certaines pages ou liens sont cassés : comment les régénérer ?

Erreurs 404, permaliens étranges, menus cassés ou pages vides viennent souvent de .htaccess, des réglages de permaliens, d’un cache, d’un plugin SEO ou d’une migration incomplète.

Régénérez les permaliens, vérifiez .htaccess, videz les caches et consultez le log Apache en cas d’erreur 500.

Pourquoi recommander des sites WordPress avec peu de plugins ?

De nombreux sites deviennent difficiles à maintenir après des années d’accumulation : plugins multiples, builders, widgets, extensions premium abandonnées, couches CSS/JS. Un seul plugin abandonné peut bloquer une mise à jour PHP, les updates sécurité ou tout le site.

Un WordPress sobre, proche du core, avec peu de dépendances et un thème maintenu améliore la sécurité, les performances, la maintenabilité et la pérennité des contenus.

Pourquoi les sauvegardes externes sont-elles importantes ?

Un hébergement n’est pas une stratégie de sauvegarde indépendante. Un plugin peut effacer des données, un hack peut contaminer les backups locaux et une mauvaise manipulation peut être répliquée avant d’être détectée.

Gardez des sauvegardes séparées, idéalement hors du compte hosting, avec plusieurs versions historiques.

Peut-on simplement restaurer un vieux backup ?

Pas toujours. Un vieux backup peut déjà contenir le malware, des plugins vulnérables ou une configuration obsolète. Vérifiez la date réelle du backup, l’état du site à ce moment-là et la compatibilité avec PHP actuel.

Le backup doit souvent être analysé, nettoyé, mis à jour puis restauré progressivement.

Pourquoi les logs sont-ils essentiels ?

Beaucoup de problèmes WordPress semblent mystérieux tant que les logs ne sont pas lus. Ils peuvent indiquer le plugin fautif, la ligne PHP, l’erreur SMTP, la permission incorrecte ou l’incompatibilité exacte.

Les fichiers les plus utiles sont souvent logs/error_log et wp-content/debug.log. Avant de reconstruire un site, lisez les logs, identifiez la cause et corrigez méthodiquement le composant concerné.