Summary: Reported problems with PHP 5.3.x
Created: 2009-09-18 08:19
Status: Closed - fixed for 2.2.7
Category: Bug, PHP Compatibility
OS: PHP 5.3.x
I am closing this entry as problems on this page have been fixed. If there are more PHP compatibility issues, please create a new PITS entry, or if you prefer, contact me directly by e-mail. --Petko December 02, 2009, at 03:09 PM
Users reported problems with PmWiki with and without recipes, on PHP 5.3 installations. Server hangs, pages not saved... Additional information could be useful. --Petko September 18, 2009, at 08:20 AM
During a trial of PHP 5.3, my PmWiki which was fine with PHP 5.2.5 displayed numerous warnings, including "depreciated function" warnings and date/time setting warnings. The date/time setting warnings were connected to the totalcounter recipe and vanished after this was disabled. Unfortunately, I was not able to correlate server settings (which also influenced the results) and PmWiki reation with greater detail. (If someone is successfully using PHP 5.3 with PmWiki, it would be nice to read about this too :-) --Henning September 18, 2009, at 08:57 AM
I hit this problem on a Macintosh upgrade to Snow Leopard. The fix was to set a timezone in the
cd /etc sudo cp php.ini.default php.ini sudo vi php.ini
Find the date.timezone comment line, uncomment it and add your appropriate timezone.
Thanks, I checked my php.ini and found the date.timezone parameter commented out (though the commented line showed the appropriate time zone :-) I went back to PHP 5.2.5 anyhow, so I can't report on the success regarding PHP 5.3.0. --Henning September 21, 2009, at 05:48 AM
Apache + php 5.3 + a pristine pmwiki-2.2.5 hang following these steps: SteP September 18, 2009, at 12:04 PM
Hi. I've done some testing on Windows, and it appears that, except the fixable default timezone as noted above, there is a problem with the PHP 5.3 crypt function which seems to hang indefinitely when called with a "salt" parameter.
$password = crypt('Some_pass'); # works $password = crypt('Some_pass', '*'); # hangs
This is quite a problem, because PmWiki will be unable to check any passwords, and won't work even when there are no passwords defined.
I'll need some time to figure out how to deal with this -- currently I don't see anything that could possibly be done on our side. Your comments and suggestions will be welcome.
(There could be more issues that we'll uncover later, as I am blocked at this point now.) --Petko September 19, 2009, at 02:25 PM
Update: I compiled PHP 5.3.0 on GNU/Linux and the crypt() function works fine -- this could be a Windows-only PHP bug. Feedback from other installations will be welcome. --Petko September 19, 2009, at 04:14 PM
Both of the above crypt() lines work fine on a Mac Snow Leopard wiki using PHP 5.3.0. Scott Connard September 19, 2009, at 07:43 PM
I use PHP 5.3.1 on a Windows machine and even a freshly installed pmwiki will hang, the page just won't load - ever. No error in the error logs, the page simply won't load. I don't use a salt in the crypt function and it still doesn't load.
Authentication has problems with session starting (using both, AuthUser and password authentication), as already reported by some people in the mailing list. To reproduce: @lock a page for reading, navigate to it, login as admin, try action=?edit - it will ask for password again. The problem: $_SESSION variable is always empty (except when submiting the login form). Rogut279s? October 03, 2009, at 07:09 AM
I too have the $SESSION variable. Users can log in, but any actions require logging in again. It is possible to edit the sites, but it requires logging in at every action. File uploads are no longer possible as the file name always comes up empty.