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 ?

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)

Pour préciser, la config particulièrement permissive (pour ne pas dire perméable) de ce serveur
(tous les paramètres sont à On 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...

Pour préciser, la config particulièrement permissive (pour ne pas dire perméable) de ce serveur
(tous les paramètres sont à On 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...

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.

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).

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...

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.

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.

La phrase était bien tournée…

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

La phrase était bien tournée…

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

Je ne bois pas de café, donc à mon avis, c'est la seconde option