This is a reminder that SAA will update UVM's central webfarm, hosting
www.uvm.edu and other sites, to PHP 5.3.1 at 7am tomorrow, February 9th,
2010.

Please voice your questions or concerns, or email [log in to unmask]

Regards,
Ben

On 1/26/10 3:46 PM, Benjamin Coddington wrote:
> SAA will update UVM's central webfarm, hosting www.uvm.edu and other
> sites, to PHP 5.3.1 at 7am, Tuesday February 9th, 2010.
>
> If you manage a website on www.uvm.edu, we encourage you to test it on
> the new version of PHP at your earliest convenience. This is especially
> important if you are using more than basic magicscript functionality, or
> have installed your own PHP applications.
>
> As with previous updates, there are two methods for testing your website.
>
> To use the first method, replace http://www.uvm.edu with
> http://php53test.uvm.edu when going to your website. While testing, you
> need to check that the URL address at the top of your browser continues
> to read http://php53test.uvm.edu/. If your site redirects you back to
> http://www.uvm.edu/, be aware that you are changing back to the
> production PHP 5.2.11 server, and you will need to re-edit the server
> name in your address bar to continue testing the PHP 5.3.1 instance.
>
> The second method addresses this redirection hassle. There is an
> application at http://www.uvm.edu/ets/gotoarch/ that will set a cookie
> in your browser to allow you to view sites under http://www.uvm.edu/ in
> PHP 5.3.1. If you set the suffix to "/", then all requests to
> http://www.uvm.edu/ will be served by PHP 5.3.1. Or you can set a more
> specific suffix to just redirect part of http://www.uvm.edu/. You can
> dump these cookies by restarting your browser or removing them in the
> application.
>
> PHP 5.3.1 is a minor conversion, but we still expect that some things
> will not work properly. A list of backward-incompatible changes can be
> found here:
>
> http://www.php.net/manual/en/migration53.incompatible.php
>
> In addition, there are a number of deprecated functions that may produce
> warnings; most notably of which are ereg() and ereg_replace(), which
> should be replaced with preg_match() and preg_replace() respectively.
> One other common deprecated usage is that you should no longer assign
> the return value of "new" by reference. For example:
>
> $myInstance = &new ClassObject();
>
> should instead be
>
> $myInstance = new ClassObject();
>
> A full list of deprecated functions may be found here:
>
> http://www.php.net/manual/en/migration53.deprecated.php
>
> Thanks,
> Ben
>