php5 vers php7

Bonjour
il y a plusieurs années, j'ai développé un site en php5.2.5 qui fonctionne avec wampserver 2 et sur mon serveur dédié . Ce site ne fonctionne pas avec wampserver 64 php 7.2.18 et, selon les techniciens de mon hébergement, devrait bientôt ne plus fonctionner non plus sur mon serveur à cause des failles de sécurité et des fonctions obsolètes .
J'ai développé ce site avec un ami qui, malheureusement, ne peut plus m'aider . Je ne sais pas du tout dans quelle direction aller afin d'adapter mon site aux nouvelles conditions techniques . paramétrage de wampserver 64 et du serveur dédié ? réécriture d'une partie du script en php ? modification du fichier .htaccess ? paramétrage apache ? .........

lorsque je le lance avec wampserver 64 les messages d'erreurs sont :

Citation:

---

Notice: session_start(): A session had already been started- ignoring in C:\wamp64 ..........
Warning: session_name(): Cannot change session name when session is active in C\wamp .......
Fatal error: Uncaught Error: Call the undefined function mcrypt_module_open() in .........

---

Certaines pages du script s'ouvrent (plutôt ne s'ouvrent pas) avec des messages d'erreur concernant les variables qui ne sont pas retrouvées ..

Citation:

---

Notice: Undefined variable : labase in C:\wamp64 .....
Notice: Undefined index: LANGUE in C: .....

---

N'ayant pas remis le nez dans la programmation, qui n'était déjà pas ma spécialité, depuis très très longtemps et sans "guide" , je suis complètement perdu .
merci d'avance à celui ou celle qui aura la patience de tenter de m'éclairer .

Mau

Il y a des guides officiels sur le sujet :
https://www.php.net/manual/fr/migration53.php

Je pense que tu devrais te concentrer sur 5.2 vers la 5.3.6, puis 5.6, puis 7.

Salut,

tu pars de trop loin et la migration ne sera pas une sinécure crois-moi.
Il y a de grandes chances que cela se termine tout simplement en reprise intégrale du code, ne serait-ce que pour bénéficier de toutes les nouveautés du langage, qui soit dit en passant sont vraiment tip-top.

Gros site ? Combien de scripts ? Avais-tu utilisé un framework à l'époque ? Base de données derrière ? Si oui, envisages-tu de la mettre à jour également et assurer le portage des données ?

bonsoir
tout d'abord, merci à vous d'avoir répondu .

le site que j'ai développé est un site commercial avec commande, paiement en ligne, administration, base de données etc... il a un peu fonctionné lorsque je l'ai créé en 2008 mais, avec l'énorme concurrence qui sévit dorénavant, c'est beaucoup plus léger, voire insignifiant . C'est la raison pour laquelle je remets mon nez dedans ...

je ne sais pas ce que tu appelles "gros site" mais en tous cas , pour moi, il l'est . très morcelé, pas mal d'include , il y a environ 200 scripts
Je l'ai développé avec dreamweaver et wampserver2 en local avec un copain (plutôt bon en la matière) derrière moi pour le démarrage et lorsque ça coinçait .Ce site a été hébergé sur un serveur dédié mais a été piraté . Un technicien de l'hébergeur a effectué une migration provisoire en ajoutant quelques éléments de sécurité mais m'a dit qu'il fallait que j'adapte tout ça sur mon nouveau serveur avec php7.1.8 dans les plus brefs délais .

Là où je me trouve actuellement et pendant deux mois , avec du temps dispo , je n'ai qu'un éditeur de scripts et wampserver64 (dreamweaver est sur mon ordi que je n'ai pas avec moi)

Mon problème majeur est que je ne sais pas du tout par où commencer pour essayer de progresser , de voir quelques résultats (htaccess, scripts php, db, config apache ou/et php. Pour l'instant, tout ce que j'ai essayé de faire reste dans des messages d'erreur ...

J'ai regardé le lien que m'a envoyé "Sodium" , et je l'en remercie, mais il est , pour moi, un peu abscons .. je vais y retourner et essayer d'y trouver des pistes ... Mais je crains d'avoir des pages et des pages à lire avant d'y trouver une toute petite bougie pour m'éclairer .

D'après ce que tu racontes... efface tout ça, prie pour qu'il n'y ait pas trop de données personnelles de clients dans la nature et installe un Prestashop.

bonjour

merci pour cette solution qui pourrait probablement être la plus efficace, compte tenu de mes connaissances limitées, mais j'aurais quand même aimé essayer de reprendre mon script , même si la tâche me semble complexe .
n'y a t-il pas un tuto explicite et accessible à un novice qui expliquerait pourquoi avec wampsever64 (nouvellement installé) j'ai un message

Citation:

---

Notice: session_start(): A session had already been started- ignoring in C:\wamp64 ..........
Warning: session_name(): Cannot change session name when session is active in C\wamp .......
Fatal error: Uncaught Error: Call the undefined function mcrypt_module_open() in .........

---

que je n'avais pas avec wampserver2
peut-être y a t-il une question de config du wamp64 ? pour ne pas risquer de planter tout le système, sans conseils, je n'ai rien changé à la config de base.

En cas d'erreurs multiples sur les config (configuration, extensions php, modules apaches) est-il possible de revenir à la config de base sans désinstaller/réinstaller wamp64 ?

pour l'instant , tout ce que j'ai trouvé (dans le script, mettre session_name avant session_start) me donne un autre message tout aussi obscur ...

Citation:

---

Warning: session_name(): Cannot change session_name when session is active in C:\ ....

---

la résolution de ce premier point me permettrait peut-être d'envisager de poursuivre ...

ensuite, j'essaierai de trouver pourquoi les variables sont "undefined" . si elles le sont toujours ...

le souci c'est l'écart entre PHP 5 et PHP 7.

Entre les fonctions dépréciées, les nouveautés du langage, le modèle objet qui est devenu hyper performant, le subtilités de la configuration, la gestion du cache... Tu devrais presque tout réapprendre pour t'en sortir.
C'est un travail colossal, comme je te l'ai dit plus haut, tu pars de trop loin. Cela ne pourra se faire par des petits ajustements, c'est soit tu recodes presque tout et là, il va falloir que tu montes ton niveau en PHP pour être à jour, soit tu essaies de voir si l'utilisation d'un moteur de boutique en ligne ne te simplifierait pas la tâche dans la mesure où cette option ne sera pas "doigts dans le nez" non plus.

Pour nuancer un peu les propos (fort exacts) de mon collègue : l'écart entre PHP 5 et PHP 7 sur ton site dépend de la façon dont il a été codé.

Exemple : si tes accès en base sont effectués par l'API mysql (mysql_connect, mysql_query), tu vas avoir une charge assez importante pour tout adapter, étant donné que l'API mysql n'existe plus en PHP7. En revanche, si ton application utilisait déjà PDO, ce sera quasi-transparent.
Mais statistiquement, la plupart des applications codées à l'époque utilise l'API mysql, donc on part du principe que c'est le cas de la tienne et donc que tu vas avoir masse de taf. :?

Et sinon, pour répondre au message d'origine :

Citation:

---

Fatal error: Uncaught Error: Call the undefined function mcrypt_module_open() in .........

---

Il faut activer l'extension mcrypt sur ton nouveau serveur, sachant que MCrypt est obsolète en PHP 7.1 et que certaines fonctions sont supprimées en PHP7.2+

Citation:

---

Notice: Undefined variable : labase in C:\wamp64 .....

---

En général, une variable manquante, c'est davantage un symptôme que le réel problème. Ce qu'il faut regarder dans ce genre de cas, 1) où est utilisée la variable en question et 2) où elle est affectée
(et 3) si il n'y a pas de faute de frappe alakon du genre $la_base, $labase ou $labsae, mais si ton site fonctionnait avant, on peut normalement exclure ce cas)

Je me suis personnellement arrêtée à "site commercial avec commandes".
Si c'est un site commercial, c'est un site qui contient des données sensibles, et je doute qu'un site en PHP 5.2 antédiluvien soit au point niveau sécurité, si que les failles soient évidentes à corriger (il y a sans doute des soucis au niveau de la conception pour commencer).

merci à toutes et tous pour ces infos

Ayant un peu de temps en ce moment, en avançant pas à pas avec vos différents conseils et forums, j'arrive à avoir quelques résultats. Un peu pugnace, ceci m'encourage, pour l'instant, à continuer dans cette direction . J'ai bien compris qu'il serait préférable de tout refaire en réapprenant à coder mais je ne suis pas sûr d'y arriver car mon but n'est pas de devenir développeur mais juste de réussir à adapter, faire fonctionner et sécuriser ce site qui m'a pris beaucoup de temps à développer et que je ne me sens pas capable de complètement recréer .
La solution du site tout fait (compliqué à mettre en place ou non) n'étant, du moins pour l'instant, pas ma préférence. (vous l'aurez probablement compris)
Si difficile n'est pas impossible, je vais insister.. en cherchant dans les docs .

pour les fonctions dépréciées, lorsqu'elles ont une fonction de remplacement, je m'en sors . Quand elle n'en ont pas ?? je cherche dans les FAQ et les forums sinon j'essaie de questionner plus qualifié que moi sur les pistes à suivre .
sur mcrypt .. je n'ai rien trouvé à part obsolète

J'ai cru comprendre que sur cette version de PHP7, les variables devaient être déclarées si elles n'existaient pas ..

tous les MYSQL ont été remplacés par MYSQLI ce qui a fait un tout petit peu avancer les choses . Je tente , quand je les comprends, de suivre et rectifier les messages d'erreur .


il y en a un sur lequel je butte concernant les sessions

mon code en début de script :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

<?php session_start(); ob_start(); session_name("mausite");   include("config.php");   if($langue){$_SESSION['LANGUE'] = $langue;} if(!isset($_SESSION['LANGUE'])){$_SESSION['LANGUE'] = "francais";}   //deconnection : fin session if ($Quit =="Ok"){ // Détruit toutes les variables de session $_SESSION = array();   // Pour détruire complètement la session, effacer également // le cookie de session. // Note : cela détruira la session et pas seulement les données de session ! if (isset($_COOKIE[session_name()])) { setcookie(session_name(), '', time()-42000, '/'); } session_destroy(); print ("<script language='Javascript'>document.location.replace('index.php')</script>"); }

---

le message d'erreur :

Citation:

---

Warning: session_name(): Cannot change session name when session is active in C\wamp .......

---

qui disparait lorsque je désactive ces lignes . Ce qui me fait avancer et reculer en même temps :?

j'ai trouvé, sur différents forums, des solutions quelquefois contradictoires .. en changeant de place les lignes ... 8O

quels sont les modules apache 2.4.39 à activer ? tous ceux qui concernent les sessions ?
y a t-il une config spéciale dans php pour les sessions ?

si vous connaissez les réponses ou des liens sûrs et compréhensibles concernant ces sujets ...je vous en serai reconnaissant

Citation:

---

Envoyé par mauyebo

J'ai cru comprendre que sur cette version de PHP7, les variables devaient être déclarées si elles n'existaient pas ..

---

Non, PHP7 est encore à la rue pour ce qui est du typage des variables malheureusement.

D'après la doc :

Citation:

---

session_name() doit être appelé avant session_start() pour que la session fonctionne correctement.

---

:arrow: PHP: session_name - Manual
Donc plutôt :

Code:

---

1 2 3 4

<?php session_name("mausite"); session_start(); ob_start();

---

Pour mcrypt, la doc indique simplement :

Citation:

---

Cette fonctionnalité est OBSOLÈTE à partir de PHP 7.1.0 et a été SUPPRIMÉE à partir de PHP 7.2.0.

Les alternatives à cette fonctionnalité incluent :

• Sodium (disponible depuis PHP 7.2.0)
• OpenSSL

---

Comme ce n'est pas une fonctionnalité que j'ai eu l'occasion d'utiliser, je suppose que ça dépend de ce pourquoi tu l'utilises.

Citation:

---

Envoyé par Celira

Les alternatives à cette fonctionnalité incluent :

Sodium (disponible depuis PHP 7.2.0)
OpenSSL

---

Ah ben bravo, personne ne m'avais mise au courant :ptdr:

@Sodium

La prochaine version de PHP : la 7.4 devrait offrir la possibilité de typer les variables nativement dans le genre :

Code:

---

1 2 3 4

class Foo { private int $bar; }

---

Un peu de lecture par ici
Sortie prévue : Novembre 2019

rawrc ? le typage sera optionnel ou obligatoire ?

Je vois mal l'équipe PHP forcer tous ses utilisateurs à réécrire entièrement leur code pour pouvoir passer à cette version ;)

Moi aussi mais on peut se trouver dans une situation ou par défaut c'est obligatoire et désactivable dans le php.ini ou complètement optionnel, c'est plutôt çà le sens de ma question.

Ca sera optionnel, peut-être éventuellement possible de le forcer via un mode strict ou autre, et je peux te le dire sans même avoir à vérifier la doc. Ils n'auraient aucun intérêt à forcer le typage, ça n'est pas dans la culture de PHP ni même dans la culture du web tout court. Même TypeScript, qui a type dans le nom ne le force pas. Je ne pense pas que ça soit non plus le cas de Java ou C# (mais je veux bien être corrigée si j'ai tort). Et puis ça serait très compliqué à mettre en oeuvre avec les tableaux PHP qui peuvent contenir n'importe quoi.

Citation:

---

Envoyé par Sodium

Et puis ça serait très compliqué à mettre en oeuvre avec les tableaux PHP qui peuvent contenir n'importe quoi.

---

euh, personnellement j'utilise des tableaux typés sans trop de difficultés.
Quand t'as besoin d'avoir la certitude du type des valeurs contenues dans un tableau il te suffit de créer une classe qui implémente les interfaces qui vont bien. Dans mon framework, j'utilise une classe qui fait le boulot :

Code:

---

1 2 3 4 5 6

abstract class ArrayOf implements \ArrayAccess, \Iterator, \Countable { // ... }

---

Alors effectivement ce n'est pas du natif au sens où tu l'entends (je crois deviner) mais ce n'est pas lourd et ça répond au besoin

Je n'ai pas dit que ça n'était pas envisageable d'utiliser des tableaux typés, mais que vu que la communauté PHP est habituée à y mettre tout et n'importe quoi depuis plus de 20 ans adapter du code existant serait un cauchemar, bien plus que de typer de simples variables ;)

merci à toutes et tous pour ces infos, alternatives et liens .. qui ont, en bonne partie, débloqué ma situation . Un peu de lecture en perspective pour faire chauffer le clavier.
je poursuis et, probablement, reviendrai vers vous au prochain "mur trop haut"... en espérant ne pas déclencher un tsunami de passions

Bonsoir à toutes et tous

J'ai eu quelques problèmes perso qui m'ont obligés à décrocher en cours de route et je n'ai pas pu vous remercier de votre sollicitude à toutes et tous ...
je tente de reprendre le codage
bonne soirée