PHP est utilisé par plus de 80 % des sites, toutefois 96 % de ces sites utilisent la version 5 du langage

Version imprimable

Voir 40 message(s) de cette discussion en une page

10/02/2017, 21h50
Malick

3 pièce(s) jointe(s)

PHP est utilisé par plus de 80 % des sites, toutefois 96 % de ces sites utilisent la version 5 du langage

PHP est utilisé par plus de 80 % des sites, toutefois 96 % de ces sites utilisent encore la version 5 du langage,
selon un rapport de la W3Techs

Comme il est de coutume, le cabinet d'études W3Techs (World Wide Web Technology Surveys) a mené une étude portant sur la fréquence d'utilisation du célèbre langage PHP par les sites Web. Son étude ne se limite pas à cela, car W3Techs s'est également intéressé à la position de ce dernier sur le Web, en comparaison avec d'autres langages de programmation très populaires à l'instar de Java, ASP.NET, ColdFusion, etc. Toutefois, W3Techs précise que cette étude prend en compte le top 10 millions des sites les plus fréquentés, cela afin de limiter l'impact des spammeurs de domaine.

L'exploitation du rapport publié par le World Wide Web Technology Surveys montre que parmi les langages de programmation côté serveur les plus utilisés par les sites web, PHP est en tête du classement. En effet, le cabinet W3Techs, au terme de son étude, a conclu que PHP est utilisé par 82,5 % des sites Web et se positionne loin devant ASP.NET (15,3 %) et Java (2,7 %).

Pièce jointe 243467

Il est également précisé dans le rapport que les sites Web en question utilisent différentes versions du langage PHP. Toutefois, c'est la version 5 dudit langage qui est classée première de la liste des versions les plus utilisées avec un pourcentage de 96 %. Comme le montre le schéma suivant, la version 7 de PHP vient en deuxième position avec 3,0 % de sites et elle est suivie par la version 4 avec 1,0 %. Les sites Web utilisant la version 3 de PHP pèsent moins de 1 % selon le W3Techs.

Pièce jointe 243478

Pour mieux faire apparaître le positionnement du langage PHP sur le marché des langages de programmation les plus populaires, le cabinet d'étude W3Techs a établi le schéma ci-après :

Pièce jointe 243482

« Ce diagramme montre la position du langage PHP sur le marché en termes de popularité. Une technologie située sur le coin inférieur droit est utilisée par de nombreux sites, mais surtout par les sites dont le trafic est moyen. Une technologie dans le coin supérieur gauche n'est pas utilisée par beaucoup de sites, toutefois la plupart des sites qui l'utilisent sont à fort trafic. La meilleure position serait le coin supérieur droit », a déclaré W3Techs.

Il convient de rappeler que la part de marché de PHP sur le Web est très largement boostée par l'utilisation massive de scripts très populaires comme les scripts de CMS, ou par la prolifération des forums entre autres raisons.

Source : W3Techs

Et vous ?

:fleche: Que pensez-vous des statistiques de W3Techs ?

:fleche: Qu'est-ce qui freine l'adoption de PHP 7 selon vous ?

:fleche: Si vous avez adopté PHP 7, quelles améliorations avez-vous appréciées le plus ?
11/02/2017, 02h07
badaze

J'ai adopté PHP 7 tout simplement parce que mon hébergeur m'a dit "Tu passes à PHP7 ou bien on te facture 5 € HT en plus chaque mois si tu veux rester en version 5". Tout ça pour dire que ce n'est pas l'attrait de la nouveauté ni les nouvelles fonctionnalités qui m'ont poussé à l'adopter.

Bien que je sois un professionnel de l'informatique, le PHP n'est qu'un hobby et de ce fait je n'ai pas énormément de temps à lui consacrer. Il y a un 15aine d'années je me suis écrit mon propre CMS que j'utilise pour mon site internet. J'avais déjà vécu le passage de PHP 4 à PHP 5 qui s'était traduit grosso modo par un remplacement de $HTTP_POST_VAR en $_POST, etc..
Mais le passage à PHP 7 m'a obligé à reprendre tout le code que j'avais écrit (un bon millier de fichiers au final) afin de remplacer telle fonction dépréciée par telle autre qui n'était pas forcément identique (je pense notamment aux fonction ereg remplacées par preg). Mais surtout ce qui m'a le plus embêté c'est l'abandon des fonctions MySQL_ remplacées par mysqli_ qui n'ont pas les mêmes paramètres !!! Encore heureux que le SQL soit le même !!! Après quelques instants de réflexion j'ai trouvé une solution qui m'a permis de migrer toutes les fonctions SQL en deux coups de cuiller à pot.

Les nouvelles fonctions SQL apportent sûrement plein de nouvelles choses utiles, mais pour moi c'est incompréhensible de devoir supprimer les anciennes. Je m'explique. Si les anciennes ne sont pas optimisées et bien il suffit de les optimiser sans changer leurs noms ni leurs paramètres. Si les nouvelles fonctions apportent de nouvelles fonctionnalités il ne faut pas oublier que les scripts qui ont été écrits avant leur apparition n'en n'avaient pas besoin et que des méthodes alternatives ont été trouvées pour les simuler si nécessaire. Bref ils auraient pu dire, on vous conseille fortement d'utiliser les nouvelles fonctions tout en gardant les anciennes.

Comme je le disais précédemment je ne travaille pas avec PHP. Mais j'imagine que pour tous ceux dont c'est le métier cela ne doit pas être évident. En effet un adage informatique dit "On ne touche pas quelque chose qui fonctionne bien". Avec PHP 7 il faut modifier du code, le retester et vendre ça aux clients. Ca ne doit pas toujours être facile !

Bref à mon avis, le frein au développement de PHP 7, tant que la version 5 sera maintenue, est cet ensemble de petites choses qui doivent représenter un beau budget et tout le monde sait qu'un Euro dépensé dans 2 ou 3 ans vaut mieux que 50 centimes dépensés tout de suite.

Ce n'est que mon avis.
11/02/2017, 03h12
Tsilefy

Tant que Cpanel ne proposera pas PHP7 par défaut, elle n'aura aucune chance de monter significativement en part car Cpanel gère l'immense majorité des hébergements PHP (mutualisés, dédiés ou VPS). La bonne nouvelle c'est que PHP 7 est déjà disponible sur Cpanel, il reste juste à la mettre par défault

Citation:

Envoyé par badaze

Les nouvelles fonctions SQL apportent sûrement plein de nouvelles choses utiles, mais pour moi c'est incompréhensible de devoir supprimer les anciennes. Je m'explique. Si les anciennes ne sont pas optimisées et bien il suffit de les optimiser sans changer leurs noms ni leurs paramètres. Si les nouvelles fonctions apportent de nouvelles fonctionnalités il ne faut pas oublier que les scripts qui ont été écrits avant leur apparition n'en n'avaient pas besoin et que des méthodes alternatives ont été trouvées pour les simuler si nécessaire. Bref ils auraient pu dire, on vous conseille fortement d'utiliser les nouvelles fonctions tout en gardant les anciennes.

Ces fonctions ont été retirées parce qu'elles sont dangereuses. Dans un monde idéal, il aurait suffi de dire "attention, l'extension mysql est dangereuse, ne l'utilisez plus" et cela aurait suffi. Malheureusement, la quantité massive de tutoriaux et de codes obsolètes (des milliers de pages de Stack Overflow par exemple) en ligne font que les débutants continuaient à les utiliser plutôt que PDO ou mysqli, et ces débutants vont ensuite devenir des pros qui vont développer des sites, ou des plugins Wordpress/Drupal/Joomla... ce qui explique la facilité avec laquelle on peut pirater beaucoup de sites.

Bref, faire une migration est toujours pénible et personne ne le fait gaiement, mais c'est parfois la seule solution.
11/02/2017, 09h16
chrtophe

Les fonctions dépréciées restent en général présentes pendant quelques versions et déclenchent un Warning qu'on peut ne pas afficher.

Conscient que cela ne pose pas de problèmes aux développeurs qui ne font que ça (mis à part le travail supplémentaire de reprise de code), je rejoint badaze dans le sens ou c'est chiant de devoir reprendre un code à cause de changement de fonctionnement du langage quand on ne fait pas que ça.

Et bonjour la galère pour le client final qui a payé pour un site et qui doit faire reprendre celui-ci car son hébergeur lui dit ne plus gérer telle ou telle version de PHP.

Dans le cas d'un accès à une base de données par exemple. Une bonne pratique en programmation de mise dans une fonction du code faisant les appels à une base de données permet d'avoir très peu de code à reprendre.
11/02/2017, 09h21
RyzenOC

moi pour ma part j'ai passé mon framework à PHP7 sans trop probleme, j'ai passé 1 mâtiné en tous. Faut dire que je l'avais fais fonctionner à 100% en php5.6 l'année d'avant et donc que les différences entre php 5.6 et 7 sont très minime.
Par contre les performances sont au rendez vous et sa fait plaisir !!!
C'est une migration que je trouve très utile sur ce point, pour qui veut plus de puissance.

Sinon je savais pas que ASP était plus utilisé que Java, je croyais que c'étais l'inverse comme quoi...
De meme je savais pas qu'on pouvait faire un site web en Erlang 8O sa mérite d'aller y faire un tour.
Si quelqu'un à déjà fait un site web en erlang si il pouvait me donner le contexte et les avantages ? je pense que l'avantage c'est une répartition des charges sur plusieurs serveurs directement dans le langage, mais on peut faire la meme chose avec une surcouche comme Slurm.
11/02/2017, 09h25
chrtophe

Citation:

De meme je savais pas qu'on pouvait faire un site web en Erlang sa mérite d'aller y faire un tour.

Avec les scripts CGI, tu peux utiliser le langage de ton choix.
11/02/2017, 10h44
badaze

Citation:

Envoyé par Tsilefy

Tant que Cpanel ne proposera pas PHP7 par défaut, elle n'aura aucune chance de monter significativement en part car Cpanel gère l'immense majorité des hébergements PHP (mutualisés, dédiés ou VPS). La bonne nouvelle c'est que PHP 7 est déjà disponible sur Cpanel, il reste juste à la mettre par défault

Ces fonctions ont été retirées parce qu'elles sont dangereuses. Dans un monde idéal, il aurait suffi de dire "attention, l'extension mysql est dangereuse, ne l'utilisez plus" et cela aurait suffi. Malheureusement, la quantité massive de tutoriaux et de codes obsolètes (des milliers de pages de Stack Overflow par exemple) en ligne font que les débutants continuaient à les utiliser plutôt que PDO ou mysqli, et ces débutants vont ensuite devenir des pros qui vont développer des sites, ou des plugins Wordpress/Drupal/Joomla... ce qui explique la facilité avec laquelle on peut pirater beaucoup de sites.

Bref, faire une migration est toujours pénible et personne ne le fait gaiement, mais c'est parfois la seule solution.

En quoi sont-elles dangereuses ?
Avec mysqli_query on passe toujours une requête. Si les contrôles des données passées à la requête ne sont pas faits correctement cela sera toujours aussi dangereux qu'avec MySQL_. Car il ne faut pas se leurrer, je ne pense pas que les gens qui ont migré de MySQL_ à mysqli_ ont tout réécrit pour bénéficier des prepared statements ou bien sont passés à PDO surtout s'il y a des milliers de scripts à contrôler. Elles ont dû (comme presque toujours en informatique) parer au plus pressé donc au plus rapide pour le coût le plus faible possible.
Comme je l'écrivais dans mon premier post un des principes de l'informatique est qu'on ne touche pas quelque chose qui fonctionne (ce qui explique que 60 ans après il y a toujours des systèmes qui fonctionnent en COBOL). Après le changement il faudrait normalement tout re tester pour s'assurer que tout fonctionne toujours bien ce qui du point de vue d'une entreprise se traduit par du non facturable. Combien le font ou l'ont fait ? Peu je pense. Ils doivent se contenter de tester une ou deux pages.

Question à ceux qui ont migré de MySQL_ à mysqli_. Comment vous y êtes vous pris ? Qu'avez vous modifié ?

Pour ce qui est des tutoriaux et codes obsolètes. Je suppose que dans les entreprises il y a des règles pour la programmation. Dans ce cas il suffit de dire qu'à partir de telle date on n'utilise plus MySQL_ dans les nouveaux développements. Ensuite pour les développeurs du Dimanche qu'il y ait MySQL_ ou mysqli_ les données ne seront pas plus contrôlées après qu'avant.

Pour ce qui est de la facilité à pirater des sites. C'est plus un problème de contrôle des données qu'un problème de librairie. Certes, si le langage peut donner des outils pour pallier en partie ces problèmes ce n'est que mieux mais il faut penser aussi à l'existant et à la pérennité du développement. Si au bout de quelques années on vient me dire que le site internet qui fonctionne très bien et qui m'a coûté une blinde doit être repris parce que la version de PHP a changé je vais l'avoir mauvaise et j'aurai tendance à prendre la solution qui consiste à garder la version de PHP le plus longtemps possible voire même après l'arrêt de la maintenance et si je dois faire refaire entièrement mon site je demanderai qu'il soit programmé dans un langage qui ne change pas tous les 4 matins.
11/02/2017, 11h25
Zefling

Personnellement, mon plus gros problème pour passer à PHP7 sur mon serveur, ce n’était pas pour mon site. Ç'a dû me prendre 1 heure à tout casser pour corriger les problèmes liés au changement, si j'oublie get_browser qui est tout bonnement devenu inutilisable. Pour MySQL, j'avais déjà fait la transition pour PHP5.6. Mais c'est surtout les outils que j'avais installés sur mon serveur, la version des repos n'est pas compatible avec PHP7 et je n'avais pas spécialement envie d'entamer une mise à niveau du serveur. Les mettre à jour c'était un poil plus compliqué. Finalement, ça m'a demandé un bon week-end pour faire la transition, à quelques bugs près. Il ne faut pas croire que la transition est aussi anodine que peut le penser. Par contre, le TRÈS bon point, c'est que j'ai divisé par 2 ma consommation CPU, et en même temps, le temps de calcul PHP de mes pages.

J’espère tout de même que le passage sur 7.1 sera plus simple. :mrgreen:

Citation:

Envoyé par badaze

Question à ceux qui ont migré de MySQL_ à mysqli_. Comment vous y êtes vous pris ? Qu'avez vous modifié ?

Perso, dans mon framework, j'ai une classe qui gère tout les accès bases de données, donc je n'avais qu'une classe à adapter sans rien toucher ailleurs.
12/02/2017, 01h29
Invité

Je trouve difficile de dire que le problème d'un langage soit son évolution. Dans ton cas je remettrais plutôt en cause ton hébergement car autant je comprendrais qu'il coupent php4 une fois php7 en place mais php5 ça me semble gonflé.
12/02/2017, 03h58
ABCIWEB

Citation:

Envoyé par badaze

Si au bout de quelques années on vient me dire que le site internet qui fonctionne très bien et qui m'a coûté une blinde doit être repris parce que la version de PHP a changé je vais l'avoir mauvaise et j'aurai tendance à prendre la solution qui consiste à garder la version de PHP le plus longtemps possible voire même après l'arrêt de la maintenance et si je dois faire refaire entièrement mon site je demanderai qu'il soit programmé dans un langage qui ne change pas tous les 4 matins.

Cela fait au moins cinq ans que les messages de la doc indiquent de ne plus utiliser mysql. On a eu le temps de voir venir. Et tu peux toujours utiliser php5.6 pour garder la compatibilité mysql.

Sinon je suis pas certain que tu trouves un autre langage de programmation web qui soit aussi facile à mettre à jour que php au fil des versions. Certes la suppression de mysql fait beaucoup de travail pour ceux qui ne s'y sont pas préparés, mais la maintenance fait normalement partie d'un site web surtout s'il coute une blinde. Et puis c'est quand même la seule grosse maj depuis plus de dix ans, les autres étaient beaucoup plus vite faites.

Si tu veux vraiment te faire peur au niveau des maj tu peux regarder ce message qui parle d'angular ;)

Pour passer de mysql à mysqli sur les gros sites existants j'ai fait des recherches/remplacements (il y a déjà plusieurs années). Cela peut prendre un certain temps avec les tests mais c'est somme toute très supportable puisqu'une maintenance était vendue avec. J'ai simplement majoré un peu en disant que c'était un investissement pour éviter d'être pris de court plus tard.

Pour les petits sites existants (sans maintenance réelle mais avec juste un suivi), je reste avec php 5.6 tant que je pourrai. Mais bon ils ont déjà huit ans et si ça peut faire encore quelques années, les gens ne râleront pas pour une maintenance après plus de dix ans.

Pour le code/lib qui devait resservir ça a été plus long car je suis passé à PDO qui est beaucoup plus pratique et agréable à écrire. Il faut considérer mysqli pour une mise à jour rapide depuis mysql sinon ce n'est pas un standard intéressant.
12/02/2017, 09h25
TiranusKBX

à tous ceux qui râles pour les MAJ de PHP faitent des classes/fonctions personnalisées pour tout !
Comme ça si modification il doit y avoir seulement les classes/fonctions personnalisées son à changer!
Par exemple ça doit faire 7 ans que j'ai une classe pour la gestion BDD et je l'ai réécrite 3 fois
12/02/2017, 10h51
Zefling

Citation:

Envoyé par ABCIWEB

Si tu veux vraiment te faire peur au niveau des maj tu peux regarder ce message qui parle d'angular ;).

Tu peux ajouter Angular 2, c'est la grosse cata. Surtout quand je vois le changement de Typescript 1 à 2, les « breaking changes » entre le 2 et la prochaine 4 et tout ce qui s'est passé avant 2.2. Là, j'ai l'impression que n'importe quoi est hyper stable à côté. :mouarf:
12/02/2017, 10h53
Geoffrey74

Hello,

bien qu'étant qu'un petit développeur, j'essaie toujours d'avoir des fonctions et des scripts à jour.
A chaque changement de version php, je regarde celle qui vont devenir obsolète et les remplaces dès que possible. C'est plus long, plus chiant, mais pour un changement de version majeur, comme le passage en php7, je n'ai quasiment rien eu à faire !
12/02/2017, 12h14
sabotage

Citation:

je demanderai qu'il soit programmé dans un langage qui ne change pas tous les 4 matins.

PHP5 existe depuis plus de 12 ans.
L'extension Mysql est vieille de 20 ans.
14/02/2017, 09h29
dev14

Personnellement je n'ai eu qu'un petit truc à régler en passant à la 7. On nous annonce quand même la couleur avec des fonctions dépréciées, il suffit de ne pas les utiliser.

Mais je comprends que ce soit tellement plus simple quand on n'est pas une entreprise de X employés, comme l'avant dernière où j'étais, qui tournait sur XP, campait sur son framework php procédural, sans parler des graphistes sur la suite adobe CS4, et j'en passe.
17/02/2017, 15h24
grunk

Citation:

Envoyé par badaze

En quoi sont-elles dangereuses ?

- l'extension n'était plus maintenu => donc aucun correctif possible si une faille se présente
- il lui manque une interface objet ce que les autres ont
- Elle ne gère pas les requêtes asynchrone
- Elle ne gère pas les requêtes préparées
- Elle ne gère pas les procédures stockées
- Elle ne gère pas les transactions
- et probablement encore d'autre truc

Citation:

Je suppose que dans les entreprises il y a des règles pour la programmation. Dans ce cas il suffit de dire qu'à partir de telle date on n'utilise plus MySQL_ dans les nouveaux développements. Ensuite pour les développeurs du Dimanche qu'il y ait MySQL_ ou mysqli_ les données ne seront pas plus contrôlées après qu'avant

A partir du moment ou ton API gère les requêtes préparées tu les utilises et tu n'as plus de problème de contrôle des requêtes.
Il est vrai que les tutoriaux obsolètes sont un vrai problème :(

Citation:

Pour ce qui est de la facilité à pirater des sites. C'est plus un problème de contrôle des données qu'un problème de librairie.

.
Voir juste avant. Si tu n'as pas de requêtes préparées à disposition tu es bien plus enclun à oublier un paramètre non sécurisé.

Citation:

Si au bout de quelques années on vient me dire que le site internet qui fonctionne très bien et qui m'a coûté une blinde doit être repris parce que la version de PHP a changé je vais l'avoir mauvaise et j'aurai tendance à prendre la solution qui consiste à garder la version de PHP le plus longtemps possible voire même après l'arrêt de la maintenance et si je dois faire refaire entièrement mon site je demanderai qu'il soit programmé dans un langage qui ne change pas tous les 4 matins.

Donc tu préfères rester avec un système potentiellement à risque , avec potentiellement des données sensibles plutôt que de mettre à jour.
Entre nous une boite sérieuse aura inclus dans son prix une durée de maintenance et ce genre de mise à jour devrait rien te coûter sauf si ton site à 10 ans et n'a jamais été touché
18/02/2017, 00h27
Tsilefy

Citation:

Envoyé par badaze

En quoi sont-elles dangereuses ?
Avec mysqli_query on passe toujours une requête. Si les contrôles des données passées à la requête ne sont pas faits correctement cela sera toujours aussi dangereux qu'avec MySQL_.

Oui, et avec PDO on peut aussi utiliser directement exec() ou query(). Personne n'empêche ceux qui le veulent de se tirer une balle dans le pied. Le problème c'est que l'extension mysql ne propose même pas de requêtes préparées.

Citation:

Envoyé par badaze

Car il ne faut pas se leurrer, je ne pense pas que les gens qui ont migré de MySQL_ à mysqli_ ont tout réécrit pour bénéficier des prepared statements ou bien sont passés à PDO surtout s'il y a des milliers de scripts à contrôler. Elles ont dû (comme presque toujours en informatique) parer au plus pressé donc au plus rapide pour le coût le plus faible possible.

Encore faut-il avoir le choix entre parer au plus pressé ou faire les choses convenablement. Après, c'est à chacun d'évaluer le plus intéressant pour son case.

Citation:

Envoyé par badaze

Comme je l'écrivais dans mon premier post un des principes de l'informatique est qu'on ne touche pas quelque chose qui fonctionne (ce qui explique que 60 ans après il y a toujours des systèmes qui fonctionnent en COBOL). Après le changement il faudrait normalement tout re tester pour s'assurer que tout fonctionne toujours bien ce qui du point de vue d'une entreprise se traduit par du non facturable. Combien le font ou l'ont fait ? Peu je pense. Ils doivent se contenter de tester une ou deux pages.

C'est quand même un changement mineur, rien à voir avec Python 3, Perl 6 ou, comme cité plus haut, Angular 2. Quand aux systèmes COBOL, je ne m'y connais pas grand-chose en COBOL, mais je soupçonne quand même que c'est largement pour des raisons de coûts plutôt que des raisons de performance/efficacité.

Citation:

Envoyé par badaze

Pour ce qui est de la facilité à pirater des sites. C'est plus un problème de contrôle des données qu'un problème de librairie. Certes, si le langage peut donner des outils pour pallier en partie ces problèmes ce n'est que mieux mais il faut penser aussi à l'existant et à la pérennité du développement. Si au bout de quelques années on vient me dire que le site internet qui fonctionne très bien et qui m'a coûté une blinde doit être repris parce que la version de PHP a changé je vais l'avoir mauvaise et j'aurai tendance à prendre la solution qui consiste à garder la version de PHP le plus longtemps possible voire même après l'arrêt de la maintenance et si je dois faire refaire entièrement mon site je demanderai qu'il soit programmé dans un langage qui ne change pas tous les 4 matins.

Je comprends ton idée, et je suis d'accord en principe, mais quelques fonctions à réécrire, ce n'est pas refaire entièrement le site. Et si le code était bien écrit (c'est un grand "SI", je te l'accorde), la partie qui gère l'accès à la BDD est suffisamment isolé et indépendante qu'on peut le remplacer ou le modifier facilement.
18/02/2017, 01h24
sabotage

Citation:

Comme je l'écrivais dans mon premier post un des principes de l'informatique est qu'on ne touche pas quelque chose qui fonctionne (ce qui explique que 60 ans après il y a toujours des systèmes qui fonctionnent en COBOL).

Ne change rien alors. Rien n'empêche même de faire tourner des script en PHP3.
Ton hébergeur te force à changer ? C'est un problème avec ton hébergeur, pas avec le langage.
Cobol, comme PHP, n'est pas resté figé dans le temps non plus. Au passage les programmes Cobol ont largement été touchés par le bogue de l'an 2000 à cause de l'habitude de coder l'année sur 2 chiffres.
18/02/2017, 02h22
badaze

Citation:

Envoyé par sabotage

Ne change rien alors. Rien n'empêche même de faire tourner des script en PHP3.
Ton hébergeur te force à changer ? C'est un problème avec ton hébergeur, pas avec le langage.
Cobol, comme PHP, n'est pas resté figé dans le temps non plus. Au passage les programmes Cobol ont largement été touchés par le bogue de l'an 2000 à cause de l'habitude de coder l'année sur 2 chiffres.

Je n'ai rien contre le changement bien au contraire.
Si tu as développé avec les fonctions MySQL_ je suppose que tu as bien fait ton travail et que tu as contrôlé/sécurisé les données avant de les insérer dans ta BDD. Donc même si les instructions ne sont pas intrinsèquement sûres à 100% tu t'es débrouillé pour qu'on ne puisse les prendre en défaut. Non ? Alors si tu as bien fait ton boulot pourquoi t'obliger à le modifier ? Tu as sûrement mieux à faire. Non ?

Pour ce qui est de Cobol et du bug de l'an 2000 comme tu l'écris ce n'est pas un problème dû au langage mais de conception de la solution.

Une question pour toi qui t'y connais. Est-ce que tu penses que ceux qui utilisaient les fonctions MySQL_ ont migré leur code en PDO en mysqli_ objet ou bien en mysqli_ procédural ?
18/02/2017, 03h09
ABCIWEB

Citation:

Envoyé par badaze

Une question pour toi qui t'y connais. Est-ce que tu penses que ceux qui utilisaient les fonctions MySQL_ ont migré leur code en PDO en mysqli_ objet ou bien en mysqli_ procédural ?

Je t'ai déjà répondu. Mysqli pour mettre à jour d'anciens sites mysql. PDO est le standard actuel donc on l'utilise pour les nouveaux développements depuis déjà quelques années. Mysqli en mode objet est probablement utilisé très marginalement puisque quand on fait une maj de mysql vers mysqli on ne s'amuse pas à transformer le code procédural en code objet à moins d'avoir une raison très particulière.

Voir 40 message(s) de cette discussion en une page