PHPfrance

la communauté d'entraide francophone dédiée au PHP

compatibilité ascendante

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : compatibilité ascendante

par Sékiltoyai » 24 juil. 2007, 20:45

La phrase était bien tournée…

Sékiltoyai a, je pense, besoin d'arrêter le café, ou de mieux dormir je sais pas :lol:
Je ne bois pas de café, donc à mon avis, c'est la seconde option :mrgreen:

par naholyr » 24 juil. 2007, 12:08

La phrase était bien tournée…

Sékiltoyai a, je pense, besoin d'arrêter le café, ou de mieux dormir je sais pas :lol:

par Jules Petibidon » 24 juil. 2007, 09:10

Hello,

Ma phrase était mal tournée peut-être. Je voulais dire que si pas d'objet, pas de souci tout simplement ;) Dans le cas contraire, il y a un risque.

par Sékiltoyai » 23 juil. 2007, 23:51

les seules différences piégeuses entre php4 et php5 sont au niveau du comportement des objets. A priori si les scripts php4 ne contiennent pas d'objets, il n'y a pas de raisons qu'il y ait le moindre problème.
Je connais des applications PHP4 qui utilisent des objets. Ce n'est pas parce que beaucoup n'avaient pas le réflexe objet, que personne ne l'avait.

par Jules Petibidon » 23 juil. 2007, 18:02

hello,

les seules différences piégeuses entre php4 et php5 sont au niveau du comportement des objets. A priori si les scripts php4 ne contiennent pas d'objets, il n'y a pas de raisons qu'il y ait le moindre problème.

quant aux options de configuration, elles sont classiques... si le code est propre, register_globals ne doit poser aucun problème. Seuls peut-être les short open tags pourraient causer un soucis avec les prologues XML je crois, même pas sur... :)

par zigz4g » 23 juil. 2007, 17:31

Je dirais que le portage des scripts en PHP4.3 vers 5 ne sont pas un gros probleme.
Si ca en passe pas, un changement du php.ini pourrait faire l'affaire.
On n'est pas encore passer a php6 :)

Pour MySQL, si les tables sont les meme ca devrait passer aussi.

Le petit hic dans cette nouvelle configuration sera peut etre le passage de l'ancien encodage vers l'UTF-8. Si toutes les donnees sont en iso-latin-1 ca risque d'etre long a convertir (sauf avec des scripts shell).

par Sékiltoyai » 20 juil. 2007, 15:15

Pour préciser, la config particulièrement permissive (pour ne pas dire perméable) de ce serveur
(tous les paramètres sont à On :evil: Beurk !) m'a laissé supposer,
sur le principe du "Qui peut le plus, peut le moins" que la compatibilité serait assurée.

Mais bon, ce n'est sans doute pas suffisant... :oops:
Attention, c'est piégeur ça !
Ce n'est pas parce que les directives sont à On qu'elles sont plus permissives, c'est php qui a un comportement différent.
Par exemple, pour register_globals, si tu le mets à On aklors quele site a été codé pour register_globals à Off, il pourra y avoir des problèmes comme des variables définies alors qu'elles ne devraient pas l'être.
Pour magic_quotes_gpc, ce sont les échappement qui disparaîtront...

Il ne faut pas essayer d'être plus permissif mais esssayer de faire en sorte que les configurations soient le plus proche possible. Et si tu n'as pas utilisé $tableau[public] pour accéder à l'élément de ton tableau, il n'y a pas de raisons que cela buggue.

par albat » 20 juil. 2007, 10:35

Pour préciser, la config particulièrement permissive (pour ne pas dire perméable) de ce serveur
(tous les paramètres sont à On :evil: Beurk !) m'a laissé supposer,
sur le principe du "Qui peut le plus, peut le moins" que la compatibilité serait assurée.

Mais bon, ce n'est sans doute pas suffisant... :oops:

par zeus » 20 juil. 2007, 10:27

N'étant pas un dieu en configuration serveur, ma réponse est à prendre avec des pincettes ...

A mon avis, je pense que la compatibilité de MySQL et d'Apache ne devraient pas poser de problèmes.

En ce qui concerne PHP, pour être totalement sûr, il faudrait comparer les configurations (php.ini, ...) mais il est possible que les méthodes de développements aient été suffisement rigoureuse pour qu'il n'y ai pas besoin de porter certaines configurations (je pense au register_global, par exemple)

compatibilité ascendante

par albat » 17 juil. 2007, 18:18

bonjour,

Je dispose du serveur suivant :
  • APACHE 2

    Code : Tout sélectionner

    LoadModule php5_module modules/libphp5.so AddType application/x-httpd-php .php AddDefaultCharset utf-8 LoadModule rewrite_module modules/mod_rewrite.so RewriteEngine On RewriteRule ^\/([0-9]+)i(.*)\.html(.*) /index.php?coe_i_id=$1$3 [L]
  • PHP 5.*

    Code : Tout sélectionner

    ‘./configure’ … ‘--enable-mbstring’ … ‘./configure’ … ‘--enable-soap’ … ‘--with-xsl[=DIR]’ … register_globals = on register_long_arrays = on allow_url_fopen = on magic_quote_gpc = on short_open_tags = on mbstring.language = Neutral mbstring.internal_encoding = UTF-8 mbstring.http_input = UTF-8 mbstring.http_output = UTF-8 mbstring.encoding_translation = On mbstring.detect_order = auto mbstring.substitute_character = none; mbstring.func_overload = 7
  • MySQL 5.0.22

    Code : Tout sélectionner

    ‘./configure’ … ‘--with-charset=utf8’ …
Le bon fonctionnement d'applicatifs développés en PHP 4.3 et MySQL 3.23.58 est-il garanti ?