is PHP savely backwards compatable?

Hi,
currently I am learning PHP.
I am just wondering about the policy of next(future) verions of PHP, if they will be backwards compatable.

The reason: I would hate if I had to rewrite a website because I didnt consider it.

I am doing PHP now is because Microsoft launched ASP.net which is different in alsmost everything to ASP3.0, so I figured changing, since I dont want to learn the same language twice

Patrick

To a certain extent, yes. If you checkout PHP's changelog you'll see what changes between versions. But some things changes and will eventually be removed from a new version of PHP, so you can never be sure...

//NoXcuz

So a site made in PHP3 would not run properly on PHP4?
Well.. I hope than they not gonna change version number every year

Patrick

One nice thing about open-source/free software scripting languages like perl, PHP, or python is that they don't have an incentive to increase version numbers by releasing too early- For instance, PHP4 is VERY improved over PHP3, just as perl 5.6.x has a lot more to it than perl 4 or even perl 5.x.

Basically, there is an attitude of "we'll release when we're damn well ready," but that usually means the releases are very meaningful. You can't really say that about a lot of commercial software.

If some behavior breaks in an upgrade from PHP3 to PHP4, there was probably a very good reason for it- the old behavior was a failed experiment, insecure, or some other reason. I think you can assume that code written for PHP4 will upgrade pretty simply to the new versions of PHP. Anyone have significant problems moving PHP3 code to PHP4 ? I haven't heard any horror stories. . .

no horror stories. only some tweaking here and there. and i agree, all this has been changed for good reasons, so you should definitively get used to the newer versions.

some problems arise from different default configuration, like the register_globals. again, this is for a good reason

I was VERY happy to hear about the changed register_globals behavior- I always "registered" by variables before anyway, so it didn't effect me.

I just don't like anyone being able to stuff variables into my scripts by appending extra query strings. . . Call me crazy.

But with the global, e.g. used like register_session. Those settings are settled in the php.ini file. If a provider suddenly changes those settings your site wouldnt work, or can different sites be adjusted seperately?

afaik some php settings can also be overridden in .htaccess
but i can´t tell which ones and of couse you need permission to use .htaccess

adding this to a script with regards to globals to pages:

<?php ini_set("register_globals", "0"); ?>

Can that overrule anyting else?
You see I am making a nice website currently (on a local machine), but would hate to redign it a soon when I find a provider that doenst support $_SESSION....

use:

global $HTTP_SESSION_VARS

instead. afaik it is available since php supports sessions (4.0). then you are on the safe side.

i doubt this line of code overrides the setting, since it is already active when the parser reaches this line...

$_SESSION will be supported whether register_globals is on or off (and PHP version is 4.1 or greater). So you won't have to rewrite your code if your host turns register_globals on. Since those arrays are a fairly recent addition it's unlikely they'll be going anywhere soon either.

Mac

No, that won't work. register_globals is not (and cannot) be affected by ini_set().

quote:
-------------------------------------------------------------
$_SESSION will be supported whether register_globals is on or off (and PHP version is 4.1 or greater).
-------------------------------------------------------------
http://www.zend.com/manual/ref.session.php

saying
"...As of PHP 4.0.3, track_vars is always turned on...."

furthon saying
"....If track_vars is enabled and register_globals is disabled, only members of the global associative array $HTTP_SESSION_VARS can be registered as session variables. The restored session variables will only be available in the array $HTTP_SESSION_VARS..."

Oh well, I guess that doenst count than or $_SESSION...