Activer PHP5 sur votre hébergeur

Stéphane · janvier 2010

Bonjour,

J'ouvre ici un fil de discussion pour recenser les différents directives afin d'activer PHP5 sur votre hébergeur et faire fonctionner correctement votre PluXml 4.3.1+
En effet de nombreux hébergeurs sont paramétrés par défaut avec PHP4.

La méthode pour activer PHP5 et la liste des directives sont consultables sur le wiki ici : Activer PHP5 sur votre hébergeur

Merci de lister sur ce forum les directives que vous connaissez en fonction de votre hébergeur et qui ne sont pas encore listées sur le wiki.

Vous pouvez également mettre directement à jour le wiki si vous le souhaitez.

Stéphane.

zenpix · mai 2011

pour l'hebergeur nuxit , a rajouter dans htaccess:

options -indexes
AddHandler x-httpd-php5 .php
AddType application/x-httpd-php5 .php

test realisé chez nuxit ok.

Stéphane · mai 2011

zenpix a écrit:

pour l'hebergeur nuxit , a rajouter dans htaccess:

options -indexes
AddHandler x-httpd-php5 .php
AddType application/x-httpd-php5 .php

test realisé chez nuxit ok.

merci pour ce retour. j'ai mis à jour le wiki

bg62 · septembre 2011

attention pour free.fr ... il semble ne supporter que php5 et pas au-dessus ... donc pour les futurs "codages", si l'on ne veut pas perdre la possibilité de pouvoir mettre PluXml sur free ...

brica · juillet 2012

Chez Online (groupe Free, Iliad) : ajouter la ligne suivante dans le .htaccess :
AddType application/x-httpd-php5 .php

Chez Free.fr (groupe Online, Iliad) supporte PHP5. Rajouter :
php 1

brica · juillet 2012

Chez OVH, rajouter dans le .htaccess :
SetEnv PHP_VER 5

Kyodev · avril 2014

le lien du wiki sur le premier post est en erreur, c'est Activer+PHP5+sur+votre+hébergement et non

sur votre hébergeur

pour ovh mutualisé, on peut cibler plus précisément, à ce jour:

[== TEXT==]
#SetEnv PHP_VER 5
	#PHP Version 5.2.17
#SetEnv PHP_VER 5_3
	#PHP Version 5.3.16
SetEnv PHP_VER 5_4
	#PHP Version 5.4.6
#SetEnv PHP_VER 5_5
	#non fonctionnel -> PHP Version 5.2.17

j'ai complété le wiki

Haruka · avril 2014

Merci à vous :-)
J'ai corrigé le lien dans le premier post.

eauland · juin 2015

Pour OVH maintenant il faut voir avec le .ovhconfig à la racine du serveur mutualisé:

Un exemple:

[== Indéfini ==]
; Valeurs: php | phpcgi
app.engine=php

; La directive "app.engine.version" permet de choisir la version de php à utiliser
;
; Valeurs: 5.4 | 5.5 | 5.6...
app.engine.version=5.6

; La directive "http.firewall" permet d'activer un firewall applicatif de type mod_security, pour cela mettez : security
; http.firewall est par défaut à none 
;
; valeurs: none | security
http.firewall=none

; La directive "environment" permet de spécifier le cache des fichier statiques ainsi que le comportement des erreurs PHP
;
; En mode development :
;    aucun cache n'est appliqué
;    les logs PHP apparaissent sur votre site (display_errors=On)
;
; En mode production : (option par défaut)
;    les fichiers statiques tels que images, vidéo, audio ont une expiration plus grande ce qui maximise la mise en cache des fichiers sur les navigateurs
;    les logs PHP n'apparaissent pas sur votre site (display_errors=Off)
;
; valeurs: production | development
environment=development

clicdroit · juin 2015

Bonjour.

J'ai changé récemment d'hébergeur (avril 2015).
Lors de la migration des sites, aucun problème rencontré, y compris lors des modifications que j'ai profité d'apporter.

Aujourd'hui, juin 2015, aucun enregistrement après modification des pages ou articles dans l'admin n'est possible : "Security error : invalid or expired token"

De plus (ou est-ce la même chose ?...), les erreurs rapportées par l'hébergeur sont des pages 404.shtml qui seraient dues à l'absence dans mes dossiers des fichiers favicon.ico et favicon.png...

La version Php actuelle de l'hébergeur est 5.4
Je ne connais pas et n'ai pas relevé hélàs la version active en avril dernier (si le problème devait venir de là)

Enfin, aucune idée si un ajout de directives Php pourrait remédier au souci, Obambu (mon hébergeur) n'étant pas référencé ici...

D'avance merci pour votre concours

Stéphane · juin 2015

@clicdroit: quel est ton hébergeur ? Peut-etre une nouvelle directive à mettre dans un htaccess pour le passage à php 5.4

clicdroit · juin 2015

@Stéphane : avant dernière ligne de mon message

Obambu (mon hébergeur) n'étant pas référencé ici...

Stéphane · juin 2015

Si tu connais le serveur utilisé par ton site, tu peux contrôler ici si ce n'est pas lié à un problème chez eux
https://obambu.com/fr/reseau/

Sinon peux-être prendre contact avec leur support ou en passant par le forum de obambu
http://forum.obambu.com/index.php

clicdroit · juin 2015

Si tu connais le serveur utilisé par ton site, tu peux contrôler ici si ce n'est pas lié à un problème chez eux

vérification faite, le serveur sur lequel sont logées mes data n'est pas concerné par les indicents

Sinon peux-être prendre contact avec leur support ou en passant par le forum de obambu

contact pris avec le support, ce dernier me renvoie (évidemment) à la supposée incompatibilité de PluX avec la version actuelle de Php utilisée par l'hébergeur (Php 5.4) dont j'attends aussi la réponse quant au numéro de version de la période à laquelle ce problème n'existait pas... et d'où toujours ma question (n'y connaissant pas plus que cela)

aucune idée si un ajout de directives Php pourrait remédier au souci, Obambu (mon hébergeur) n'étant pas référencé ici... [?]

ou, dit autrement, comment savoir si un ajout de directives remédierait (ou pas) à cette curiosité bizarroïde ?

par ailleurs, je ne m'explique pas que...

De plus (ou est-ce la même chose ?...), les erreurs rapportées par l'hébergeur sont des pages 404.shtml qui seraient dues à l'absence dans mes dossiers des fichiers favicon.ico et favicon.png...

pourtant les fichiers favicon.ico/png existent bel et bien et sont on ne peut plus présents

tout comme...

je me rends compte aussi par ailleurs que...
la page publique :
/index.php?static19/temoignages
ne correspond pas au fichier qui en est à l'origine :
/data/statiques/019.temoignages.php

en réponse de quoi, le support hébergeur me réplique :

Les modifications apportées au fichier 019.temoignages.php sont bien présentes dans la page /index.php?static19/temoignages

Veuillez cependant noter que le contenu du fichier 019.temoignages.php n'est pas envoyé directement au navigateur : le fichier contient uniquement le texte central, le code HTML correspondant au reste (menus, pied de page, etc) est ajouté par PluXML. De plus, les instructions PHP contenues dans le fichier 019.temoignages.php sont interprétées et ne sont donc plus présentes dans le code HTML final qui est envoyé au navigateur. Il est donc normal que le code source du fichier 019.temoignages.php et le code source de l'adresse /index.php?static19/temoignages ne soient pas identiques.

En plus de cela, il semble que votre site utilise le cache côté client (navigateur), les modifications apportées ne sont donc pas visibles immédiatement.
Après avoir effectué une modification, je vous invite à ouvrir la page via une session de navigation privée afin de ne pas utiliser le cache de la session principale.

or, manipulation qui n'a jamais été nécessaire auparavant, chez mon ancien hébergeur, où les modifs étaient quasi instantanées...

pour ceux qui auraient des pistes de résolution, merci d'avance

Stéphane · juin 2015

Bonjour

Pour commencer PluXml est pleinement compatible avec Php 5.4. Aucun problème de ce coté là.

Si tu as fait des modifications dans PluXml, peux-tu essayer de faire une nouvelle installation propre dans un autre dossier et regarder si cela fonctionne ?
Attention si tu as un fichier .htaccess à la racine de ton hébergement (pas dans le dossier d'install de PluXml, mais bien au 1er niveau), renomme le, car les directives qui sont dedans peuvent se propager et être effectives dans les sous dossiers, ce qui viendrait en conflit avec l'install propre par effets de bords.

On va essayer déjà cette étape...

clicdroit · juin 2015

Bon, donc, déjà : pas de .htaccess à la racine de l'hébergement, et j'ai bien fouillé dans tous les dossiers A LA RACINE
en .* je n'ai que du : bash, lastlogin, zshrc et contactemail

Maintenant :
[list=*]
[*]j'ai bougé tous les fichiers de mon répertoire-site d'origine vers - on va dire - un dossier d'archive temporaire, et ce de sorte à pouvoir refaire une install en repartant de zéro dans le répertoire-site (vers lequel pointe le nom de domaine)[/*]
[*]je réalise mon install d'un PluX vierge fraîchement redownloadé[/*]
[*]j'entre dans l'Admin et là... qu'est-ce que je ne vois pas ?!![/*]
[*]TOUS MES ARTICLES ET TOUTES MES PAGES N'ONT PAS BOUGE ET SONT TOUJOURS LA ! Autrement dit : ce qui n'est plus dans le répertoire-site d'origine et se trouve à présent dans le dossier d'archive temporaire, s'y trouve néanmoins encore... mais virtuellement (dans le dossier, sur le serveur : rien, mais dans l'admin, côté usager : tout y est !

)[/*]
[*]... et tandis que je reviens à nouveau vérifier : les articles ont à présent disparus, ne restent (encore) que les pages statiques (ce qu'expliquait j'imagine le gars de mon support hébergement)[/*]
[/list]

Néanmoins, mon problème de base demeure : il semble désormais impossible d'enregistrer quoi que ce soit

OU BIEN, un enregistrement conduit à une page blanche "Security error : invalid or expired token"
OU BIEN, la page qui vient d'être corrigée se rafraîchit et revient à son état antérieure (évacuant totalement la correction apportée)
OU BIEN ENCORE, un retour à la page précédente après un "Security error : invalid or expired token" ramène bien sur la page corrigée et une nouvelle tentative d'enregistrement fait alors cette fois passer à la page précédente de l'admin (liste des articles si la page corrigée était un article, ou liste des statiques si la page à corriger était une statique)

en tout cas, si jusqu'ici je n'en menais pas large, là maintenant ce qui est sûr, c'est que je suis complétement largué

PS : niveau permissions - à tout hasard et à tâtons du pifomètre -, j'ai soit du 644, soit du 705 ou du 755...

Stéphane · juin 2015

@clicdroit: je t'invite à me contacter en privé par mail, pour qu'on regarde et qu'on essaye de résoudre le problème, si tu veux bien me donner un accès ftp à ton serveur pour que je vérifie l'installation, les droits des fichiers, et tout ce qui pourrait gener. A ma connaissance tu es le 1er à héberger un PkuXml chez Obambu. Tu essuies les platres...

clicdroit · juin 2015

en complément et peut-être conclusion de la partie publique, voilà la réponse du support

Obambu a écrit:

La version de PHP utilisée actuellement par votre compte est la même depuis plusieurs mois, il s'agit de la version 5.4.

L'erreur indiquée se produit lorsque le jeton de sécurité n'est pas transmis correctement ou qu'il a été créé plus d'une heure avant l'enregistrement des modifications (voir fichier class.plx.token.php).

Enregistrez-vous bien les modifications moins d'une heure après avoir ouvert l'éditeur ?

En effet, même si je ne l'ai pas présenté de la sorte mais bel et bien décrit ainsi, le problème rencontré est le même que lorsqu'on dépasse ce délai (dont j'ai oublié l'appellation) au delà duquel il est nécessaire de rafraîchir la page ou de se reconnecter à PluX pour que les actions soient prises en compte.
La différence ici est que ce délai semble être ne pas respecté ou inexistant, car mes contenus n'étant que quasi exclusivement rédactionnels les modifs/enregistrements sont fréquents, de l'ordre de la minute et donc très loin de l'heure...

clicdroit · juillet 2015

EPILOGUE

ajout .htaccess :

[== Indéfini ==]
RequestHeader unset If-Modified-Since
RequestHeader unset If-None-Match

explication du support :

Obambu a écrit:

Le navigateur ne téléchargeait pas le nouveau token (jeton) à chaque édition de l'article car il chargeait la page qui permet d'éditer l'article depuis son cache.
Cela avait pour conséquence de provoquer l'erreur indiquée précédemment (jeton invalide ou expiré).

En désactivant le cache côté navigateur, le navigateur charge le formulaire à chaque demande et obtient ainsi le nouveau jeton de sécurité.

Et à la question, restant néanmoins posée : "comment se fait-il que le problème soit apparu du jour au lendemain ?" la seule explication plausible, au vu de la réponse et de la résolution congruentes du support, serait une MAJ auto du navigateur... Même si dans ce cas : pourquoi aurais-je été le seul à rencontrer un tel problème... mystère et boule de gomme !

(avec un grand merci tout particulier à Stéphane pour sa réactivité et son suivi sans faille)

bankai · août 2015

Mise à jour du wiki pour le changement de version chez OVH mutu 2014-2015

cfdev · décembre 2015

bankai a écrit:

Mise à jour du wiki pour le changement de version chez OVH mutu 2014-2015

Normal que les boutons : "dernier changement, historique et recherche" ne fonctionne pas ... sur ce wiki ?

Stéphane · décembre 2015

cfdev a écrit:

bankai a écrit:

Mise à jour du wiki pour le changement de version chez OVH mutu 2014-2015

Normal que les boutons : "dernier changement, historique et recherche" ne fonctionne pas ... sur ce wiki ?

ça fonctionne tres bien chez moi.

Gzyg · décembre 2015

Je confirme que ça NE fonctionne PAS pour moi non plus. (firefox, opera et chromium sur linuxmint)

à plus,

Gzyg

kowalsky · décembre 2015

Même problème par ici. Quand j'analyse les liens du menu et du bouton recherche, je constate que ceux-ci renvoient vers la page d'accueil sans tenir compte des indications après le "?".

<div id="brdmenu">
<ul>
	<li><a href="index.php?page=Accueil">Accueil</a></li>
	<li><a href="index.php?action=recent">Changements récents</a></li>
	<li><a href="index.php?page=Accueil&amp;action=history">Historique</a></li>
</ul>
</div>

A titre de comparaison, cela fonctionne correctement pour la section "Documentation pour les développeurs" dont les liens du menu sont identiques, à l'exception de l'url du sous-domaine :

http://devzone.pluxml.org/index.php?page=Accueil

Peut-être un soucis avec le rewriting d'url du wiki ?

Activer PHP5 sur votre hébergeur

Réponses