PITS /

01141: Reported problems with PHP 5.3.x

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

From: Petko

Assigned:

Priority: 54

Version: all

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

Refactored summary:

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.
more?

Description:

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 /etc/php.ini configuration file. If you currently don't have a /etc/php.ini file, then copy /etc/php.ini.default to /etc/php.ini and then edit /etc/php.ini:

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.

;date.timezone =

changes to

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

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.

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

The $_REQUEST variable no longer includes the contents of $_COOKIE with 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 $_REQUEST with $_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.