Gandi Groupes

Gandi Simple Hosting: Mise à jour PHP et implications

Vous devez être connecté pour poster de nouveaux messages. Créer un compte.

Bonjour,

Comme d'autres j'ai constaté quelques changements suite à la mise à jour
PHP. Et si elle n'est pas la seule, j'ai repéré l'une des causes et le
moyen d'y remédier.

*** Ce qui changé
Avec le passage en version supérieure, sont également stockés dans le
fichier error.log PHP les Warning (alertes PHP) correspondant au niveau
d'erreur E_STRICT (le niveau le plus stricte concernant la syntaxe PHP).

*** Conséquence
De nombreuses alertes qui étaient invisibles et indolores sont désormais
prises en compte. Elles sont également ajoutée au fichier error.log qui
peut très rapidement grossir. Mon instance s'est arrêté lorsque le
fichier à atteint le Giga !

*** Que faire
Il faut donc vérifier que son code est STRICT compatible; pour cela il faut
éditer le fichier php.ini et remplacer la ligne "error_reporting = E_ALL"
par : "error_reporting = E_ALL | E_STRICT"
La version locale de son site fera apparaître toutes les alertes qui
semblent ralentir le site et permettra de les corriger.

Pour ceux qui utilisent des applications tiers, comme un CMS et qui
préfère ne rien toucher, il faudra attendre une mise à jour.

Concrètement la seule alerte qui est apparu dans mon cas, est la
non-déclaration d'un objet.
Pour déclarer l'objet monObjet avec une variable maVariable de valeur "1",
je n'avais qu'une ligne:

  $monObjet->maVariable  = 1;

Ce qui générait l'alerte "PHP Error: Creating default object from empty
value"

Il faut désormais déclarer l'instance de l'objet, ce qui revient à
ajouter la ligne suivante:

  $monObjet = new stdClass();
  $monObjet->maVariable = 1;


Voilà,
Bon courage à tous.
Bonjour Hami

*** Ce qui changé
Avec le passage en version supérieure, sont également stockés dans le
fichier error.log PHP les Warning (alertes PHP) correspondant au niveau
d'erreur E_STRICT (le niveau le plus stricte concernant la syntaxe PHP).

*** Conséquence
De nombreuses alertes qui étaient invisibles et indolores sont désormais
prises en compte. Elles sont également ajoutée au fichier error.log
qui...
Oui effectivement, j'ai vu ça hier et en prime erreur 503, donc pas de site
web accessible (à part la page de l'erreur 503, ce qui veut dire que le
serveur est encore là :-)

L'accès est toujours possible par ftp.

Une question, comment accédez-vous au php.ini ni ou my.cnf sur Simple
Hosting?

Cordialement.
Michel
Une question, comment accédez-vous au php.ini ni ou my.cnf sur Simple
Hosting?
Je n'y accède pas; et comme aucune configuration n'est possible côté
serveur, j'ai du adapter ma configuration locale pour être sûr que tout ce
qui fonctionne chez moi fonctionnera chez eux.

C'est donc mon fichier php.ini que j'ai mis à jour, pour le caler sur la
version du serveur.

Il existe peut-être d'autre manière de modifier le niveau d'erreur PHP,
par exemple via le .htaccess, je l'ignore, mais tant qu'à faire si le mode
E_STRICT permet d'améliorer son code PHP, ce n'est pas peine perdue.
Etes vous vraiment sur gandi hosting ?

Il n'y a pas à ma connaissance *pour l'instant* de php.ini modifiable.
Il y a eu un petit moment ou le error_reporting était plus strict, ce qui
occasiona des effets boule de neige à cause des logs. Et sans redemarrage
de l'instance pas de nouvelle config...

On est en php 5.4.4-2 en error_reporting 22519 E_ALL & ~E_NOTICE &
~E_DEPRECATED
donc normalement pas de souci spécifique en vue.

La plupart des fonctions dépréciées fonctionneront encore, au fur à
mesure des maj php, et disparaitront.

Si votre code est trop vieux, ne l'utilisez plus, c'est dangeureux !
PHP 4 derniere version 2008, PHP 5 existe depuis 2004, bientôt PHP 6...

ciao
C'est donc mon fichier php.ini que j'ai mis à jour, pour le caler sur la
version du serveur.
OK, c'est bien du php.ini local dont vous parlez. Vous l'avez paramétré de
façon à "simuler" la config existante chez Gandi, sur laquelle vous n'avez
pas la main. :-) Compris.
E_STRICT permet d'améliorer son code PHP, ce n'est pas peine perdue.
Je suis d'accord, un code "propre" c'est bien. Mais là, mettre la main dans
Joomla et modifier tout ce qui ne respecte pas le niveau d'exigence du code
attendu, c'est beaucoup, beaucoup de temps à passer à modifier modules et
plugins et même Joomla core (?)... Je préfèrerais, avoir le choix et
"ignorer" les erreurs qui n'ont pas à être interprétées et qui ne
devraient pas mettre le moteur PHP dans les choux.

Cordialement.
Michel
Bonjour,
Des problèmes égalements "visibles" sous Drupal :
Warning : preg_match(): Compilation failed: disallowed Unicode code point
(>= 0xd800 && <= 0xdfff) at offset 2112 dans truncate_utf8() (ligne 339 dans
/srv/data/web/vhosts/XXXX/htdocs/includes/unicode.inc).

Il ne s'agit que d'un Warning, peut être déjà existant avant la mise à
jour de l'instance.

Il s'agit d'un bug connu de Drupal j'ai l'impression que celà dépend de la
version d'une librairie installée sur le serveur.

Cordialement

JP

Le 13 juil 2012 à 16:22 CEST, Hami a écrit :
Bonjour,

Comme d'autres j'ai constaté quelques changements suite à la mise à
jour
PHP. Et si elle n'est pas la seule, j'ai repéré l'une des causes et le
moyen d'y remédier.

*** Ce qui changé
Avec le passage en version supérieure, sont également stockés dans le
fichier error.log PHP les Warning (alertes PHP) correspondant au niveau
d'erreur E_STRICT (le niveau le plus stricte concernant la syntaxe PHP).

*** Conséquence
De nombreuses alertes qui étaient invisibles et indolores sont désormais
prises en compte. Elles sont également ajoutée au fichier error.log qui
peut très rapidement grossir. Mon instance s'est arrêté lorsque le
fichier à atteint le Giga !

*** Que faire
Il faut donc vérifier que son code est STRICT compatible; pour cela il
faut
éditer le fichier php.ini et remplacer la ligne "error_reporting = E_ALL"
par : "error_reporting = E_ALL | E_STRICT"
La version locale de son site fera apparaître toutes les alertes qui
semblent ralentir le site et permettra de les corriger.

Pour ceux qui utilisent des applications tiers, comme un CMS et qui
préfère ne rien toucher, il faudra attendre une mise à jour.

Concrètement la seule alerte qui est apparu dans mon cas, est la
non-déclaration d'un objet.
Pour déclarer l'objet monObjet avec une variable maVariable de valeur
"1",
je n'avais qu'une ligne:

  $monObjet->maVariable  = 1;

Ce qui générait l'alerte "PHP Error: Creating default object from empty
value"

Il faut désormais déclarer l'instance de l'objet, ce qui revient à
ajouter la ligne suivante:

  $monObjet = new stdClass();
  $monObjet->maVariable = 1;


Voilà,
Bon courage à tous.
Bonjour,

Gandi est-il au courant de ce problème ?
Quand vont-ils proposer une mise à jour ??

Mon site est complètement à plat à cause de çà:
http://www.visipure.com/immobilier/immobil...

Merci.
www.visipure.com
Le 13 juil 2012 à 19:25 CEST, xemaps a écrit :
On est en php 5.4.4-2 en error_reporting 22519 E_ALL & ~E_NOTICE &
~E_DEPRECATED
donc normalement pas de souci spécifique en vue.
tout à fait. la conf est la suivante cote logs:
error_reporting = E_ALL & ~E_STRICT & ~E_NOTICE & ~E_DEPRECATED
William
Le 16 juil 2012 à 13:21 CEST, Frederic M a écrit :
Mon site est complètement à plat à cause de çà:


http://www.visipure.com/immobilier/immobil...
le problème que vous indiqué est relatif à votre code qui n'est pas
compatible avec php5.4. Il faut veiller à utiliser la dernière version
disponible de votre appli si c'est un projet externe ou corriger votre code
si le projet vous appartient.
William
Le 16 juil 2012 à 17:33 CEST, William a écrit :
Le 16 juil 2012 à 13:21 CEST, Frederic M a écrit :
Mon site est complètement à plat à cause de çà:




http://www.visipure.com/immobilier/immobil...
le problème que vous indiqué est relatif à votre code qui n'est pas
compatible avec php5.4. Il faut veiller à utiliser la dernière version
disponible de votre appli si c'est un projet externe ou corriger votre
code
si le projet vous appartient.
La version de cette appui est la plus récente. Puis-je remettre mon
instance à la version précédente ?
www.visipure.com
Le 16 juil 2012 à 17:42 CEST, Frederic M a écrit :
La version de cette appui est la plus récente. Puis-je remettre mon
instance à la version précédente ?
Dans certains cas on peut envisager cela histoire de vous laisser un peu
plus de temps pour migrer. Il faut alors passer par une demande support.
William
Le 16 juil 2012 à 19:22 CEST, William a écrit :
Le 16 juil 2012 à 17:42 CEST, Frederic M a écrit :
La version de cette appui est la plus récente. Puis-je remettre mon
instance à la version précédente ?
Dans certains cas on peut envisager cela histoire de vous laisser un peu
plus de temps pour migrer. Il faut alors passer par une demande support.
Bonjour,

Il y a en effet des logs d'erreur... :

[17-Jul-2012 12:26:25 UTC] PHP Fatal error:  Call-time pass-by-reference has
been removed in
/srv/data/web/vhosts/www.djmanuelchino.com/htdocs/wp-content/themes/photolio/functions.php
on line 827
[17-Jul-2012 12:26:25 UTC] PHP Stack trace:
[17-Jul-2012 12:26:25 UTC] PHP   1. {main}()
/srv/data/web/vhosts/www.djmanuelchino.com/htdocs/index.php:0
[17-Jul-2012 12:26:25 UTC] PHP   2. require()
/srv/data/web/vhosts/www.djmanuelchino.com/htdocs/index.php:17
[17-Jul-2012 12:26:25 UTC] PHP   3. require_once()
/srv/data/web/vhosts/www.djmanuelchino.com/htdocs/wp-blog-header.php:12
[17-Jul-2012 12:26:25 UTC] PHP   4. require_once()
/srv/data/web/vhosts/www.djmanuelchino.com/htdocs/wp-load.php:29
[17-Jul-2012 12:26:25 UTC] PHP   5. require_once()
/srv/data/web/vhosts/www.djmanuelchino.com/htdocs/wp-config.php:100

En revanche, je suis débutant en web, pouvez vous me "traduire" le
problème ?
Si je comprends bien le fichier "functions.php" de mon thème wordpress est
à l'origine du problème ?
Michel ABASSI avait prétendu :
Je suis d'accord, un code "propre" c'est bien. Mais la, mettre la main
dans
Joomla et modifier tout ce qui ne respecte pas le niveau d'exigence du
code
attendu, c'est beaucoup, beaucoup de temps 
Faut prendre une instance serveur dédiée alors...
Le 17 juil 2012 à 15:41 CEST, Manu a écrit :
En revanche, je suis débutant en web, pouvez vous me "traduire" le
problème ?
Si je comprends bien le fichier "functions.php" de mon thème wordpress
est
à l'origine du problème ?
Le mieux reste de remonter le problème à l'auteur du plugin en question.
Wordpress possède un support dédié pour chaque plugin.
Dans ce cas précis c'est un problème de compatibilité entre php5.3 et
php5.4
voir http://fr.php.net/manual/en/language.refer...

la solution est de transformer function myFunc(&$arg) en function
myFunc($arg)

en attendant, fixer le problème soit meme peut etre quelque chose comme:
grep '&$' `find . -name '*.php' -xtype f`
sed 's/&$/$/g' lesfichiers.php
William
Le 18 juil 2012 à 12:55 CEST, William a écrit :
Le 17 juil 2012 à 15:41 CEST, Manu a écrit :
En revanche, je suis débutant en web, pouvez vous me "traduire" le
problème ?
Si je comprends bien le fichier "functions.php" de mon thème wordpress
est
à l'origine du problème ?
Le mieux reste de remonter le problème à l'auteur du plugin en question.
Wordpress possède un support dédié pour chaque plugin.
Dans ce cas précis c'est un problème de compatibilité entre php5.3 et
php5.4
voir http://fr.php.net/manual/en/language.refer...

la solution est de transformer function myFunc(&$arg) en function
Merci pour ces précieux renseignements, je remonterai le problème à
l'auteur du thème
myFunc($arg)

en attendant, fixer le problème soit meme peut etre quelque chose comme:
grep '&$' `find . -name '*.php' -xtype f`
sed 's/&$/$/g' lesfichiers.php