OVH Community, votre nouvel espace communautaire.

Testez PHP7 - version stable disponible


amyltessa
11/03/2016, 12h01
Recently one of Cloud hosting providers Cloudways has added PHP 7 on their servers. They have also performed benchmarks with different PHP applications and the applications are pretty fast.

chantoine
15/01/2016, 21h19
Je viens de passer mon site sous SPIP 3.1.0 en PHP 7.0, a priori tout se passe bien.

Jikoo
14/01/2016, 17h33
Citation Envoyé par koeurtra
En effet, j'ai constaté à plusieurs reprises des coupures de service importantes, avec pour résultat une page blanche (même avec une simple page phpinfo) qui reste en chargement pour enfin obtenir :

Page Web inaccessible
ERR_CONNECTION_RESET
J'ai osé utiliser PHP 7 en production sur tout le site depuis plusieurs mois --> Tout va bien. Je n'ai pas d'erreur comme vous.
https://forum.ovh.com/showthread.php...729#post654729

Et merci vcasse pour l'astuce.

vcasse
14/01/2016, 10h36
Bonjour à tous,
.
Petite astuce trouvée dans les vidéos du dernier forum PHP pour la migration vers PHP7.
Rasmus, le créateur de PHP a sorti un outil qui analyse le code et peut remonter les erreurs possibles dues à la migration vers PHP7 :
https://github.com/etsy/phan

Cordialement,
Vincent

koeurtra
07/01/2016, 14h50
Bonjour à tous,

Je suis en train de tester php 7 sur mon site web, il ne s'agit pas d'un CMS mais d'un site réalisé par mes soins.

Sur 1 journée complète j'ai constaté que ma moyenne de temps de chargement des pages (évalué par Google Analytics) est passé de 3,27 secondes à 1,47 secondes ! C'est assez impressionnant toutefois j'hésite encore à rester sur cette version qui me parait instable...

En effet, j'ai constaté à plusieurs reprises des coupures de service importantes, avec pour résultat une page blanche (même avec une simple page phpinfo) qui reste en chargement pour enfin obtenir :

Page Web inaccessible
ERR_CONNECTION_RESET

En repassant à php 5.6 immédiatement en modifiant le fichier .ovhconfig, la page se charge à nouveau tout de suite correctement.

Quelques minutes plus tard, en testant la page phpinfo sur un autre repertoire de mon hébergement avec le fichier .ovhconfig en php 7.0 celle-ci s'affiche bien à nouveau.

Le problème semble assez aléatoire, on dirait que quelque chose plante et qu'il faut qu'un service redémarre.

Quelqu'un a t'il déjà rencontré des soucis de stabilité avec php 7.0.0 ?

Pensez-vous qu'il est possible qu'une des pages de mon site ne soit pas compatible et puisse dégrader ou faire planter un service ?

D'autre part OVH prévoit-il de mettre à jour php 7.0.0 aux nouvelles distribution de php comme 7.0.2 ect...

Merci d'avance pour vos retour car j'aimerai vraiment rester en php 7 au vu des performances, mais ci cette version n'est pas stable je devrai revenir définitivement à la version 5..6.

vcasse
18/12/2015, 10h32
Salut à tous,

Nous ne ferons pas de guide de migration pour une raison : ils sont déjà réalisés, de manière exhaustive, par les équipes de PHP :
http://php.net/manual/en/migration70.php

Et il y a un guide par version
On met juste en avant les points les plus "bloquants".

Cordialement,
Vincent

Gaston_Phone
17/12/2015, 20h53
Citation Envoyé par nitrix-ud
Pour ceux que ça pourrait intéresser voici une classe php qui permet de ne rien faire pour passer de mysql à mysqli
http://www.phpclasses.org/package/91...extension.html

En gros il suffit d'inclure la classe dans les fichiers php qui utilise mysql et les fonctions mysql sont "mappées" en mysqli
Merci nitrix-ud

nitrix-ud
17/12/2015, 20h06
Pour ceux que ça pourrait intéresser voici une classe php qui permet de ne rien faire pour passer de mysql à mysqli
http://www.phpclasses.org/package/91...extension.html

En gros il suffit d'inclure la classe dans les fichiers php qui utilise mysql
include_once('mysql2i.class.php');
et les fonctions mysql sont "mappées" en mysqli

Pratique pour des vieux sites "legacy"

- - - Mise à jour - - -

Personnellement, les choses que j'ai dû modifiées ces derniers mois en vue de php7 :
- bien spécifier le charset pour php quand la page en question n'est pas en utf-8 (déjà indispensable pour php 5.6).
- mysql_ -> mysqli_
- preg_replace /e -> preg_replace_callback
- quelques soucis de lectures de variables comme l'indique vincent plus haut (mais ça n'en concerne que très peu).
j'ajouterais

ereg_replace => preg_replace
ereg => preg_match

chmod777
17/12/2015, 19h30
Citation Envoyé par Gaston_Phone
Merci beaucoup à Vincent (vcasse), chmod777 et nitrix-ud.
De rien.
Sinon, je viens de voir que j'aurais plutôt dû écrire iso-8859-1 au lieu de iso8859-1, même si ça semble fonctionner correctement.


Citation Envoyé par Gaston_Phone
Peut-être pourriez-vous envisager de faire un guide pour expliquer les principales opérations indispensables pour passer de PHP 5.6 à PHP 7.
Personnellement, les choses que j'ai dû modifiées ces derniers mois en vue de php7 :
- bien spécifier le charset pour php quand la page en question n'est pas en utf-8 (déjà indispensable pour php 5.6).
- mysql_ -> mysqli_
- preg_replace /e -> preg_replace_callback
- quelques soucis de lectures de variables comme l'indique vincent plus haut (mais ça n'en concerne que très peu).

Parmi les choses obsolètes à partir de php7.0 :
- "Calling non-static methods statically"
- constructeurs php4.

Après, la liste des changements potentiels est plus longue que ça :
http://php.net/manual/en/migration70.incompatible.php
http://php.net/manual/en/migration70.deprecated.php

janus57
17/12/2015, 19h24
Bonjour,

La suppression des commandes mysql_xxx et son remplacement par les commandes pdo
y a aussi mysqli pour ceux qui ont pas envie de passer à PDO (c'est relativement proches des ancienne mysql_ dans 80-90% des cas).

Exemple tiré de la doc :

mysql_*
Code:
mysqli_*
Code:
Au passage les fonctions mysql_* sont dépréciés depuis un bon moment.

Cordialement, janus57

Gaston_Phone
17/12/2015, 18h33
Citation Envoyé par vcasse
Probablement un soucis causé par le changement de lecture des variables.
Les principaux changements sont expliqués là dedans https://www.ovh.com/fr/news/a1948.ph...-moment-migrer
Merci Vincent pour ce lien fort intéressant.
Peut-être pourriez-vous envisager de faire un guide pour expliquer les principales opérations indispensables pour passer de PHP 5.6 à PHP 7.
Avec entre autre :
- cette histoire de charset à forcer au début de chaque script,
- La suppression des commandes mysql_xxx et son remplacement par les commandes pdo

vcasse
17/12/2015, 17h31
Salut Gaston_phone,

Probablement un soucis causé par le changement de lecture des variables.
Les principaux changements sont expliqués là dedans https://www.ovh.com/fr/news/a1948.ph...-moment-migrer

Cordialement,
Vincent

Gaston_Phone
17/12/2015, 16h48
Citation Envoyé par vcasse
@gaston_phone : donc tu es en php7 maintenant ?
Sur le site en production, je suis en PHP 5.6 et ... grâce à vous tous et plus particulièrement à chmod777 tout fonctionne.

Contenu de mon fichier /www/.ovhconfig :
app.engine=php
app.engine.version=5.6
http.firewall=none
environment=production
Sur le site de test, je suis en PHP 7 et certains scripts (faits maison) ne fonctionnent plus.
Il va falloir que je bosse.

vcasse
17/12/2015, 10h29
Bonjour à tous,

Intéressant ce changement de charset de 5.5 à 5.6. Je n'y avais pas fait attention, bossant déjà en utf-8. En tout cas, j'enregistre, ca peut servir d'autres personnes dans leurs migrations ! Merci chmod777, nitrix-ud et janus.

@gaston_phone : donc tu es en php7 maintenant ?

Cordialement,
Vincent

nitrix-ud
17/12/2015, 08h44
Content que ton problème soit bien identifié

Gaston_Phone
16/12/2015, 23h02
Citation Envoyé par nitrix-ud
Si tu as 5 minutes, enleve ton ini_set('default_charset', 'iso8859-1'); passe en php 5.5 et à mon avis tu n'auras pas de soucis d'accents.
Je viens de faire le test sur un autre hébergement de test (donc un autre domaine) :
  • PHP 5.5 : OK
  • PHP 5.6 : Problème d'affichage des caractères accentués.

Tu as raison, Nitrix-ud, je devais avant être en PHP 5.5.

Je viens de contrôler dans ma sauvegarde du 17 octobre 2015, j'étais bien en PHP 5.5.

Veuillez m'excuser de mettre trompé en disant que cela fonctionnait avant avec PHP 5.6

Merci beaucoup à Vincent (vcasse), chmod777 et nitrix-ud.

Gaston_Phone
16/12/2015, 22h22
Citation Envoyé par nitrix-ud
http://php.net/manual/en/ini.core.ph...efault-charset
Voici le lien de la doc mentionnant ce changement de charset par défaut du php.ini
Pas évident pour tomber dessus.
Merci pour ton aide nitrix-ud.

Citation Envoyé par nitrix-ud
Si tu as 5 minutes, enleve ton ini_set('default_charset', 'iso8859-1'); passe en php 5.5 et à mon avis tu n'auras pas de soucis d'accents.
Merci pour la suggestion que je vais tester sur demaine de test.

nitrix-ud
16/12/2015, 22h08
http://php.net/manual/en/ini.core.ph...efault-charset

Voici le lien de la doc mentionnant ce changement de charset par défaut du php.ini

nitrix-ud
16/12/2015, 22h02
@Gaston_Phone

Je pense que le soucis est le passage de php 5.5 à php 5.6

en tout cas dans mon cas travaillant en iso8859-1, j'ai dû ajouté un petit

header('Content-Type: text/html; charset=ISO-8859-1');
en tête de mes fichiers php pour assurer une migration de php 5.5 à php 5.6 (sinon pb d'accents)

Si tu as 5 minutes, enleve ton ini_set('default_charset', 'iso8859-1'); passe en php 5.5 et à mon avis tu n'auras pas de soucis d'accents.

Gaston_Phone
16/12/2015, 21h57
Citation Envoyé par chmod777
Donc, je pense qu'il suffit de rajouter un simple ini_set('default_charset', 'iso8859-1'); tout en haut des fichiers php, ou le fichier header, etc.
Tu es mon sauveur!

Merci mille fois chmod777.

Citation Envoyé par chmod777
Cela dit, c'est bizarre que le problème ne soit provoqué que maintenant, tu es sûr que tournais bien sous php 5.6 avant d'avoir essayé php7 ?
Tout à fait sür.

chmod777
16/12/2015, 21h52
Citation Envoyé par Gaston_Phone
j'ai mis sur mon profil l'adresse d'une page "Vide" de test
Effectivement, il y a bien ça dans ton code :


mais ça ne concerne que la partie html.

PHP envoie bien, lui, la page avec l'encodage par défaut depuis php 5.4 (ou 5.5?) : utf-8.
Donc, je pense qu'il suffit de rajouter un simple ini_set('default_charset', 'iso8859-1'); tout en haut des fichiers php, ou le fichier header, etc.

Cela dit, c'est bizarre que le problème ne soit provoqué que maintenant, tu es sûr que tournais bien sous php 5.6 avant d'avoir essayé php7 ?

Gaston_Phone
16/12/2015, 21h47
@ janus57, j'ai mis sur mon profil l'adresse d'une page "Vide" de test qui ne comprend :
- Que le menu (un fichier index.php)
- Q'une page vide (à droite)
- Et que la Pub

Avec ou sans la pub les caractères accentués du menu sont mal affichés.

- - - Mise à jour - - -

Et pourtant je suis bien revenu en PHP 5.6 (dixit le phpinfo).

Gaston_Phone
16/12/2015, 21h37
Citation Envoyé par janus57
Entre le PHP7 et 5.6 combien de temps a passé avant d'avoir tenté de nouveau l'affichage de la page ?
Quelques minutes.

Citation Envoyé par janus57
Est-ce pareil en phpcgi ?
Oui.

Citation Envoyé par janus57
Appel à une BDD ? des insertions en BDD lors du passage en PHP7 ?
Oui, il y a un appel a une BDD pour seulement enregistrer le suivi des appels entrants.

janus57
16/12/2015, 21h11
Bonjour,

entre le PHP7 et 5.6 combien de temps a passé avant d'avoir tenté de nouveau l'affichage de la page ?

Est-ce pareil en phpcgi ?

Appel à une BDD ? des insertions en BDD lors du passage en PHP7 ?

Cordialement, janus57

Gaston_Phone
16/12/2015, 20h27
Citation Envoyé par chmod777
Quand tu charges la page, il y a quoi dans les entêtes au niveau du "Content-Type " (à voir avec Firebug par exemple). Normalement, ça devrait être "text/html; charset=ISO-8859-1".
Voila ce que j'ai :

chmod777
16/12/2015, 20h25
Citation Envoyé par Gaston_Phone
Merci janus57 pour ton intervention.

Jusqu'à aujourd'hui 16h tout fonctionnait bien et j'étais ;
  • en : app.engine=php
  • et charset=iso-8859-1
Quand tu charges la page, il y a quoi dans les entêtes au niveau du "Content-Type " (à voir avec Firebug par exemple). Normalement, ça devrait être "text/html; charset=ISO-8859-1".

Gaston_Phone
16/12/2015, 19h39
Merci janus57 pour ton intervention.

Jusqu'à aujourd'hui 16h tout fonctionnait bien et j'étais ;
  • en : app.engine=php
  • et charset=iso-8859-1

janus57
16/12/2015, 19h15
Bonjour,

J'ai essayé :


si à la base c'était pas de l'UTF-8 cela ne suffit pas, il faut aussi ré-encoder le fichier en entier en UTF-8 (sans BOM) (via notepad++ par exemple) et vérifier la BDD.

Sinon pour le passage de PHP7 à PHP5.6 je pense qu'il faut déjà attendre le temps que les processus se régénère en PHP5.6 et aussi est-ce que avant c'était du FPM (app.engine=php ou app.engine=phpcgi ?).

Note : les problème d'accents peuvent aussi non pas venir de l'encodage des fichiers et/ou BDD, mais belle et bien d'une fonctionne PHP dont l'encodage par défaut a été passé en UTF-8 alors que la fonctions reçoit des données en ISO-8859-1 (déjà eu le cas).
Dans ce cas là il faut plonger dans le manuel PHP et modifier sa fonction pour lui re-forcer l'iso.

Note 2 : DE nos jours UTF-8 est préférable, même si cela est un peu plus "lourd".

Cordialement, janus57

Gaston_Phone
16/12/2015, 19h15
Bonjour Vincent

J'ai mis sur mon site une page vide qui ne comprend :
- Que le menu (un fichier index.php)
- Une page vide (à droite)
- La Pub

J'ai rajouté le lien sur le ticket 2015121619059332.

Gaston_Phone
16/12/2015, 18h56
Le problème semble être chez OVH pour 2 raisons :
  • Mon site fonctionnait impecablement jusqu'à ce que je passe avec app.engine.version=7.0 où j'ai eu mes problèmes d'affichage des caractères accentués.
  • Après un retour en app.engine.version=5.6 , et sans rien changer à mon site, les problèmes d'affichage des caractères accentués demeurent.

Contenu de mon fichier /www/.ovhconfig :
app.engine=php
app.engine.version=5.6
http.firewall=none
environment=production
J'ai essayé :

Que faut-il que je fasse ?

vcasse
16/12/2015, 18h06
De rien Gaston,

Franchement c'est étrange. Probablement un soucis entre les données réçue (fichier, base de données, requêtes HTTP) et la configuration de php-fpm.
Pourquoi ca ne s'est pas produit avant ? bonne question.
Les équipes de PHP ont fait des changements sur PHP7 et l'UTF-8, il y a peut etre un lien.

Pour savoir si tu utilises php-fpm, cela dépend de ton .ovhconfig. Variable app.engine
https://www.ovh.com/fr/g1207.configu...ebergement-web

Ce que je te conseille déjà de faire : repasse en php-fpm et 5.6 comme tu étais avant et voir si cela fonctionne.
Si c'est le cas, essaie de checker les encodages de tes fichiers, de ta base s'il y en a une. Puis retente de passer en PHP7.

Le soucis d'encodage provient probablement de tes data. Si tu veux passer à php7, tu devras les update.

Et en cas de soucis, n'hésites pas à poster.
Cordialement,
Vincent

Gaston_Phone
16/12/2015, 17h52
Merci Vincent, mais c'est malheureusement pareil en UFT8.
Je ne me rappelle pas à avoir touché à un quelconque PHP-FPM. Comment le savoir ?
Et ... pourquoi l'affichage était correct (app.engine.version=5.6) jusqu'à ce que je passe à app.engine.version=7.0 .
Que puis-je faire maintenant ?

vcasse
16/12/2015, 17h32
Bonjour Gaston,

L'erreur d'encodage n'est pas du à PHP7 mais à l'activation de PHP-FPM (disponible depuis PHP5.4 sur les hébergements web).
Je pense qu'il n'était pas activé précédemment si le .ovhconfig contenait une erreur.

A mon avis, cette erreur peut être rapidement fixée. Probablement en passant la page html en utf8

Cordialement,
Vincent

Gaston_Phone
16/12/2015, 16h52
Bonjour Vincent,

Comment revenir en arrière à la version 5.6 ? ? ?

Ticket 2015121619059332

Gaston_Phone
16/12/2015, 16h42
OK, Vincent.
Le problème était bien là.

Mais j'ai appliqué aussi app.engine.version=7.0 sur un autre domaine et j'obtiens :
  • app.engine.version=7.0 D�veloppement : CMS
  • app.engine.version=5.6 Développement : CMS

Je n'arrive plus à revenir en arrière à la version 5.6.
J'ai bien maintenant app.engine.version=5.6 dans le fichier /www/.ovhconfig, mais j'ai toujours l'erreur sur les caractères accentués.

Comment revenir en arrière ? ? ?

vcasse
16/12/2015, 14h52
Bonjour Gaston_phone,

Je viens de regarder. Il s'agissait d'une erreur dans le .ovhconfig. La valeur à indiquer est 7.0.
app.engine.version=7.0
La valeur qui s'y trouvait était
app.engine.version=7
Est ce que cette valeur provient d'une documentation erronée ?

Cordialement,
Vincent

Gaston_Phone
16/12/2015, 12h44
Citation Envoyé par vcasse
C'est étrange comme comportement ...
Est ce que tu peux me transmettre un lien que l'on puisse investiguer ?
Merci Vincent. Ticket 2015121619034868.

Gaston_Phone
16/12/2015, 12h02
Merci Vincent.
As-tu une adresse MAIL où je puis te fournir le lien ?

vcasse
16/12/2015, 12h00
Salut Gaston_phone,

C'est étrange comme comportement ...
Est ce que tu peux me transmettre un lien que l'on puisse investiguer ?

Cordialement,
Vincent

Gaston_Phone
16/12/2015, 11h45
Erreur en PHP 7 :
Method Not Implemented
POST to /xxx.php not supported.
Script PHP :
Comment puis-je corriger cela ?

Gaston_Phone
16/12/2015, 11h30
Citation Envoyé par vcasse
Les .ovhconfig fonctionnent uniquement dans les dossiers pointés par un domaine (par défault : www) et à la racine de l'hébergement web.
En dehors, les .ovhconfig ne seront pas pris en compte.
Merci pour ces Précisions.

vcasse
16/12/2015, 10h34
Bonjour Gaston_phone,

Les .ovhconfig fonctionnent uniquement dans les dossiers pointés par un domaine (par défault : www) et à la racine de l'hébergement web.

En dehors, les .ovhconfig ne seront pas pris en compte.

Cordialement,
Vincent

Gaston_Phone
15/12/2015, 18h43
Essaie, étapes par étapes, en mettant un .ovhconfig dédié à PHP 7 dans tous les dossiers.

Nicolasnik
15/12/2015, 18h36
Citation Envoyé par Nicolasnik

#vcasse:
J'ai créé un sous domaine (www.admin.mondomaine.com) que j'ai pointé vers www.mondomaine.com/admin...
En mettant un .ovhconfig dans "admin" (app.engine.version=5.6) et un .ovhconfig dans "www" (app.engine.version=7.0)

Mais j'ai une erreur :

Not Found
The requested URL / was not found on this server.
En fait cela marche, j'arrive à accéder à mon Admin... Mais j'ai plein d'erreurs qui apparaissent ensuite...
Donc pour moi c'est une méthode, certe, mais pas la bonne en ce qui concerne ce script...

Je vais donc voir avec le concepteur de ce script, afin qu'il mette à jours la partie ADMIN du script...

Merci de votre réactivité.

Très cordialement

Nicolasnik
15/12/2015, 18h27
Citation Envoyé par Gaston_Phone

Qu'obtiens-tu comme erreur ?
Le site par lui même marche bien, mais l'Administration de ce site me génère une page blanche...

Cdt

Gaston_Phone
15/12/2015, 18h18
Citation Envoyé par Nicolasnik
@Gaston_Phone:
J'ai effectivement essayé de mettre un .ovhconfig dans "admin" (app.engine.version=5.6) et un .ovhconfig dans "www" (app.engine.version=7.0)
Mais cela ne marche pas...
Il fallait essayer.

Tout dépend comment ton CMS a été conçu et quels dossiers ont été touchés.

- - - Mise à jour - - -

Qu'obtiens-tu comme erreur ?

Nicolasnik
15/12/2015, 16h44
Merci à vous deux pour vos réponses,

@Gaston_Phone:
J'ai effectivement essayé de mettre un .ovhconfig dans "admin" (app.engine.version=5.6) et un .ovhconfig dans "www" (app.engine.version=7.0)
Mais cela ne marche pas...

#vcasse:
J'ai créé un sous domaine (www.admin.mondomaine.com) que j'ai pointé vers www.mondomaine.com/admin...
En mettant un .ovhconfig dans "admin" (app.engine.version=5.6) et un .ovhconfig dans "www" (app.engine.version=7.0)

Mais j'ai une erreur :

Not Found
The requested URL / was not found on this server.
---
pourtant ma configuration dans mon Manager semble bonne...

Je ne comprends pas ???

Merci de vos réponses

Cordialement

Nicolasnik
15/12/2015, 12h52
Bonjour et merci de vos réponses,

@Gaston_Phone
Oui j'ai essayé un .ovhconfig dans l'Admin (www/admin) et un dans le répertoire www...
Mais c'est celui du Rep WWW qui prime, celui dans l'Admin n'a donc pas d'effet...

@vcasse
En fait il faudrait que je créais un "sous-domaine" (EX: admin.monsite.com) et que je le pointe sur www.monsite.com/admin/
Je vais essayé cette astuce...

Quand au développeur de ce script, il est au courant, mais le temps qu'il bouge...

Merci encore à vous deux pour vos réponses.

Je ne tarderai pas à venir donner des nouvelles

Cordialement

vcasse
15/12/2015, 11h47
Bonjour nicolasnik,

Il y a une technique, mais elle n'est pas triviale. Elle est basée sur la possibilité d'utiliser un .ovhconfig par domaine attaché.

Il "suffit" alors de configurer un domaine attaché qui pointe vers www/admin puis d'ajouter un .ovhconfig dans ce dossier.
Si vous utilisez admin.monsite.com comme domaine attaché vers www/admin, vous pourrez accéder à votre administration avec la configuration PHP qui se trouve dans www/admin/.ovhconfig.

Attention cependant, si vous tentez d'y accéder par monsite.com/admin, ce sera toujours la version .ovhconfig du domaine principal qui sera utilisée.

Cette technique, est conseillée uniquement aux personnes à l'aise techniquement. Le mieux étant d'avoir tout son hébergement mutualisé sur une même version de PHP. (mais on a parfois pas le choix).

N'hésitez pas à tenir au courant le développeur de cette application que son espace d'administration n'est pas a jour.

Cordialement,
Vincent

Gaston_Phone
15/12/2015, 11h46
Citation Envoyé par Nicolasnik
Si mon site marche sous PHP 7.0, ce n'est pas le cas pour l'Administration...
Y a t'il un moyen de faire tourner l'admin (www/admin) sous PHP 5.6 et le site (www) sous PHP 7.0 ?
As-tu essayé en mettant un fichier .ovhconfig dédié PHP 5.6 dans ton dossier admin ?

Nicolasnik
15/12/2015, 11h00
Bonjour à tous,

J'utilise le script de petites annonces "Script PAG"...

Si mon site marche sous PHP 7.0, ce n'est pas le cas pour l'Administration...

Y a t'il un moyen de faire tourner l'admin (www/admin) sous PHP 5.6 et le site (www) sous PHP 7.0 ?

Merci de vos réponses.

Cordialement

shacreaw
10/12/2015, 14h02
Génial merci

Bastijn
10/12/2015, 12h28
Citation Envoyé par shacreaw
C'est une bonne nouvelle ça

Par contre on ne peut pas encore choisir PHP7 dans la crontab, c'est normal ?

Dans le même registre quel est le chemin vers le binaire pour utiliser PHP7 via SSH par exemple ? J'ai essayé /usr/local/php7.0/bin/php mais c'est la version 7.0.0RC5.
Pour la cronTab, c'est en cours

pour le chemin, c'est le bon, un oubli, on update aujourd'hui

shacreaw
10/12/2015, 11h57
C'est une bonne nouvelle ça

Par contre on ne peut pas encore choisir PHP7 dans la crontab, c'est normal ?

Dans le même registre quel est le chemin vers le binaire pour utiliser PHP7 via SSH par exemple ? J'ai essayé /usr/local/php7.0/bin/php mais c'est la version 7.0.0RC5.

Bastijn
08/12/2015, 18h22
En tout cas PHP 7 stable sera disponible demain pour tous les clients, configurable depuis le manager v6

janus57
07/12/2015, 18h06
Citation Envoyé par insidebasket
Bonjour,

Pour le moment, testé sur http://www.emaginance.com (version Wordpress 4.3.1, dernière dispo) et échec.
Je n'ai pas cherché plus loin l'erreur, j'attends la prochaine version de WP.

Bonne journée.
Bonjour,

de mémoire wordpress est compatible PHP7, par contre pour les plugins c'est aux différents auteurs de les mettre à jour et c'est surement ça qui va bloquer.

Cordialement, janus57

insidebasket
07/12/2015, 17h01
Bonjour,

Pour le moment, testé sur http://www.emaginance.com (version Wordpress 4.3.1, dernière dispo) et échec.
Je n'ai pas cherché plus loin l'erreur, j'attends la prochaine version de WP.

Bonne journée.

janus57
03/12/2015, 13h38
Bonjour,

je crois pas que l'équipe mutualisé connaisse bien les distributions des produits dédié =)

Cordialement, janus57

pkoipas
03/12/2015, 13h06
Bah la Release 3

Bastijn
03/12/2015, 10h54
Citation Envoyé par pkoipas
et pour la r3, à quand une version récente de php ?????????
Merci
r3 ?

pkoipas
30/11/2015, 21h43
Et pour la R3, à quand une version récente de php ?????????
Merci

Jack31
26/11/2015, 22h14
Bonjour Vincent,
La prochaine version stable, SPIP 3.1 sera compatible PHP7.
En attendant il est possible d'utiliser (ce que je fais) la version svn qui est très stable : http://files.spip.net/spip/dev/SPIP-svn.zip
Je reviendrai ici quand la 3.1 sera sortie.

Jacques

vcasse
26/11/2015, 10h37
Bonjour Jack,

Merci pour ton retour.
Sais tu à partir de quelle version Spip gére PHP7 ? Nous pouvons l'ajouter dans nos documentations

Cordialement,
Vincent

Jack31
25/11/2015, 23h01
Je commence de passer mes sites en PHP 7. Et tout semble très bien se passer.
J'ai essayé un CMS qui n'a pas été testé par l'équipe d'OVH puisqu'il s'agit de SPIP. La version 3.1 en Release Candidate est parfaitement compatible avec PHP7.
J'ai commencé par la mettre hier sur un site de test http://test.jack31.org/ sur lequel j'ai activé le mode development, pour vérifier qu'il n'y avait pas de warnings qui s'affichaient (en fait il y en avait quelques uns qu'un développeur de SPIP a réglé immédiatement)

Ce soir j'ai activé php7 sur un (petit) site en production.
Tout semble OK. Par contre là j'ai remis le mode en production pour bénéficier du cache. Le site semble plus rapide, même si je ne sais pas comment faire des mesures précises.

vcasse
24/11/2015, 13h53
Bonjour Brigerard,

Quelle était l'erreur rencontrée ?
Était-elle due au code de votre site internet ?

Cordialement,
Vincent

brigerard
24/11/2015, 13h07
Je viens d'essayer PHP7 --> Site internet inaccessible
retour à PHP 5.6

Bastijn
19/11/2015, 13h48
Citation Envoyé par Booteille
Bonjour,

Je me demandais si l'extension RAR est supportée par PHP 7.
Non

nocbos
18/11/2015, 21h36
Pas d'amélioration vis à vis du problème déjà remonté ici : https://forum.ovh.com/showthread.php...29-et-exitcode

Booteille
16/11/2015, 13h37
Bonjour,

Je me demandais si l'extension RAR est supportée par PHP 7.

ktanguy
09/11/2015, 23h59
Ok, d'où le feedback. Merci pour la confirmation.
Ça correspond au cas d'usage sur le mutu où on va observer le plus les avantages de PHP 7 vu les efforts qu'ils ont fait sur les optimisations de calcul et d'allocation mémoire (nombre de fonctions qui copiaient les structures prennent maintenant des pointeurs...). Le code a été nettoyé énormément.
Effectivement lorsqu'il y a connexion à une base ou lecture sur le filerz... on n'a pas de gain, les IOs restent totalement séparées de la performance du moteur PHP sur le contenu de ces IOs. (à un bémol près, PHP est le seul langage que j'ai vu faire des boucles de read d'un char de taille 1 jusqu'à EOF sur des fichiers, et des stat/getattr in fine combien même ces attr étaient déjà disponibles, il y a donc encore beaucoup d'optimisations possibles de leur côté).
Bref n'hésite pas à remonter tes tests, c'est pour ce genre d'usage que ça va changer la donne.

Jikoo
09/11/2015, 19h12
Citation Envoyé par ktanguy
Quel est ton cas d'usage ?
Tout d'abord, j'ai aussi fait un benchmark PHP avec microtime() et je vois que c'est plus rapide lors de l'execution.
Mon site est très simple. J'utilise ni Database, ni CMS, ni Framework. Tout est codé à "la main", dynamique, optimisé et caché.
Bref, je fourni notamment des API publiques (utilisés par exemple par chocolatey.org). Les API étant publiques , ils sont très sollicités par d'autres applications, extensions de navigateur, logiciels, scripts en tout genre... Cependant, seule l'accès en lecture est autorisé publiquement. J'ai osé mettre PHP 7 en prod et pour l'instant, j'en suis très satisfait. Par contre, les CRON sont en PHP 5.6 mais ça m'intéresse de les passer aussi en PHP 7.

cavapulser
08/11/2015, 10h23
Moi, j'ai testé sur du WordPress 4.3.1, et ça reste de l'ordre du subjectif question amélioration de la rapidité.
Bref, j'attends que ça murisse pour basculer, mais le "gain" annoncé vs constaté ne sera pas mon moteur principal pour cela :-/

ktanguy
08/11/2015, 00h13
Citation Envoyé par Jikoo
Merci pour la news.
Waooow, c'est effectivement plus rapide ! ^^
Quel est ton cas d'usage ?

Jikoo
05/11/2015, 20h26
Merci pour la news.
Waooow, c'est effectivement plus rapide ! ^^

janus57
05/11/2015, 18h16
Bonjour,

normalement chaque cluster dispose de toute les version PHP que OVH à en stock, cela ne vous fait pas changer de serveur juste car vous changer de version de PHP (trop lourd à gérer).

Cordialement, janus57

Reglysse
05/11/2015, 15h33
Bonjour, est-ce que vous avez des serveurs différents par version de PHP ? Est-ce que le fait de changer de version nous change de serveur ?

Bastijn
04/11/2015, 11h05
Citation Envoyé par monsieurlovaaa
Absolument!

Je ne sais rien des tests mais voici:

Sur mon nouveau mutu PRO2014, plus aucun php ne marche!
Mon site principal est en erreur 500 depuis près de 24h!

Et le support ovh ne répond pas aux tickets d'assistance! Silence radio!

J'ai un plan90P ancien, mes anciens sites dessus marchent. php wordpress !!!

Quelqu'un peut-il aider s'il vous plait???
Bonjour,
Une erreur 500 peut venir de beaucoup de chose. Il faudrait déja avoir des détails
Ce guide peut t'aider pour en avoir : https://www.ovh.com/fr/g1562.mutuali...e_page_blanche

Ensuite, l'ajout de cette version PHP 7 n'a pas d'impact sur les autres versions, c'est totalement décorrelé.
Si le support n'est pas assez rapide pour toi par email, n'héiste pas à appeler le 1007, ils sont très reactifs.
Bonne journée

monsieurlovaaa
03/11/2015, 19h17
Absolument!

Je ne sais rien des tests mais voici:

Sur mon nouveau mutu PRO2014, plus aucun php ne marche!
Mon site principal est en erreur 500 depuis près de 24h!

Et le support ovh ne répond pas aux tickets d'assistance! Silence radio!

J'ai un plan90P ancien, mes anciens sites dessus marchent. php wordpress !!!

Quelqu'un peut-il aider s'il vous plait???

nitrix-ud
03/11/2015, 14h28
J'ai testé sur un mediaplan, et pas de soucis les erreurs php ne trigger pas d'erreur 500 apache...

nitrix-ud
03/11/2015, 13h47
Bonjour,

Super pour la disponibilité de PHP 7.

Du coup j'ai fait des tests ce matin, et je me suis aperçu que les erreurs fatales PHP trigger des erreurs 500 !!!! (en php 7 mais aussi en php 5)
super pour faire des tests ....

Vous avez des soucis sur les hébergements mutu aujourd'hui ??

Merci pour vos réponse...


Juste ce petit bout de code donne une erreur 500, j'avais encore jamais vu ça
Code PHP:

echo 'test 1
'

echo 'test 2';
?>

Bastijn
02/11/2015, 10h20
Citation Envoyé par nicolinux
Merci de proposer la PHP*7 !

Le gain est vraiment indéniable, et avec un blog WordPress, on est assez tranquille niveau compatibilité. Je l'ai mis en place sur mon blog, et je n'ai aucun souci particulier.Et niveau performances, on voit bien la différence, en particulier dans l'administration.

J'ai mesuré théoriquement la différence et expliqué comment passer à PHP*7 dans cet article, si cela vous intéresse : https://mestrucspour.wordpress.com/2.../01/php-7-ovh/
Merci pour l'article nicolinux ! tes benchs correspondent bien à notre ressenti ça fait plaisir
On vous tiendra au courant dès que PHP7 sera disponible via le manager V6 (au lieu d'une modif du .ovhconfig), c'est à dire quand PHP7 sera en release stable.

nicolinux
01/11/2015, 18h43
Merci de proposer la PHP*7 !

Le gain est vraiment indéniable, et avec un blog WordPress, on est assez tranquille niveau compatibilité. Je l'ai mis en place sur mon blog, et je n'ai aucun souci particulier.Et niveau performances, on voit bien la différence, en particulier dans l'administration.

J'ai mesuré théoriquement la différence et expliqué comment passer à PHP*7 dans cet article, si cela vous intéresse : https://mestrucspour.wordpress.com/2.../01/php-7-ovh/

vcasse
28/10/2015, 13h55
Bonjour Daniel,

Je vous invite à regarder la liste officielle des incompatibilités fournies par PHP : http://php.net/manual/fr/migration70.incompatible.php

En résumé, les points vraiment "risqués" sont :
- Le changement de lecture des variables "complexes" : http://php.net/manual/fr/migration70...dling.indirect
- Les erreurs fatales retournées en exceptions (enfin!)
- Le support de nombreuses extensions abandonnées (sapi_*, mysql_* ...)
- L'extension memcache non compatible pour le moment

Cordialement,
Vincent

chmod777
28/10/2015, 13h53
Citation Envoyé par Daniel60
Dans le cas de sites créés "à la main" en dehors des CMS, pouvez-vous donner la liste des incompatibilités par rapport à 5.5 car nous venons juste de refaire tout les scripts !
En gros :
Suppression des extensions ereg et mysql originale.
L'option /e est également supprimée pour les fonctions preg_ (cassure pour phpBB).
De manière générale, tout ce qui est obsolète (deprecated) sous php5.x a été supprimé.

Pour tout le reste :
http://php.net/manual/fr/migration70.php

Daniel60
28/10/2015, 13h47
Dans le cas de sites créés "à la main" en dehors des CMS, pouvez-vous donner la liste des incompatibilités par rapport à 5.5 car nous venons juste de refaire tout les scripts !

Gaston_Phone
28/10/2015, 12h51
C'est bon à savoir.

Bastijn
28/10/2015, 10h13
UPDATE : PHP7 stable disponible


Bonjour à tous,

PHP7 Release Candidate 7 est disponible sur les hébergements mutualisés Linux ( PHPinfo ).
Nous vous expliquons ici comment tester PHP7 avant sa sortie officielle.

NOTE INFORMATIVE
PHP7 n'est pas pas encore stable dans sa version actuelle (Release Candidate 5). OVH vous déconseille de l'utiliser pour vos sites en production.
OVH ne pourra pas vous aider en cas de problème sur cette avant-première, aucun support n'est fourni.
La version finale sera mise en place et disponible à OVH dès sa sortie (roadmap officielle : https://wiki.php.net/todo/php70#timetable)


PHP 7 ?
20 ans après sa création, PHP arrive en version 7 ! Vraiment plus rapide, plus stable, vos sites hébergés chez OVH ont tout à y gagner
Si vous n'avez pas encore lu notre article sur cette sortie, n'hésitez pas : https://www.ovh.com/fr/news/a1859.no...e-php-pas-mort.
Consultez aussi le guide de migration officiel afin de vous assurer que votre code sera compatible : http://php.net/manual/fr/migration70.php. Ne vous inquiétez pas : le passage de PHP5 à PHP7 est bien moins douleureux que le passage de PHP4 à PHP5.


COMMENT TESTER PHP7 RC7 ?
Envie de tester ? C'est facile :
- vous devez disposer d'un hébergement Web mutualisé Linux (packs Perso, Pro, ou Performance)
- vous pouvez ensuite modifier la variable app.engine.version=7.0 dans votre fichier .OVHCONFIG
Si vous ne savez pas comment faire, suivez ce guide : https://www.ovh.com/fr/g1207.configurer-php-web

Une fois PHP7 disponible en version stable (prévu pour novembre), OVH vous permettra de modifier votre configuration PHP vers la version 7 directement depuis votre Manager V6.


COMPATIBILITES
PHP 7 étant en cours de développement, tout n'est pas encore compatible.
Par exemple, le module permettant la connexion à Memcache n'est pas encore disponible pour PHP7.

Nous avons testé les principaux CMS et frameworks de développement et voici nos résultats, à date du 27/10/2015 :

Compatibles :
Wordpress : compatible depuis la version 4.3
Symfony : compatible pour toutes les versions ayant actuellement du support : 2.3, 2.6, 2.7 et la future 3.0
Zend framework : compatible depuis la version 2.4 (actuellement en version 2.5)
Laravel : compatible avec la version 5 (courante)

Pas encore compatibles (mais presque) :
Prestashop : pas encore compatible mais prêt dans la prochaine version 1.6.1.2 (actuellement en release candidate)
Joomla : pas encore compatible mais le travail est en cours pour la version 3.5 (prochaine version majeure)
Drupal : pas encore compatible mais prêt dans la prochaine version majeure 8.0 (actuellement en release candidate)


PERFORMANCES
Nous arrivons au plus intéressant Autant le dire d'emblée, les gains sont excellents.
Nos benchmarks sont réalisés sur les offres mutualisés de OVH, avec le mode FPM activé (à partir de PHP5.4).

PHP Benchmark :
Benchmark réalisé à partir de http://php-benchmark-script.com/.
https://www.ovh.com/fr/images/news/p...-benchmark.png

PHP 4.4 => 15,60s
PHP 5.2 => 6,89s
PHP 5.3 => 6,06s
PHP 5.4 => 4,85s
PHP 5.5 => 4,28s
PHP 5.6 => 4,20s
PHP 7.0 => 1,35s

Prestashop :
Benchmark réalisé à partir du temps de chargement de la homepage
https://www.ovh.com/fr/images/news/p...Prestashop.png

PHP 5.4 => 0,708s
PHP 5.5 => 0,691s
PHP 5.6 => 0,676s
PHP 7.0 => 0,595s

Wordpress :
Benchmark réalisé à partir du temps de chargement de la homepage
https://www.ovh.com/fr/images/news/p...-Wordpress.png

PHP 5.4 => 0,311s
PHP 5.5 => 0,305s
PHP 5.6 => 0,301s
PHP 7.0 => 0,270s

==> N'hésitez pas à nous faire vos retours ici sur PHP 7 !