Migrating phpWebsite 0.10.2 to PHP version 5

After changing my web hosting provider, I am faced with the task of migrating a couple of web sites to the new server. A couple of these web sites are phpWebsite-based. Unfortunately, the new server is using a version of PHP higher than 5, which is known to cause some problems with the version of phpWebsite (v 0.10.2) I am currently using. Left with no choice, I searched Google for available solutions. Luckily, the search results did come up with some possible solutions, although I could not find an official migration guide. So in this post, I will describe the problems I’ve encountered in migrating my phpWebsite 0.10.2 installation to a server running a PHP version higher than 5.

The first thing I did was to transfer all files and databases to the new server. After uploading everything, I also changed the configuration file (conf/config.php) to reflect the new server setup. This included changing the database and source directory settings. Then, the debugging part.

The first time I accessed the site, I encountered a fatal error from the article manager module, one of the installed third party modules. The error  was something like

<pre>Fatal error: Cannot re-assign $this in /home/user/public_html/mod/article/class/Article.php on line 723</pre>

The offending code came from the following:

function fatCatview ($id) {
    $this = new PHPWS_Article($id);
    return $this->view(false, true);
}

Reassigning $this is no longer allowed in PHP 5 and above, thus line 3 in the code gave a fatal error. To resolve this problem as suggested in some websites, you can replace $this with some other variable name such as $article, which was what I did. The function should now read as:

function fatCatview ($id) {
    $article = new PHPWS_Article($id);
    return $article->view(false, true);
}

After this, I could already view the site content. But accessing the control panel gave the following warnings:

Warning: Unknown class passed as parameter in /home/user/public_html/core/Error.php on line 125
Warning: Unknown class passed as parameter in /home/user/public_html/core/Error.php on line 125

Checking Error.php, I found out that the warning was generated by a call to the is_subclass_of function. So I removed it from the code changing the line to

return (is_object($value) && (strcasecmp(get_class($value), 'PHPWS_Error') == 0));

from

return (is_object($value) && (strcasecmp(get_class($value), 'PHPWS_Error') == 0)
  || is_subclass_of($value, 'PHPWS_Error'));

The next problem to solve was the calendar module. I read somewhere that the calendar module had to be completely replaced. Fortunately, I found a link to an updated version from Phpwebsite Support Forums. The link (http://blackfoot.appstate.edu/legacysvn) points to the SVN files for the 0.x version of phpWebsite. I downloaded all the files for the calendar module and replaced my existing installation. Except for the one glitch, the newer version seemed to be working.

The remaining problem I encountered was that in the month view (including minimonth), the last entry of the month was always missing in the display. I suspected that the loop generating the display caused the problem. It seems like the loop terminated just before the last entry. I checked the code and discovered the culprit, which is related to my time zone setting initially set to JST. However, one of the called functions (PHPWS_Calendar::loadEvents($calStart, $calEnd)) just before the loop converted the time zone of the entered parameters to UTC.

Here is the value of the Date variable ($calEnd) before the function call:

$calEnd:

Date Object ( [year] => 2008 [month] => 04 [day] => 27 [hour] => 09 [minute] => 52 [second] => 34 [partsecond] => 0
 [tz] => Date_TimeZone Object ( [id] => Asia/Tokyo [longname] => Japan Standard Time [shortname] => JST
 [hasdst] => [dstlongname] => Japan Standard Time [dstshortname] => JST [offset] => 32400000 [default] => ))

After calling  PHPWS_Calendar::loadEvents($calStart, $calEnd);, the value of the variable $calEnd is now:

$calEnd:

Date Object ( [year] => 2008 [month] => 4 [day] => 27 [hour] => 0 [minute] => 52 [second] => 34 [partsecond] => 0
 [tz] => Date_TimeZone Object ( [id] => UTC [longname] => Coordinated Universal Time [shortname] => UTC
 [hasdst] => [dstlongname] => Coordinated Universal Time [dstshortname] => UTC [offset] => 0 [default] => ) )

Somewhere within the function, the change occurred. I don’t know where specifically. Since UTC is 9 hours behind JST, the loop terminates before displaying the last entry. To avoid this problem, I just defined another variables copying the content of $calStart and $calEnd and used these instead as the input parameters to loadEvents:

:
$evStart = new Date($calStart);
$evEnd = new Date($calEnd);
$eventList = PHPWS_Calendar::loadEvents($evStart,$evEnd);
:

And that’s it. Now, my phpWebsite 0.10.2 is working fine under PHP version 5.

NOTE: For those who want to have a copy of the modified calendar version, you can download a copy from here.

UPDATE (20 may 2008):

When saving an edited article, I encountered this error:

Fatal error: Unknown edit type in /home/user/public_html/mod/article/lib/pear/Text/Diff/Renderer.php on line 118

This problem is related to the get_class() function, which in php4 was not case sensitive. To solve this, I edited Renderer.php changing text_diff_op_* in lines 101, 105, 109, and 113 to Text_Diff_Op_*.

A similar problem was reported in phpwsforums.com. See this thread: http://phpwsforums.com/showthread.php?t=4482. And it is suggested to replace the version of Text_Diff with the newer one, which can be downloaded from this link: http://pear.php.net/package/Text_Diff.

UPDATE: 5 June 2009

The bulletin board is not displaying properly the last post column for list operations. What I did to resolve this is to update the Forum.php file in mod/phpwsbb/class directory. You need to change the function name getLastPost() to getlastpost() around line 500. You also need to do this in Thread.php file in mod/phpwsbb/class directory. The reason may be is that php 5 is now case sensitive so the two functions are now different. But I am not sure.