01141: Reported problems with 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
- Default timezone needs to be set -- Fixed for 2.2.7
- Auth/Session problems, because $_REQUEST doesn't include $_COOKIE -- Fixed for 2.2.7.
- Pagelists with negative -patterns return empty results (01149) -- Fixed for 2.2.7
- The crypt() function may hang on Windows with the UniServer but reportedly the current latest PHP 5.3.1 version works fine.
- On Windows, passwords shorter than 4 characters are not correctly recognized. Not fixed, please use longer passwords.
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
/etc/php.iniconfiguration file. If you currently don't have a
/etc/php.inifile, then copy
/etc/php.iniand then edit
cd /etc sudo cp php.ini.default php.ini sudo vi php.ini
date.timezone = "America/New_York"
See http://php.net/manual/en/timezones.php for a list of valid timezones. Scott Connard September 18, 2009, at 09:21 AM
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
- download the WAMP server UniServer_Mona_5_1 from http://www.uniserver.com
- unzip it to C:\UniServer
- unzip phwiki-2.2.5.zip into the document root C:\UniServer\www
- add localhost:80 to C:\windows\system32\drivers\etc\hosts
- run C:\UniServer\alternative_control\Start_Server.bat
- browse http://localhost/pmwiki-2.2.5/pmwiki.php?n=Main.HomePage
- reload the page a few times or edit+cancel the page -- eventually it will hang.
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
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.
Pagelists with -patterns produce empty results, e.g. (:pagelist group=-PmWiki:) Rogut279s? October 03, 2009, at 07:09 AM
- Confirmed, ToDo. --Petko October 03, 2009, at 07:31 AM
- Done, from PITS:01149. --Petko October 24, 2009, at 09:11 PM
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
$_REQUESTvariable no longer includes the contents of
$_COOKIEwith the default
php.ini(see PHP 5.3 note at http://php.net/manual/en/reserved.variables.request.php). This is the reason why a conditional fails in
SessionAuth()and why logging in isn't "remembered". This is the conditional that fails:
if (!$auth && ($called > 1 || !@$_REQUEST[session_name()])) return;. A possible fix would be to replace
$_COOKIE(probably loosing compatibility with non-cookie sessions), or to add an additional statement for
$_COOKIE[session_name()]. -- Rogutės, 2009-10-28
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.