D'avance, qu'on me pardonne si cette question a déjà été posée mille et une fois, mais j'ai le cerveau enflé à force de me cogner la tête sur ce problème.
J'ai une install WampServer 2.2 x64 avec Apache 2.2.21 (version active) et 2.4.2 et deux versions de PHP 5.3.8 et 5.4.3 (active). Pour bien comprendre, j'ai dû installer une deuxième version de Apache et PHP parce que l'install précédente avait un gros souci à faire tourner SilverStripe, mon CMS.
Bref, aujourd'hui, l'exécution de certaines pages s'arrête sur un simple warning que je reproduis ici: [Warning] file_get_contents() expects parameter 1 to be a valid path, array given
Je crois savoir qu'il faut mettre error_reporting = E_ALL & ~E_NOTICE.
Je l'ai fait dans le PHP.ini que le menu contextuel WampServer m'ouvre mais rien n'y fait, je continue de tomber sur ce warning.
En faisant une recherche sur les fichiers .ini qui contiennent la chaîne "error_reporting = ", je me rend compte qu'il y en a 6 dans le dossier d'installation de WampServer…
Quelqu'un aurait-il la gentillesse de me dire lequel est effectivement pris en compte par Apache ? Entre les phpForApache.ini et les php.ini qui se trouvent dans apacheX.X.X\bin, je me perds.
Le fichier php.ini actif est celui situé dans la branche Apache active, c'est à dire, si ous tournez avec Apache 2.2.21 : "wamp\bin\apache\apache2.2.21\bin\php.ini"
Le fichier "wamp\bin\php\php5.4.3\php.ini" sert lors de l'exécution de PHP en ligne de commande ou en mode CGI.
Le fichier "wamp\bin\php\php5.x.y\phpForApache.ini sert lors du basculement de versions de PHP d'une part pour sauvegarder le php.ini en cours avant basculement de version et, d'autre part à créer le nouveau php.ini actif de la nouvelle version de PHP.
> Bref, aujourd'hui, l'exécution de certaines pages s'arrête sur un simple warning que je reproduis ici: > [Warning] file_get_contents() expects parameter 1 to be a valid path, array given
Vouloir masquer les avertissements n'enlèvera en rien les erreurs de programmation, je vais même aller plus en disant qu'en développement il est impératif d'utiliser : error_reporting = E_ALL | E_STRICT pour PHP 5.3 error_reporting = E_ALL pour PHP 5.4
Il vous faut regarder pourquoi il y a un tel avertissement et effectuer les corrections en conséquence.
Merci de toutes ces explications. Je les ai copiées dans un fichier texte en local.
> Vouloir masquer les avertissements n'enlèvera en rien les erreurs de programmation. Je suis parfaitement d'accord et si cela avait été mon code, je l'aurais corrigé car je ne laisse aucun warning quel que soit le langage utilisé. Mais là, il s'agit du code du CMS, ce même code remplissait parfaitement avec PHP 5.3 la tâche qui génère maintenant des avertissements avec la 5.4.
Me lancer dans une correction du code de SilverStripe ne serait pas très futé, n'est-ce pas ?
PHP 5.4 est beaucoup plus strict quant au respect des règles de programmation que ne l'est PHP 5.3.(1) Dans votre cas, il semblerait que le paramètre passé comme chemin de fichier soit un tableau. Cela peut se produire si le chemin du fichier contient des espaces ou des caractères accentués ou des caractères qui peuvent être considérés comme spéciaux par PHP. C'est pourquoi il est recommandé d'utiliser urlencode(). Il serait quand même bon de chercher pourquoi il y a l'avertissement et faire un rapport de bug à SilverStripe.
(1) Par exemple :
replace_texte(trim(messages_reponse[$i]), false));
avec la fonction replace texte c omme suit :
function replace_texte(&$texte, $censure=true){...
Ne génère aucun avertissement (Même en mode strict) avec PHP 5.3 alors qu'il y a l'avertissement : Strict Standards: Only variables should be passed by reference in ... avec PHP 5.4
En fait, je me rends compte que j'avais déjà rencontré ce problème et que j'avais commencé par corriger. Et effectivement, le paramètre est parfois un tableau, parfois une chaîne et les codeurs ont laissé à PHP le soin de se dépatouiller avec ce qui lui est fourni. Comme PHP 5.4 râle, j'avais utilisé un is_array pour agir en conséquence.
Quelle plaie, je n'ai pas d'autre choix que de continuer, d'autant que SilverStripe 3 est sorti il y a quelques semaines (bien sûr, après que mon stagiaire a commencé à travailler sur la version précédente 2.4 sinon ça n'aurait pas été drôle) et que la communauté SilverStripe n'est pas des plus réactives… J'aurais mieux fait d'opter pour un WordPress ou un Joomla, je pense.