Have you upgraded to php 5.3x yet?

Have you upgraded to PHP 5.3x yet?

  • Yes

    Votes: 17 53.1%
  • No

    Votes: 15 46.9%

  • Total voters
    32

ditto

Verified User
Joined
Apr 27, 2009
Messages
2,348
Now that PHP 5.2x is no longer supported, have you upgraded a production server to PHP 5.3x yet? If so, did you experience any problems with existing applications, like WordPress, Joomla, Drupal etc?
 
No, for some commercial applications we still use PHP4, because it does not support 5.x. The same is with 5.3x. Perhaps, we will use it with new installations or as an option at least one year or so.

It's not a trivial question for us.
 
We are running 4 versions of PHP on our Production Hosting Servers.

1. PHP 4.4.9
2. PHP 5.2.17
3. PHP 5.3.5
4. PHP 6 (on request)

I am running all them on one server with CLI and CGI. Each user can choose.
 
Not sure. This is only available under our customized DirectAdmin running on Gentoo. When I will find some Free time I will finish the Gentoo Overlay for DirectAdmin. You will be able to do a emerge directadmin and everything will be running and always up2date.
 
I find limiting the version per user too restrictive (same for antispam, mailboxes, etc.). Power users need different settings per domain.
Hopefully, we'll get custom variables for domains shortly and you'll be able to implement a PHP chooser per domain by using the proper path in the vhost.
 
There's already a ready plug-in on these forums, it allows users to select PHP-CGI version on per domain basis.
 
I've upgraded to 5.3 last week and didn't have any problems but then again I'm only running my websites without any 3rd party software like drupal, Wordpress or Joomla. :)
 
Nope.

Upgrading to 5.3 caused a bunch of issues with drupal 6's calendar module. Though there was a patch, I dont see the plus side in devoting a bunch of work into patching multiple sites on the system. I did read up on the new stuff in 5.3 and not much of it was "vital" or "mission critical", much less needed to me at all.

I'm very happy how easy it was to downgrade directadmin back to 5.2, kudos!
 
It's not vital until the next security advisory gets released.
PHP 5.2 will probably not be patched and you will be left unprotected unless you upgrade to 5.3.
I think it's best to start planning the upgrades to 5.3/drupal 7 now.
 
Upgrading to 5.3 caused a bunch of issues with drupal 6's calendar module. Though there was a patch, ...

I have a customer who is using Embedded Gallery 2 wich on my php 5.3.6 server is getting this error: "Embedded Gallery2 is not available."

Is that the same problem your customers was facing? If so, do you have the link to the patch?
 
I figured I'd upgrade to 5.3 as well, but having the deprecated functions in mind, I searched google if there was a script detecting these functions.
I've found it, you can get it here:

http://www.typofree.org/article/arc...e-for-deprecated-ini-directives-and-functions

I'll post it here for future reference in case it gets removed:

Code:
#!/bin/bash
#
# PHP 5.3 Deprecated function checker
#
# Version: 0.0.3
#
# Author: Michiel Roos <[email protected]>
#
# http://www.php.net/manual/en/migration53.deprecated.php
#
# Please note that there will be some false positives. Some PHP code is mixed
# with JS code. In JS 'split' is still a valid function.
#
 
deprecatedFunctions=(
    call_user_method
    call_user_method_array
    define_syslog_variables
    dl
    ereg
    ereg_replace
    eregi
    eregi_replace
    set_magic_quotes_runtime
    session_register
    session_unregister
    session_is_registered
    set_socket_blocking
    split
    spliti
    sql_regcase
    mysql_db_query
    mysql_escape_string
)
 
deprecatedIniDirectives=(
    define_syslog_variables
    register_globals
    register_long_arrays
    safe_mode
    magic_quotes_gpc
    magic_quotes_runtime
    magic_quotes_sybase
)
 
len=${#deprecatedFunctions[*]}
i=0
 
echo "Checking for deprectated functions ______________________________________"
echo ""
 
while [ $i -lt $len ]; do
    echo "  // checking for '${deprecatedFunctions[$i]}()'"
    grep -rn --color --include=*.php "^[^#]*[^a-zA-Z_]${deprecatedFunctions[$i]}[[:space:]]*(" *;
    echo ""
    let i++
done
 
len=${#deprecatedIniDirectives[*]}
i=0
 
echo "Checking for deprectated ini directives _________________________________"
echo ""
 
while [ $i -lt $len ]; do
    echo "  // checking for '${deprecatedIniDirectives[$i]}()'"
    grep -rn --color --include=*.php "ini_set[[:space:]]*(['|\"]${deprecatedIniDirectives[$i]}" *;
    echo ""
    let i++
done

If you put it in a file in /home/ (or place it in /home/user for only one user) chmod it and run it you can see where the functions are used which are not going to work anymore with php 5.3

I've ran this script and I found 4808 lines that contain a deprecated function.. Mostly Wordpress installations by the looks of it. I could run both 5.2 and 5.3, but thats not ideal. I guess I'll inform the clients and upgrade later anyway.
 
I've upgraded to PHP 5.3 because it has a nifty little feature that 5.2 doesn't have and that it's useful in the following situation :

Let's say we put the following in the main php.ini when a user adds a domain to his account :

[PATH=/home/user/domains/domain.tld/]
open_basedir = /home/user/domains/domain.tld/:/tmp

Which is in fact critical when used with suPHP, I had a few clients hacked because they gave a subdomain to untrustable people and they hacked into the main website with a shell script.

It's the only way to use open basedir for domains with suphp without too many headaches.
(I stole this trick from the cpanel forums :cool:)
 
Last edited:
Back
Top