Est-ce que vous avez PHP 7 sur votre hébergement ?

Pour avoir un site avec un fonctionnement toujours optimal, il faut pouvoir se tenir régulièrement à jour (même si ça vous agace). Est-ce que vous savez quelle est votre version de PHP ? Faisons ensemble le point…

Le jeudi matin j’optimise mon site

Et oui c’est un genre de tradition de mon côté… chaque jeudi matin est dédié à l’optimisation de mon site pour le rendre plus agréable et performant. Cela fait déjà un moment que je voyais chez mon hébergeur que ma version de PHP 5.6 devait être mise à jour… (mais comme toujours, pas le temps… mieux à faire).

Alors, comme hier j’étais motivé… je me suis dit que j’allait changer ma version de PHP, car il faut savoir que cette nouvelle version est plus rapide et plus performante… En théorie PHP 7 peut être 2x plus rapide… alors pourquoi s’en priver ? De mon côté je suis chez l’hébergeur Infomaniak et la manipulation est assez simple, il suffit dans back-office de switcher de version. La grande question c’est bien sûr est-ce j’ose le faire ou ça va tout planter ?

PHP 7 chez Infomaniak
Dans les propriétés de votre hébergement, vous pouvez modifier la configuration PHP en un clic (cela dépend de votre hébergeur).

Est-ce que le site m’a explosé à la tête ?

En ce qui concerne le site Webbax principal sous WordPress, tout s’est bien passé à première vue… j’ai pas eu besoin de faire d’adaptations, il a supporté PHP 7 à merveille. Par contre, il faut dire aussi que j’utilise actuellement la dernière version de WordPress et que je fais chaque mise à jour (rappelez-vous, je me suis déjà fait hacké).

Pour ma boutique Prestashop en version 1.6 par contre, là y’a eu plantage… j’ai dû activer le mode débugage pour voir les erreurs et j’ai appliqué un patch vu sur le forum Prestashop. A noter que je n’ai pas mis en place la version PHP 7.1, car à première vue ça semblait trop « foireux » (vous aimez quand je dis ça hein ?). Mis à part cette correction, le reste à l’air de fonctionner… mais faudra voir à l’usage.

Et sinon en ce qui concerne mon site « todolist » qui stocke mes idées… c’était plutôt la « galère totale »… en fait c’est un script PHP open source, mais qui n’est pas compatible PHP 7… J’ai bidouillé un peu le truc, mais sans succès. Finalement, j’ai dû créer un sous domaine pour ce site et j’ai appliqué une version PHP différente pour ce sous domaine (on peut le faire avec Infomaniak…. merciiiii).

Ram du serveur Infomaniak
En fait juste après ce changement j’ai vu que ma mémoire RAM s’était libérée, alors j’étais tout content, car je me suis dit que mon serveur allait avoir un meilleur répondant avec plus de ressources.
Infomaniak RAM saturation
Avec le recul je me rends compte déjà qu’aujourd’hui la zone verte a totalement disparu. J’ai pas encore vraiment diagnostiqué si j’ai un problème dans mes processus ou si tout simplement mon site est un gros glouton.
Plusieurs versions de PHP Infomaniak
Sur le même hébergement on peut avoir un sous-domaine avec une version PHP différente du domaine principal. Cela me rend bien service, car je ne peux pas migrer cet outil…

Ce que vous devez faire

Alors cela donne lieu à une autre question est-ce que vous devez migrer en PHP 7 ? A l’heure actuelle il n’y a pas d’obligation… mais c’est pour éviter surtout d’être à la traîne… car si on ne fait rien à force on est dépassé à tous les niveaux. La manipulation est facile et vous pouvez le faire vous-même et vous pouvez revenir en arrière très facilement en 1 seul clic.

Mon conseil serait donc de vous dire d’essayer de faire le basculement et si votre site plante… vous remettez l’ancienne version. En cas de plantage, il faudra chercher la source de l’erreur en vous aidant de Google ou en faisant appel à un spécialiste de la plateforme que vous utilisez. Ou sinon, vous jouez la montre et vous attendez encore, jusqu’à quand votre hébergeur vous « oblige » à faire la migration (pour le moment… c’est une recommandation).

Explications d'Infomaniak PHP7
Comme l’explique Infomaniak dans sa documentation… « normalement » si on a de la chance tout fonctionne. Le problème c’est souvent qu’une seule ligne de code suffit à faire planter tout le processus de fonctionnement d’un site ou d’une boutique. Il est donc important après le basculement, de faire un test global des fonctionnalités que vous avez l’habitude d’utiliser.

Bilan

Vous voulez que je vous dise le pire dans la journée de hier ? A 18h30 quand je devais boucler le bureau… je me dis que je vais noter une idée dans mon site todolist… et je me rends compte à ce moment-là que j’avais oublié de le tester et qu’il ne marche plus du tout « Fatal Error ».

Ahahah c’est toujours le genre de truc « usant »… car bien sûr on voit ça quand on est à la bourre. Si vous avez envie de faire la migration, faites le à un moment où il y’a moins de trafic sur votre site… et surtout à un moment où vous êtes calme. Bonne migration à tous !

Notez mon billet, Google va adorer :
1 étoiles - J'aime pas !2 étoiles - Bof !3 étoiles - Bien !4 étoiles - Très bien !5 étoiles - Génial ! (3 votes, moyenne : 3,67 sur 5)
Loading...

16 commentaires sur “Est-ce que vous avez PHP 7 sur votre hébergement ?”

  1. Bonjour,

    Intéressant retour qui tombe à pic pour moi.

    Je suis justement passé à php 7 il y a moins de 2 mois sur un presta 1.6.1.17, mais suite à cela je rencontre un problème de page qui ne se charge pas de façon aléatoire tant en front qu’en back office.

    J’ai consulté les logs d’erreur serveur pour ce NDD et il semble y avoir un problème avec fastcgi.

    je m’explique :

    Je suis chez phpnet, lors de l’upgrade vers php7 on doit selectionner
    – fastcgi ou cgi

    J’ai donc sélectionné fastcgi.

    Cependant le rapport error.log du NDD en question m’indique régulièrement ces deux erreurs en masse :
    – (70008)Partial results are valid but processing is incomplete: mod_fcgid: can’t get data from http client, referer: urldelapage

    et

    – mod_fcgid: read data timeout in 240 seconds, referer: urldelapage
    Premature end of script headers: index.php, referer: urldelapage

    et plus rarement:
    – (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server
    – 22)Invalid argument: mod_fcgid: can’t lock process table in pid 24102

    le problème semble venir exclusivement de fastcgi.

    J’ai contacté l’hébergeur pour avoir leur avis, j’espère avoir une réponse prochainement.

    Peut-être dois-je renseigner une fonction dans le htaccess ou autre, I don’t know…

    Je vous invite à checker vos logs car j’ai mis un bout de temps à m’en rendre compte car le site fonctionne parfaitement mais de temps en temps il faut recharger la page ou attendre le time out à 240 secondes pour afficher une belle erreur 500 indiquant [no adress given].

    Pas top pour les clients…

    Les sites sous wordpress ne souffrent pas des mêmes problèmes et ne bloquent pas la navigation de l’utilisateurs donc soucis secondaires, juste quelques Plugins à bricoler.

    Bonne continuation

    1. Hello,

      Concernant le message « Premature end of script headers » celui-ci n’est pas forcément évident à détecter et j’en ai déjà fait l’expérience plusieurs fois. Pour ce type d’erreur obligé de trouver déjà un processus qui permet de reproduire le problème à chaque fois, puis ensuite il faut désactiver chaque module, chaque couche pour comprendre l’origine du soucis (le problème n’est pas forcément FastCGI).

      Disons qu’en principe quand je vois ce genre de message, je sais que je vais devoir creuser et j’espère toujours avoir un peu de chance pour localiser rapidement l’emplacement du soucis.

      A bientôt !

  2. Merci pour cet article.

    Personnellement cela fait déjà quelques temps que je suis passé en PHP 7, je devais avoir la version 1.6.10 de Prestashop si je me souviens et je n’ai eu aucun soucis. Par contre c’est avec WordPress que j’ai eu souci, j’ai dû désactiver un plugin pour afficher le Captcha pour que mon site remarche…

    Comme quoi, chacun peut avoir une expérience différente…

    1. Hello,

      C’est exact, cela va dépendre de la personnalisation du site ou de la boutique ainsi que le nombre de modules / plugins installés. On en revient toujours à un point important, moins on charge un site, plus on a de souplesse et on diminue le risque de conflits / incompatibilités.

      A bientôt !

  3. Bonjour,

    Merci je me sens moins seul…

    Après échanges avec l’hébergeur cela semblait bien venir de fastCGI. Je suis repassé en CGI et plus d’erreurs de ce type.

    Peut-être un module bancal de presta ou autre. Je n’ai pas vu de différence de perfs flagrantes avec le passage en CGI.
    Pas spécialement envie de perdre du temps sur ce type de problème.

    Juste cette erreur qui revient :
    (70008)Partial results are valid but processing is incomplete: Error reading request entity data, referer: url

    Due à quelques ip qui génèrent cette erreur en masse mais ça doit être des bad bots vu le nombre de pages vues et la vitesse de navigation par exemple :

    92.154.10.113 localisée a Neuilly en France, 96 erreurs réparties de 10h43 à 16h47…
    85.90.19.1 Un petit gars de chez vous mais moins acharné ça reste donc isolé à quelques ip douteuses.

    Voilà pour les personnes qui rencontreront le même problème que moi, en PHP 7, repassez en CGI.

    Bonne continuation et surtout poursuivez vos articles. 😉

    1. Bonjour,

      Effectivement vous soulevez encore un point intéressant…

      Cela rappelle aussi qu’il est important de penser à suivre les logs du serveur lorsqu’on fait une migration de PHP. Parfois lorsqu’on teste les processus… on le fait en surface et on ne se rend pas compte que d’autres utilisateurs rencontrent des erreurs fatales (peut-être même dans d’autres emplacement du site qu’on a oublié de tester). C’est toujours bien d’avoir un oeil dessus… mais encore faut-il pouvoir comprendre l’erreur.

      Merci pour le retour d’expérience concernant fastCGI.

      A bientôt !

  4. Bonjour ,
    Concernant les performances de vos sites, avez vous noter une amelioration flagrante apres le changements de version php sur prestashop ?
    Merci d’avance de vos reponses

    1. Bonjour,

      Sincèrement pas autant qu’avec un module de cache dédié (ex. Module Prestashop Page Cache). Dans les cas clients que j’ai observés avec PHP7 la différence du gain de temps au chargement de page n’était pas flagrante.

      A bientôt !

  5. Bonjour,
    j’ai besoin de votre aide, je rencontre un problème sur mon site, je pense lié au php qui me cause des problèmes en base de données. Je n’arrive pas à avoir des réponses claires et précises de mon hébergeur planethoster. En effet, selon que je me trouve sur les infos de mon serveur (php 7.0.30), ou dans version php du système (php 5.6), ou depuis les informations de prestashop (php 5.6.36), j’ai des versions différentes de php. Je suis sous prestashop 1.6.1.0. Lorsque, en front office, je fais « commander » depis le panier, j’ai une page blanche. En debug, j’ai : Fatal error: Call to undefined method Product::checkAccessStatic() in /home/souriredessaveur/public_html/classes/Cart.php on line 3225. J’ai d’autres erreurs côté back office, aussi. Quels sont vos conseils ? Merci

    1. Bonjour,

      Voilà une réponse comme ça de tête… pour une version Prestashop 1.6 je conseille plutôt la version PHP 5.6, car avec la version 7.0.X il y’a trop de risques d’avoir des erreurs critiques à certains emplacements.

      Il faut donc demander à votre hébergeur la procédure pour downgrader la version PHP dans un premier temps pour tester.

      A bientôt !

      1. Bonjour,
        je suis en php 5.6.36, mon hébergeur me dit qu’à l’endroit où je vois dans le serveur php 7, c’est si je crée un nouveau site qu’il sera automatiquement de base sur php 7. Du coup l’erreur ne viendrait pas de là…

  6. J’ai demandé à mon hébergeur de me mettre à disposition la sauvegarde du 26 mai, car il me semble que l’erreur que j’ai, est peut être dû à l’installation puis la désinstallation de geoip du 26 mai au soir. Est-ce que ça peut être la cause ?
    Merci

    1. Bonjour,

      Difficile de confirmer ce point, mais c’est tout à fait possible oui une extension de ce type peut proposer des conflits de fonctionnement (et aussi potentiellement ralentir le shop).

      A bientôt !

  7. Bonjour,

    Valérie, pour changer de version de PHP avec PlanetHoster, ça se passe depuis le WHM > Software > MultiPHP Manager.
    Par contre, moi aussi je suis bloqué en PHP5.6, la version 7.0 me donne une belle page blanche…
    Je pense que la meilleure solution pour un Prestashop en 1.6 est de rester en 5.6, pour optimiser le chargement, je recommande le module Cache Manager de Presta-Module, un compte avec FasterImage et surtout, un belle opti.

    Ah, merci d’être là Webbax, votre site m’a sorti de plusieurs belles galères…

    1. Bonjour,

      Merci d’avoir apporté cette précision qui aidera certainement d’autres lecteurs. Actuellement pour Prestashop 1.6 je préconise la version PHP 5.6 qui était la version courante lors du développement du projet.

      A bientôt !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *