Cette version à l'air d'avoir la vocation de faire un gros nettoyage et risque de rendre PHP méconnaissable, et beaucoup d'applications heu... à réécrire.
Je vous fait un copié/collé de la partie intitulée "Remove" :
- register_globals (rasmus)
- magic_quotes_* (rasmus)
- safe_mode and focus on open_basedir (rasmus)
- items that have been marked deprecated since the dawn of PHP 4, and various function aliases (rasmus)
- ereg (derick)
- gd1 (pierre)
- remove freetype 1.x DONE (pierre)
- ze1.compatibility_mode (helly)
- "register_long_arrays", HTTP_GET_VARS, etc. (jani)
- Support for old type constructors
- (ezcLogMessage?::ezcLogMessage?()) (derick)
- SimpleXML? on by default
- ext/mysql (georg)
Je pense que tout ça est une bonne chose, notamment pour les register_globals, mais...
Les magic_quotes, je les désactive quand je le peux car ce n'est vraiment adapté à rien et il faut toujours repasser derrière, mais nombre de programmes les utilisent. Je pense qu'il aurais au moins fallu commencer par les désactiver par défaut, comme pour register_globals. Enfin à voir la suite, il n'y aura de toute façon plus aucune raison d'utiliser les magic_quotes.
Safe_mode et open_basedir, il y a des hébergeurs qui ne sont pas près de proposer du PHP6. A un moment ou il est important que l'hébergement PHP soit compétitif par rapport à ASP, je pense que la suppression de safe_mode et open_basedir n'est vraiment pas une bonne chose.
extension mysql: Il va falloir utiliser Mysqli ou PDO, dont l'utilisation n'est pas dutout la même. D'ailleurs le choix se restreint à PDO puisque plus loin on vois ça: move "native" non pdo extensions to pecl.
Bref, cette version va certainement mettre encore plus de temps que PHP5 à être disponible chez les hébergeurs, et beaucoup d'appli vont avoir du mal à s'en remettre, voir ne s'en remettrons pas.
Est il vraiment nécessaire de supprimer tout ça ? Ne serait il pas plus bénéfique de changer la configuration par défaut afin de garder une compatibilité avec les applications existantes ?
[1] Wishlist trouvée sur la mailing list internals. Its by no means official, but fairly complete: http://oss.backendmedia.com/PhP60
# comme php4
Posté par Damien Metzler . Évalué à 4.
Pour ma part, je pense qu'un changement de version majeure est vraiment le moment de supprimer les choses qui posent problème.
Magic Quotes : c'est effectivement de la merde. Je pense qu'il faudrait les désactiver par défaut dans les futures releases de PHP5
Pour safe_mode et open_basedir, j'ai pas d'avis. Je pense que les hébergeurs trouveront une solution plus en amont.
Extension mysql : je pense que c'est une très bonne décision que de passer par PDO. Depuis le temps que je rale sur les gens utilisant les fonctions natives au lieu d'une librairie d'abstraction (Pear ou ADODb).
Il y a aussi de bonnes choses dans PHP6, comme le support d'unicode en natif.
[^] # Re: comme php4
Posté par andeus . Évalué à 2.
C'est vrai qu'il y a encore du temps pour php6, ça va pas nous tomber dessus sans prévenir, mais ça va demander beaucoup de changements à pas mal d'appli pour être compatible php6.
Oui, mais les solutions en amont sont beaucoup plus coûteuses en ressources que le safe_mode ou open_basedir.
Oui, il y a quelques bonnes choses, comme le cache d'opcode aussi.
Par contre je ne comprend pas bien ce qu'implique le support natif d'unicode. On peut déjà utiliser unicode dans PHP non ?
[^] # Re: comme php4
Posté par Éric (site web personnel) . Évalué à 5.
> d'unicode. On peut déjà utiliser unicode dans PHP non ?
oui et non.
Les chaines de caractères sont des suites d'octets. Oui tu peux mettre de l'unicode dedans. Non PHP ne saura pas que c'est de l'unicode et ne saura rien faire avec. Il ne saura que compter les octets et envoyer tout le binaire vers l'affichage.
Ce qu'on peut faire en plus avec une connaissance d'Unicode :
- trier par ordre alphabétique en prenant en compte autre chose que a-z et A-Z (les accents, les trémas, ß, etc.)
- connaitre le nombres de caractères (et pas d'octets)
- extraire des mots, des sous-chaînes
- mettre en majuscule/minuscule
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: comme php4
Posté par andeus . Évalué à 3.
Il y a une option de php.ini qui permet d'overloader les fonctions natives par les fonctions mb_* (mbstring.func_overload).
Après avoir mis "mbstring.func_overload 7" dans le php.ini, un petit "mb_internal_encoding('UTF-8');" dans le code, et une bonne partie des fonctions de chaines gèrent l'utf8 :) (pas printf par contre).
Et pour les preg_*, il faut mettre le modifier u :)
[^] # Re: comme php4
Posté par Éric (site web personnel) . Évalué à 2.
Certes, strlen() fonctionnera sur les chaînes UTF8
Mais ceux qui utilisaient strlen() pour calculer le nombre d'octets (ils sont nombreux vu qu'il n'y avait que ça pour le faire) auront des problèmes. Si tout le code PHP qui tourne n'est pas le tien tu risques des ennuis.
Pire, ça essayera de jouer avec l'UTF8 dans tes champs binaires, types les fichiers compressés. C'est dommage et ça peut casser certaines choses (impossible de retirer les X derniers octets d'un flux binaire opaque).
A partir du moment où tu ne codes que pour mbstring, c'était mieux de le faire explicitement. Tu ne pourris pas tout ce qui cherche à calculer des nombre d'octets, et ça fonctionnera chez ceux qui ont mbstring sans avoir activé l'overload.
De toutes façons chez ceux qui n'ont pas mbstring l'appli aurait buggué donc autant que ça plante en ralant sur mbstring, c'est même presque mieux.
L'overload mbstring c'est à restreindre à des cas très précis. Par exemple l'internationalisation "en catastrophe" d'une appli qui n'était pas prévue pour.
[^] # Re: comme php4
Posté par andeus . Évalué à 2.
Par contre comment php6 gère ça ? il fait une détection sur les chaînes genre utf8/pas utf8, ou binaire/pas binaire ?
[^] # Re: comme php4
Posté par Éric (site web personnel) . Évalué à 3.
# safe_mode -> open_basedir
Posté par Éric (site web personnel) . Évalué à 5.
> compétitif par rapport à ASP, je pense que la suppression de
> safe_mode et open_basedir n'est vraiment pas une bonne chose.
Ils ne proposent pas de retirer open_basedir, c'est même limite l'inverse. Ils veulent retirer le safe_mode qui est dûr à maintenir et pose plein de problèmes pour les hébergeurs mutualisés (alors que c'est justement la cible) pour imposer plutot l'utilisation de open_basedir (qui n'agit pas sur les même choses mais qui répond assez bien au principal de la problématique).
> extension mysql: Il va falloir utiliser Mysqli ou PDO, dont l'utilisation
> n'est pas dutout la même.
L'utilisation de mysqli est (potentiellement) exactement la même que celle de l'extension mysql. A vrai dire, à part la procédure de connexion, il n'y a à mon souvenir qu'une seule fonction qui marche différement (qui renvoit NULL à la place de FALSE).
Certes, mysqli peut faire beaucoup plus de choses, va beaucoup plus loin, mais les suites de requêtes SQL et exploitation des résultats sont presques reprenables avec un rechercher/remplacer de mysql vers mysqli.
> D'ailleurs le choix se restreint à PDO puisque plus loin on vois ça:
> move "native" non pdo extensions to pecl.
L'idée de PECL c'est à la base uniquement de différencier le cycle de release de PHP de celui des extensions. Ca n'empeche même pas les packages PHP téléchageables de fournir de base les extensions concernées.
Rien n'empêche d'installer du PECL. C'est vraiment super simple. Un des buts c'est aussi le développement de PEAR et PECL. Personne ne se plaint d'avoir à utiliser CPAN au lieu d'avoir tout dans le paquet Perl de départ.
Quoi qu'il en soit, un des objectifs de ceux qui mettent en avant cette liste c'est justement de couper les vieux trucs qu'ils ne veulent plus maintenir et qu'ils considèrent comme une mauvaise idée.
Donc oui, il y a des choses qui ne marcheront plus avec les anciennes méthodes, et ils faudra utiliser les nouvelles.
> Est il vraiment nécessaire de supprimer tout ça ? Ne serait il pas
> plus bénéfique de changer la configuration par défaut afin de
> garder une compatibilité avec les applications existantes ?
C'est ce qui est fait pour l'instant et .. ça ne marche pas.
Les gens gardent les anciens php.ini. Au final on a toujours les problèmes de portabilité, de compatibilité, et on doit toujours supporter tous les systèmes "historiques" qu'on aimerait jeter.
Cette cassure on est beaucoup à l'attendre. Certains (dont moi) l'espéraient déjà pour PHP5, et malheureusement ils n'en ont pas profité.
[^] # Re: safe_mode -> open_basedir
Posté par andeus . Évalué à 1.
Ok, je n'avais pas compris ça comme ça. C'est plutôt une bonne chose alors :)
En fait je suis passé directement de l'extension mysql à PDO sans passer par mysqli, je n'avais vu que des exemple d'utilisation orientés objet, plus difficilement adaptable à quelque chose d'existant. Mais en effet ça à l'air d'être utilisable à peu près de la même façon que l'extension mysql.
Oui c'est simple d'installer une extension avec pear ou phpize, mais on ne trouve pas souvent d'extensions PECL chez les hébergeurs mutualisés.
[^] # Re: safe_mode -> open_basedir
Posté par Mr F . Évalué à 1.
Très peu d'hébergeur mutualisé utilisent actuellement le safe_mode, il est bien trop restrictif par rapport au cahier des charges necessaire pour être compétitif en therme de fonctionnalités.
C'est effectivement d'avantage une solution à base d'open_basedir et de forbiden_fonctions qui est utilisé par les hébergeurs. Si PHP6 pouvait intégrer en plus directement un équivalent à suexec, ce serait parfait.
[^] # Re: safe_mode -> open_basedir
Posté par Éric (site web personnel) . Évalué à 3.
> de forbiden_fonctions qui est utilisé par les hébergeurs. Si PHP6
> pouvait intégrer en plus directement un équivalent à suexec, ce serait
> parfait.
Ca n'est pas son rôle et ce n'est pas forcément réalisable.
Installé en module ce n'est pas faisable. Si le process apache-php change ses droits d'accès, il ne pourra pas retourner dans son utilisateur initial après et ne pourra pas être réutilisé.
Installé en CGI il y a déjà plein de wrapper de ce type. Suexec est fourni avec Apache mais il en existe d'autres moins couplés au serveur Web. Quel serait l'avantage pour PHP d'implémenter ça en interne ?
[^] # Re: safe_mode -> open_basedir
Posté par Mr F . Évalué à 1.
C'est une vue de l'esprit.
Installé en CGI il y a déjà plein de wrapper de ce type.
Justement, d'ou l'idée de ne pas s'encombrer d'un wrapper supplémentaire.
Suexec est fourni avec Apache mais il en existe d'autres moins couplés au serveur Web
Suexec ne permet absolument pas de remplir ce rôle. Et s'il en existe d'autres, il n'en existe pas tant que ça non plus.
Quel serait l'avantage pour PHP d'implémenter ça en interne ?
De permettre d'avoir un système sécurisé sans devoir rajouter quoi que ce soit d'autre.
Je serais plutôt tenter de demander : En quoi est ce génant que php incorpore directement ce type de code, activable a souhait, permettant de supprimer les wrappers divers et varié ?
[^] # Re: safe_mode -> open_basedir
Posté par Éric (site web personnel) . Évalué à 1.
Parce que ça veut dire rajouter dans PHP un code qui n'a rien à voir avec le langage de programmation, qui est très sensible coté sécurité, et qui de plus risque de ne pas être portable aussi bien que PHP (il faut au minimum un ifdef pour windows)
Avoir plusieurs softs, chacun avec un role et une fonction définie c'est bien. Les gros trucs monolithyques qui font le café c'est inmaintenable assez vite.
> Suexec ne permet absolument pas de remplir ce rôle.
> Et s'il en existe d'autres, il n'en existe pas tant que ça non plus.
Il le tient pourtant à plein d'endroits. Ca doit être le wrapper le plus utilisé pour ça. Pourquoi ne pourrait-il pas convenir d'après toi ?
Et s'il n'en existe pas des centaines d'autres il doit bien en exister 3 ou 4 de courants, ce qui est largement assez pour un soft de ce type.
> De permettre d'avoir un système sécurisé sans devoir rajouter quoi
> que ce soit d'autre.
Tu rajoutes bien apache, tu rajoutes l'OS, tu rajoutes les libs, tu rajoutes tes comptes utilisateur ... PHP ne contient pas tout et n'est pas fait pour ça. Pourquoi vouloir intégrer suexec et pas directement le serveur Web par exemple ?
C'est un langage de programmation, pas un serveur d'application, et encore moins une plate-forme complète.
[^] # Re: safe_mode -> open_basedir
Posté par Mr F . Évalué à 1.
Sans allez a l'extrème, il s'agit simplement d'une fonctionnalité lié de façon très proche avec PHP.
Il le tient pourtant à plein d'endroits. Ca doit être le wrapper le plus utilisé pour ça. Pourquoi ne pourrait-il pas convenir d'après toi ?
Parcequ'il n'éxècute pas de binaire en ce basant sur le uid du fichier lancé, mais en ce basant sur l'url (la partie ~user). De plus il ne supporte pas les virtual uid.
Donc non, il ne convient pas, et non, ce n'est pas le plus utilisé dans le domaine de l'hébergement (et c'est un domain que je connais bien).
Tu rajoutes bien apache, tu rajoutes l'OS, tu rajoutes les libs, tu rajoutes tes comptes utilisateur ... PHP ne contient pas tout et n'est pas fait pour ça. Pourquoi vouloir intégrer suexec et pas directement le serveur Web par exemple ?
C'est un langage de programmation, pas un serveur d'application, et encore moins une plate-forme complète.
Il s'agit justement de fixer la bonne limite entre une fonctionnalité pouvant être incorporé et "le reste du monde".
Et en l'occurence, c'est une fonctionnalité qui pourrait être implémenté directement dans PHP, sans que cela le transforme en usine à café brésilien, et qui permettrait de supprimer une couche non necessaire.
Mais bref, nos point de vue diverges, autant arrêter là.
[^] # Re: safe_mode -> open_basedir
Posté par Anonyme . Évalué à 0.
Donc non, il ne convient pas, et non, ce n'est pas le plus utilisé dans le domaine de l'hébergement (et c'est un domain que je connais bien).
Il y a suphp pour ca.
# Bonne nouvelle
Posté par Guillaum (site web personnel) . Évalué à 8.
Moi je suis plutot pour la philosophie inverse, on efface tout et on recomence. À partir de la sortie de php6 on saura que l'on tournera dans un environement de réglages uniformisés, ce qui simplifiera completement les devellopements.
Le temps que cela arrive chez les hebergeurs, on s'en balance. Php est assez complet pour n'importe qui actuellement, et ce n'est pas php6 qui risque d'apporter son lot de fonctionalitées vitales. Bref, le fait de ne pas disposer de php6 chez les hebergeurs de classes moyennes n'handicapera personne. Par contre, il sera possible d'installer du php6 et de profiter de ses qualitées 'propres' pour des gens disposant des clefs de leur serveurs.
Pour les magics quotes, il est clair que c'est quelque chose qui doit sauter. Alors le faire progressivement ou d'un coup, je suis partant pour d'un coup. Il va juste se passer qu'une bonne quantité de programmeurs (même "proffessionels') vont se retrouver avec des applications bancales voir cassées (voir non sécurisées). Et après ? Un petit apprentissage des téchniques de développements avec php ne feras du mal à personne.
Bref, pour moi c'est une tres bonne chose.
[^] # Re: Bonne nouvelle
Posté par Victor STINNER (site web personnel) . Évalué à 1.
Il existe des bouts de code pour "émuler" register_globals ! Rassurez-vous, messieurs, on pas encore faire du code tout pourri :-)
Haypo
[^] # Re: Bonne nouvelle
Posté par Anonyme . Évalué à 4.
Ouais ouais, avec PHP il y a sacrement besoin d'apprendre. Il faut toujours apprendre parce que rien n'est jamais logique, un peu à l'image des noms des fonctions.
Moi qui maintiens une application partiellement en PHP, et qui est très ancienne, je m'en mords les doigts quotidiennement. Je ne suis pas pressé de la voir venir cette nouvelle version de PHP.
Avec Perl, je code, avec PHP je corrige du code, je corrige du code.
[^] # Re: Bonne nouvelle
Posté par vieuxshell (site web personnel) . Évalué à 2.
Avec php: ca "coule de source", la doc est super, ...
Avec perl: obligé d'avoir "Programmation en perl" et "Perl en action" pour chaque bout de code. Et c'est l'enfer quand j'ai du code à reprendre qui a plus d'une semaine ou -pire- que je n'ai pas écrit.
Par contre je dirai que je ne maitrise pas le perl (et en plus j'aime pas), ca vient peut etre de là.
# ereg ?
Posté par fabien . Évalué à 3.
il y a un probleme a utiliser ereg ? ca marche tres bien.
suppression de mysql : c'est pas une bonne idée je trouve...
pour moi seuls les points 1 et 2 comptent, et encore c'est dejà desactivable....
donc, non tout ca c'est pas une bonne idée.
[^] # Re: ereg ?
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Je sais pas. Par contre, il est noté dans la doc' PHP, et ce depuis longtemps, que preg* est plus rapide que ereg*. Ca fait peut-être doublon (double temps de maintenance entre autres) ?
Haypo
[^] # Re: ereg ?
Posté par Julien Duponchelle (site web personnel) . Évalué à 1.
[^] # Re: ereg ?
Posté par Éric (site web personnel) . Évalué à 2.
Parce que ereg() est grosso modo 100x plus lent que preg_match(), et non, ce n'est pas un chiffre lancé au hasard.
L'idée jetée il y a longtemps c'était de supprimer la bibliothèque d'expressions rationnelles posix et de créer une extension dans PECL qui émule ereg() en transformant la syntaxe pour utiliser preg_match() en sous-main.
> suppression de mysql : c'est pas une bonne idée je trouve...
Parce que ?
> pour moi seuls les points 1 et 2 comptent, et encore c'est dejà
> desactivable...
Désactivable oui mais , est-ce désactivé ? le truc ce qu'on est obligés de faire 150 patchs à toutes les applications pour pouvoir livrer sur toutes les configurations possible.
C'est très pénible et pour les développeurs d'application, et pour les hébergeurs qui font le support, et pour les développeurs de PHP qui assurent la maintenance.
C'est d'autant plus pénible qu'on sait que certaines options sont mauvaises et font plus de mal que de bien, qu'elles n'auraient jamais du exister.
Ces options désactivables sont considérées comme obsolètes depuis longtemps, il est temps de les jeter et d'arrêter de se trainer des boulets toute la vie.
[^] # Re: ereg ?
Posté par fabien . Évalué à -2.
>Parce que ereg() est grosso modo 100x plus lent que preg_match()..
est-ce la même syntaxe ?
si non : pas uen bonen idée de supprimer car ca casse tout.
si oui, il suffit de faire un wrap entre les 2 fonctions.
conclusion : pas la peien de supprimer .
>> suppression de mysql : c'est pas une bonne idée je trouve...
>Parce que ?
en deux mots : parce LAMP.
en plus de mot : le success de PHP va de paire avec celui de Mysql.
dejà livrer PHP sans Mysql, c'est casser l'enorme majorité des dev qui utilisent mysql (je dirais que 80% des sites utilisant un base de données utilisent mysql).
>> pour moi seuls les points 1 et 2 comptent, et encore c'est dejà
>> desactivable...
>Désactivable oui mais , est-ce désactivé ? le truc ce qu'on est
>obligés de faire 150 patchs à toutes les applications pour pouvoir
>livrer sur toutes les configurations possible.
ouai, de deux choses l'une : tu dev un intra (par ex.) ou tu es maitre du serveur et de ton PHP.IN alors là c'est hyper facile, une option a changer une fois pour toute.
ou alors t'as pas le droit de toucher au serveur (hebergeur) et là, rien ne t'empeche de gerer ces options dans un fichier include au debut de ton script (là par exemple ou tu met ton session_start et cie..)
et ensuite, t'en entends plus parler.
donc, voilà rien de penible en soit, juste un minimum de rigueur.
Et encore je ne trouve pas tres difficile de faire un ptit
require_once("general.inc.php"); au debut de chaque fichier.
[^] # Re: ereg ?
Posté par Frédéric . Évalué à 2.
> en plus de mot : le success de PHP va de paire avec celui de Mysql.
> dejà livrer PHP sans Mysql, c'est casser l'enorme majorité des dev qui
> utilisent mysql (je dirais que 80% des sites utilisant un base de données
> utilisent mysql).
Sauf erreur de ma part, il ne s'agit pas de supprimer purement et simplement la possibilité d'interagir avec une base de données MySql, mais de supprimer les fonctions mysql_* au profit de l'extension mysqli (http://fr.php.net/manual/fr/ref.mysqli.php) qui peut être utilisée quasiment de la même manière. (-> https://linuxfr.org/comments/648088.html#648088).
[^] # Re: ereg ?
Posté par Éric (site web personnel) . Évalué à 3.
> si non : pas uen bonen idée de supprimer car ca casse tout.
> si oui, il suffit de faire un wrap entre les 2 fonctions.
> conclusion : pas la peien de supprimer .
Non, ce n'est pas la même syntaxe.
Ceci dit si tu ne sais pas ça (c'est à dire que tu n'as aucune connaissance sur le sujet), et dit vraiment sans aucune agressivité ni aucun reproche, je ne suis pas sûr qu'exprimer un avis avant de te documenter soit forcément pertinent.
Pour le wrapp c'est justement ce qui a été proposé un temps (cf le commentaire auquel tu répond). Reste à voir si ça vaut le coup, si beaucoup de gens ont du ereg() difficile à passer en preg().
De toutes façons les gens qui auront du vieux code ne pourront pas le passer sans migration dans le nouveau moteur si toute la liste est effectivement appliquée. Et franchement passer les ereg en preg ce n'est pas le pire. Du coup ce n'est pas dit que perdre du temps à faire le wrapper soit forcément pertinent.
> dejà livrer PHP sans Mysql
Si on veut être précis : depuis PHP 5 mysql n'est plus par défaut. Je ne suis même pas sûr que le client MySQL soit livré dans PHP 5.1.0 (on préfère le client externe à celui qui était builtin auparavant).
Ce n'est pas parce qu'il n'est pas dans le package par défaut que tu ne peux pas le compiler.
Ceci dit il me semble que tu as mal compris. Il ne s'agit pas de retirer le support de Mysql. Il s'agit de retirer une des extensions qui permet d'accéder à Mysql (et de laisser les autres : PDO et mysqli). Si on retire celle là c'est parce qu'elle ne supporte que mysql 3.23, qui commence à être de plus en plus vieux (il y a eu 3 versions majeures stables depuis : 4.0, 4.1 et 5.0, il y en aura probablement au moins une de plus d'ici PHP6). Les autres extensions permettent d'accéder au 3.23 mais aussi aux plus récentes.
> Et encore je ne trouve pas tres difficile de faire un tit
> require_once("general.inc.php"); au debut de chaque fichier.
Là aussi, n'y vois aucun mal, mais j'ai l'impression que tu ne connais pas la problématique.
La plupart des options dont on parle ce sont justement celles qui ne sont pas modifiables dans le script PHP lui même (register_globals, long_arrays, magic_quotes_gpc, ...)
De plus là où tu ne contrôles pas le .ini il est fréquent de ne pas avoir non plus accès à ini_set()
Et quand bien même tu as accès au .ini, tu vas avoir des problèmes quand telle lib te demande un "On" et telle autre un "Off". Ou plus bêtement quand ça te demande un "On" mais que c'est un risque de sécu non négligeable que tu voudrais éviter.
[^] # Re: ereg ?
Posté par fabien . Évalué à 2.
Primo ma question était être purement rethorique. (qui aide mon argumentation si tu prefere : ue ce soit oui ou non, la conclusion est la même, tu as du le remarquer)
secondo, je vais être parfaitement franc : OUI je sais utiliser les expression reguliere avec ereg* (pas d'un niveau expert c'est vrai) et NON je ne connais pas preg* justement parcequ'avec ereg j'ai tout ce qui me fallait et j'en suis bien content. au moment de choisir entre les deux je me rappelle avoir comparé la syntaxe, et pris celui qui me plaisait le mieux (et que je *trouvais* plus simple) [rappel : trouver!=etre].
voilà, pour mysql, je ne suis sûr de rien mais en lisant le post au dessus du tiens, Frédéric explique que c'est *uniquement* les fonction mysql_* qui vont disparaitre (ha ouais cool, ben heuresement que c'est uniquement ca, qu'est-ce que ca aurait été si ca avait été pire ?!)
quand je lis ton post, j'ai l'impression que c'est un peu different. (vu que sur une de mes machines j'ai un mysql 4.0.17 qui tourne et que je continue a utilise les fameuses fonction mysql_* je me dis que vos post en sont pas sur la même longueur d'onde (vu que d'apres toi ce qui sera supprimé ne concerne que du mysql 3.23)...
donc en bref, ca marche comment ? est-ce que je pourrait continuer a utiliser les fonction mysql* ???
ou alors j'ai rien compris du tout (et non je ne le prends pas mal si tu m'explique :) )
ha ?
j'avoue que j'en sais rien, vu que moi, mon serveur intranet c'est moi qui ai mis les "bonnes" options dans php.ini.
mais justement je pensais a ini_set().
vu que le changement n'est applicable que pour le temps ou le fichier est traité, j'etais (je le suis encore) convaincu qu'on pouvait utiliser ini_set() pour mettre les register global a off, ainsi que les magic_quotes.
encore une fois,mes propos peuvent paraitrent d'une incompetence notoire (ca expliquerais le moinsage je pense) mais en fait, c'est que le contexte est different : mon php.ini est propre (enfin j'espere) donc la problematique est differentes, et c'est pour celà que je suis surpris que l'on veuille supprimer plein de truc (comme je l'ai ecrit lors de mon 1ere message).
moi, perso... la suppression de mysql, c'est putot une decission politique non ? (licence GPL)... faut-il s'en rejuire ?
mysqli aurat'il des perfs comparable ?
faudrat'il se payer le code des appli php pour changer les appels de mysql ?
on s'etonnes ensuite que les dev ne sont pas content ? (ca fait plaisir a personne de corriger du code, surtout si on est pas l'auteur).
[^] # Re: ereg ?
Posté par Éric (site web personnel) . Évalué à 2.
Les fonctions mysql_* vont peut être disparaitre. Maintenant :
- tu auras des mysqli_* qui fonctionneront quasiment pareil, il suffit de faire un rechercher/remplacer et corriger un ou deux détails (la phase connexion entre autres)
- rien ne t'empêche de compiler toi même l'extension mysql sur ta version de PHP, ou d'utiliser une bibliothèque qui reprend les fonctions mysql pour les diriger vers mysqli
Bref, c'est plus clean pour PHP mais ça ne te retire pas grand chose. De toutes façons d'ici que ce PHP6 sorte il est peu probable que tu utilises encore du mysql 3.23 donc de toutes façons les fonctions mysql_* actuelles n'auraient pas fonctionné.
> vu que sur une de mes machines j'ai un mysql 4.0.17 qui tourne et que je continue
> a utilise les fameuses fonction mysql_* je me dis que vos post en sont pas sur la
> même longueur d'onde
Oui, en fait je prend un raccourci. La cassure n'est pas sur 3.23 / 4.0 mais sur 4.0.x / 4.0.y, je ne me souviens plus exactement où.
Il y a aussi des gens qui utilisent les mysql_* avec mysql 4.1 et > mais c'est au prix d'une bidouille (une config spéciale du serveur mysql qui lui demande d'utiliser les anciens protocoles d'authentification)
> vu que le changement n'est applicable que pour le temps ou le fichier est traité,
> j'etais (je le suis encore) convaincu qu'on pouvait utiliser ini_set() pour mettre
> les register global a off, ainsi que les magic_quotes.
Non, parce que quand il lit ton fichier, il a déjà initialisé (ou pas) les globales, et a déjà opéré (ou pas) l'échappement des magic_quotes_gpc.
> moi, perso... la suppression de mysql, c'est putot une decission politique non ?
> (licence GPL)... faut-il s'en rejuire ?
C'est effectivement à l'origine une décision politique, mais pas du groupe PHP. Ca vient du groupe Mysql.
En gros l'ancien client Mysql était typé LGPL ou BSD (je ne sais plus) pour qu'une appli non compatible GPL puisse se connecter à un serveur Mysql.
Ils ont voulu restreindre un peu plus et le nouveau client à partir de mysql 4.0 (celui qui permet de se connecter à mysql 4.1) est GPL uniquement. Pour que les gens ne continuent pas à utiliser l'ancien client ils ont changé le système d'authentification (ou plus précisément le cryptage des mots de passe). On créé l'incompatibilité pour forcer la mise à jour, donc la nouvelle licence, donc le paiement de la licence proprio pour ceux chez qui ça ne convient pas.
Le premier défaut c'est qu'on se retrouve avec deux clients mysql différents. Ca explique qu'on ait maintenant deux extensions "mysql" et "mysqli". Le second défaut c'était que l'extension "mysql" était fournie par défaut avant. On ne peut pas faire la même chose avec "mysqli" parce que si PHP est du logiciel libre (assez proche de BSD), ce n'est pas du logiciel compatible GPL. (note; ce problème de licence a été réglé depuis)
Donc oui, c'est bourré de politique là dedans. Mais bon, c'est comme ça.
> mysqli aurat'il des perfs comparable ?
oui
> faudrat'il se payer le code des appli php pour changer les appels de mysql ?
Non si tu contrôles ton serveur, tu peux le bidouiller pour te connecter avec l'ancien client (utiliser l'ancien cryptage des mots de passe)
Oui sinon, mais les modifs à faire sont assez simples.
Maintenant on parle de PHP6, qui au mieux sortira en décembre 2006 (au mieux). Aujourd'hui, un an et demi après PHP 5.0, 95% des gens sont encore en PHP4.
Autant dire que rien ne t'obligera à être en PHP6 à ce moment là, donc à changer quoi que ce soit à ton code.
[^] # Re: ereg ?
Posté par fabien . Évalué à 2.
php.net est ma bible, mais rien sur les pages mysql* ne parle de mysqli
je suis donc allé voir ce nouvel mysqli que je trouve ma fois pas mal (puisque qu'on peu facilement l'utiliser en version " Style orienté objet" mais j'ai pas éllucidé l'etape supplementaire de preparation...)
il y a dejà une veritable proffusion de fonctions (on reconnais bien là le style php !!!)
On peu aimer developper sans aimer bidouiller sur le systeme. je crains un peu de sortir du standart...
on est bientot en 2006, autant dire que PHP6 c'est pour demain.
J'ai du code développé il y a déjà 5 ans qui tourne encore...
donc je vais commencer a reflechir a tout ca.
c'est domage que mysqli ne soit qu'en php5 (j'aurais bien aimé que la transition s'effectue sur 2 versions majeurs : de 5.x a 7.x mais bon...)
[^] # Re: ereg ?
Posté par Sylvain Sauvage . Évalué à 2.
C'est marrant ça, quand on dit que debian etch sortira fin 2006, personne n'y croit...
(D'ailleurs, d'aucuns pourront encore se plaindre que la dernière debian stable n'inclut pas php6...)
# c'est une bonne chose
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Alors conçernant ta liste de remove : la majeure partie des items (en particulier magicquotes, register globals, register long array etc..) sont des trucs marqués "obsolète" ou déconséillé à utiliser/activer depuis.. la sortie de PHP 4 !
Et tout programmeur serieux est au courant de ces recommandations depuis donc des lustres, et comme ils sont serieux, ils les suivent, et donc ils n'ont pas grand chose à craindre ce passage à PHP6 conçernant ces removes.
Conçernant safe_mode, ça suxor, c'est mal foutu, c'est la galère surtout quand on gère des uploads. Moi je me contente d'open_basedir (qui ne sera pas retiré) et ça fonctionne trés bien
Avoir une API unifié, voilà quelque chose qui va permettre justement une meilleure portabilité du code. Et puis bon, d'ici à ce que PHP6 sorte, tout le monde se sera mis à PDO, et quand php6 sortira, je suis sûr que l'extension mysql sera encore là parce qu'il y aura forcément trop de mécontentant.
oui, faut faire le ménage de temps en temps. PHP5 n'a pas assez fait le ménage d'aprés moi. Parce que maintenir trop longtemps des compatibilités avec ce qui précède
- ça complexifie le moteur (bonjour l'apparition de bugs potentiels)
- ça empêche une bonne évolution (garder une compatibilité sur un truc peut empêche une réarchitecture d'un autre truc qui pourtant permettrait de faire des choses encore mieux)
- ça complexifie l'API. ex : avoir deux système de regexp: ereg et preg; un débutant se demande forcément lequel choisir. L'API est suffisement longue comme ça
- c'est aussi la cause de baisse de perf. ex: plus y a de fonctions disponibles, plus le tableau d'index des symboles de fonctions dans l'interpreteur est gros, plus la recherche est longue lors du parsing (c'est une des raisons pour laquelle tous les modules ne sont pas inclus d'office); ou encore, le débutant choisira une fois sur deux cette daube de ereg plutôt que preg pourtant beaucoup plus performant.
[^] # Re: c'est une bonne chose
Posté par Anonyme . Évalué à 3.
Tout programmeur qui n'a que ça à foutre ou qui bosse sur une appli pas plus vieille que PHP4, tu veux dire.
« ça complexifie l'API. ex : avoir deux système de regexp: ereg et preg; un débutant se demande forcément lequel choisir. L'API est suffisement longue comme ça»
Tu veux dire que ça change grand chose ?
Voilà une liste de trucs du genre bien pire : http://tnx.nl/php
# Compétitif avec ASP ?
Posté par Pierre Tramonson . Évalué à -1.
S'il faut être compétitif avec quelque chose autant que ce soit avec ASP.NET.
Et là, à moins d'une révolution, je ne vois pas trop comment c'est possible en PHP.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.