It looks to me as if the php5apache2.dll module has a serious bug, for which reason I reported it to the PHP bug-list.
However, the people at the PHP bug-list instantly classified my bug-report as BOGUS, and claimed that the php5apache2.dll isnâ€™t bug ridden at all. And since I had encountered this problem with both the WordPress application and the phpMyAdmin application, and since a database (MySQL) was involved, the people at the PHP bug list suggested that both the WordPress application and the phpMyAdmin application and the database (MySQL) was at fault.
However, for some time now I have used PHP 5 in CGI-mode, where itâ€™s working OKAY, but recently I installed the SQLiteManager application which requires httpd-www authentication functionality, and since the CGI mode doesnâ€™t support httpd-www authentication I had to change over to run the PHP as an Apache module (using php5apache2.dll instead of php-cgi.exe).
At first it looked to me as if it was working okay when PHP was run as an Apache module, but when I grabbed a copy of the WordPress application and tried to install it to my server, the WordPress application wasnâ€™t able to install on my server. The installation failed during Step 3, causing the Apache Server to produce a â€˜fatal errorâ€™ messagebox. And as it turned out this errorcondition was triggered by a get_col() function of the db class (ez_sql) included in the application.
However, when I changed back to run the PHP in CGI mode the installation of WordPress was successfully completed.
While the PHP still was running as an Apache module I also tried to use the phpMyAdmin application, where it appeared that the Browse function didnâ€™t function correctly â€“ it only printed the uppermost screen line before triggering the fatal error in the Apache server.
It looks to me as if the bug-ridden part is php5apache2.dll or the Apache server, because the error condition doesnâ€™t exist when the PHP is handled by the php-cgi.exe.
After a discussion the PHP Bug-team asked me to produce a small php-script which they could use to reproduce the error condition, and to place this script at the internet. They also demanded that this script wasnâ€™t allowed to include a database. But since the errorcondition actually happens when communicating with a database, I considered this requirement a joke.
Since the ez_sql.php class (included in WordPress) did trigger the error condition I decided to include the class (ez_sql.php) in my tiny test script, which I placed here: http://hoppalong.1go.dk/bug/demo.php
At this point the PHP bug team again closed the BUG because the test script involved too much code, and because it also involved a database, which apparently made it far too complicated for the PHP BUG team to work with
I then realized, that the PHP bug team simply was pulling my leg - they probably are aware that the php5apache2.dll is bug ridden, but apparently they had no intention to fix the bug.
In the PHP 5.0.3 Source I found this note about php5apache2.dll:
â€œ Currently the issues with the module are:
* Thread safety of external PHP modules
* The lack of re-entrancy of PHP. due to this I have disabled the 'virtual'
function, and tried to stop any method where a php script can run another php
script while it is being run.â€?
It looks to me as if the php5apache2.dll canâ€™t handle the db class of the ez_sql.php, which could lead to the conclusion that this class isnâ€™t compatible with PHP 5, but then again, this class works correctly when handled by php-cgi.exe
In the phpMyAdmin I have encountered two different actions which causes the Apache2 server to produce a â€˜fatal errorâ€™ messagebox (there are probably more actions in phpMyAdmin which will trigger this error): 1. When I used the â€œBrowseâ€? function. 2. When I tried to execute a SQL Query like: DESC name_of_a_column;
The problem ISNâ€™T directly related to the â€œDESCâ€? query. In regard to phpMyAdmin the problem has something to do with the way the phpMyAdmin handles it.
The reason I can say that the problem ISNâ€™T directly related to the â€œDESCâ€? query, is because it works OK when I test it in another small test program: http://hoppalong.1go.dk/bug/demo2.php
In regard to ez_sql.php and the WordPress application the problem has something to do with how the php5apache2.dll (or the Apache2 server) is handling the ez_sql db class.