- Statut : non résolu
- Ce sujet contient 10 réponses, 2 participants et a été mis à jour pour la dernière fois par
, le il y a 12 années et 4 mois.
-
Messages
-
Bonjour,
Ma configuration WP actuelle
– Version de WordPress : 3.1.4
– Version de PHP/MySQL : 5.2.0
– Thème utilisé : privé, inspiré de bootstrapwp
– Extensions en place : Custom Contact Forms, Custom Post Type UI, Log Deprecated Notices, Secure WordPress, The Events Calendar, WordPress Database Backup, WP Security ScanProblème(s) rencontré(s) :
Bonjour,
En me rendant dans le panneau d’administration, j’ai ces erreurs PHP :
Warning: call_user_func_array() [function.call-user-func-array]: Unable to call swUtil::addDashboardWidget() in ../wp-includes/plugin.php on line 395
Warning: call_user_func_array() [function.call-user-func-array]: Unable to call wpssUtil::addDashboardWidget() in ../wp-includes/plugin.php on line 395
Warning: Cannot modify header information – headers already sent by (output started at ../wp-includes/plugin.php:395) in ../wp-includes/functions.php on line 850
Warning: Cannot modify header information – headers already sent by (output started at ../wp-includes/plugin.php:395) in ../wp-includes/functions.php on line 851Je précise que :
– l’encodage ne semble pas correct puisque ça indique, par exemple, « Catégories ». Cependant, ça ne concerne que la rubrique « Tableau de bord » ;
– les messages d’erreurs n’apparaissent que dans « Tableau de bord » ;
– il n’y a aucune espace dans ces fichiers functions.php et plugin.php au début et à la fin des documents ;
– la réponse à Unable to call wpssUtil::addDashboardWidget() donnée par Websitedefender reste un mystère puisqu’il est impossible de trouver ce bout de code if (in_array($_right, $tooManyRights)) dans libs/functions.php file on line 253 du plugin en question ;
– les fonctions ayant été créées dans le fichier functions.php de mon thème pour modifier le panneau d’admin (notamment des ajouts de colonnes) ont été désactivées pour vérifier si elles étaient en cause. Et ce n’était pas le cas ;
– les deux derniers messages d’erreurs Warning: Cannot modify header information ne sont plus reproduits une fois qu’on a parcouru d’autres rubriques du panneau d’administration. Idem pour les erreurs d’encodage ;
– la désactivation des plugins Secure WordPress et WP Security Scan suppriment ces messages d’erreurs (mais c’est justement bien ennuyant que ce soient eux qui soient visés !) ;
– enfin, certaines réponses glanées ici et là parlent d’une mise à jour nécessaire de WordPress. Or, pour des raisons techniques, le serveur hébergeant le site est limité aux versions 5.2.0 pour MySQL et PHP.J’aurais donc aimé savoir si la dernière remarque pouvait être la véritable cause ou s’il y avait une raison autre possible qui n’aurait pas été découverte
La version du php et du MySql ne peuvent pas être les mêmes. Il manque une info. Et essaie avec un thème par défaut en désactivant tous les plugins.
Oups, erreur sur MySQL, c’est la 5.0.
Sinon, en ayant désactivé toutes les extensions et avec le thème par défaut, je n’ai plus ces erreurs. Par contre, c’est en remettant les deux plugins de sécurité Secure WP et WP Security Scan que me reviennent les alertes. Et celles commençant spécifiquement par Warning: Cannot modify header information me semblent liées à la première connexion (j’ai vidé le cache de mon navigateur et les cookies pour vérifier).
Bon, ben le second nécessite php 5.2.9 donc ça peut expliquer bien des choses. Et le premier n’est pas mis à jour… Attention avec ce genre de plugins ! Ils sont à manier avec précaution.
PHP 5.2.9 ? Je suis surpris car sur le site de WordPress, à la page des plugins, la version minimum WP requise est la 3.0
Et si je les supprime pour chercher à les rajouter, je n’ai aucun avertissement d’incompatibilité avec la 3.1.4.
Je ne comprends pas… 😕
Les plugins ne respectent pas les minimums exigés par WP. Il y avait de nombreux plugins qui demandaient php5 pour fonctionner avant que WP ne l’exige. C’est assez logique vu qu’ils ont pour objectif d’aller un peu plus loin que ce que propose WP.
Ok mais dans ce cas, quels plugins étaient utilisés quand on utilisait la version 3.1.4, enfin comment faisaient les utilisateurs pour protéger leur site ? Si tu as des suggestions, je suis preneur car j’ai cherché mais je n’ai trouvé aucune extension satisfaisante.
Les plugins ne sont pas obligatoires pour protéger son site. Pour ce que j’ai lu sur le Web, avoir un hébergeur très prudent est déjà une bonne chose -mon hébergeur limite beaucoup de choses genre connexion ftp venant de l’étranger. Ces dernières années, les attaques les plus importantes sur les sites WP ont pris les formes suivantes:
– utilisation d’un thème payant piraté
– faille chez l’hébergeur
– passage par un script connu avec une faille -TimThumb qui a été utilisé par de nombreux plugins
– passage par un cheval de troie ciblant Filezilla
– distribution d’un plugin destiné à pirater le site – la dernière attaque sérieuse qui a fait parler d’elle puisqu’elle est à l’origine du virus qui a touché Apple.La vraie sécurité est encore de réaliser des sauvegardes régulières de son site et sa base de données – un hébergeur qui s’en charge quotidiennement en plus c’est mieux – pour pouvoir faire un nettoyage complet en cas de problème. Perso, je n’ai installé qu’un plugin empêchant les attaques brutales sur le site (Login Lockdown). Et si je devais en rajouter un ce serait une analyse des modifications des fichiers WP.
Mais il est bien connu que la première priorité, c’est une mise à jour de son installation WP… ce que tu n’as même pas fait. Un peu paradoxal, non ?
Des tutos donnent des indications de précaution sans passer par des plugins – genre modifier le préfixe de la base de données lors d’une nouvelle installation.Je te remercie pour toutes ces précisions sur les attaques ciblées et les conseils prodigués pour une sécurité optimale.
Concernant maintenant spécifiquement le paradoxe que tu as soulevé, la raison est assez simple : il ne m’est pas possible de faire une mise à jour de WP, le site est un site institutionnel, il est soumis à des contraintes d’hébergement mutualisé établies par la Direction informatique, donc en l’occurrence 5.0 pour SQL et 5.2.0 pour PHP.
Le préfixe de la base de données a été néanmoins modifié, c’est la première chose que j’avais effectuée en installant WP.
Mais je dois avouer que c’est tout de même une situation particulière car la maintenance technique et de la sécurité du site n’est pas dans le périmètre de la DSI. Néanmoins, le site est hébergé sur leurs serveurs. C’est, disons, ça le paradoxe : un site rattaché à l’institution en question mais indépendant dans son fonctionnement et sa politique éditoriale…
Autant dire que c’est quasi peine perdue de s’escrimer à vouloir optimiser la sécurité. C’est comme si on demandait à un vigile armé d’un balai de surveiller une banque si je peux me permettre 🙂 Ou alors se passer de WP pour utiliser un moteur maison.
J’ignore comment est utilisé WP ici mais tu peux même n’autoriser qu’une adresse IP à pouvoir se connecter dans l’admin 🙂
- Vous devez être connecté pour répondre à ce sujet.