Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

MIgrating to 5.0

Status
Not open for further replies.

ericbrunson

Technical User
Joined
Jan 9, 2004
Messages
2,092
Location
US

I have a production server running 4.3.4 and a test server running 5.0rc2. I've copied all my code over from the production box and tweaked it to run under 5.0. Let me tell you, I'm glad I switched to using PEAR modules where ever possible, most of the hardcore changes were already done by the PEAR maintainers.

I'm going to move to 5.0 soon after it's released. but I'm worried about upgrading my 4.3 to 5.0. My current 5.0rc2 install was on a clean system, not upgraded. I'm worried there may be problems with internal MySQL drivers or other strange intricacies.

Has anyone successfully upgraded to 5 from 4.3, and if so, could you share any gotchas you came across in the process?

TIA,
e.
 
There are a number of differences, some good, some bad.

[ul][li]First the good news:[/li][ul][li]PHP 5 integrates better with Apache 2. It doesn't give any better functionality, but there have been reported problems with using apachectl to manage Apache. If you perform a restart using apachectl, apachectl sends a HUP (hangup) signal to Apache. On some systems, that can cause Apache to sigfault and die. I had this problem on RH9 with Apache2 running PHP 4.3.6 as a module. When I installed PHP 5, the problem went away. And after all, the PHP developers still categorize PHP 4's use as a module with Apache2 as experimental.[/li][/ul]

[li]Then the bad news:[/li][ul][li]If you go with the default configuration, some existing code is going to generate warnings or errors. For example by default, the variables $HTTP_[GET|POST|SERVER|...]_VARS are not created when you run PHP 5. This behavior is affected by the "register_long_arrays" runtime configuration directive. But what's the point? The $_[GET|POST|SERVER|...] arrays have the same information as well as the benefit of being superglobal.[/li][li]If you are using the "var" operator on variables inside a class method, PHP will issue a warning -- PHP 5 wants you to be more specific through the use of the "public", "private" and "protected" operators. In general, you can replace "var" with "public" and your code will work without warnings. I don't know if there is a runtime configuration directive for this.[/li][li]In terms of compiling PHP 5 from source, there are a few things to watch out for. PHP 5 will require newer versions of some third-party libraries to compile. The "configure" script will let you know about this.[/li][/ul][/ul]





Want the best answers? Ask the best questions!

TANSTAAFL!!
 
Here's another thing:

PHP 5.0RC2 seems to be a lot pickier about value types than 4.3.6 is. The JPGraph objects run fine under PHP 4.3.6, but I'm getting some type conversion errors under 5.0RC2.



Want the best answers? Ask the best questions!

TANSTAAFL!!
 
I don't know if you're running Linux or Windows or whatnot... but under Windows it's absolutely trivial to install the two side by side... or in my case (and possibly this case), the more useful option of installing 5.0 while keeping 4.3.x installed but not running.

That way, in the worse case scenario you're back online after a changing two lines in your php.ini file and a restart of the apache server. obviouslly not the best solution, but comforting to at least a small degree.
 
If you compile PHP from source, you can do the same under Linux. You can either use the "--enable-versioning" option to the configure script or simply run one PHP version at a time while having both available on the system.




Want the best answers? Ask the best questions!

TANSTAAFL!!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top