Is WordPress compatible with PHP 5?

WP v1.2.x is not entirely compatible with PHP v5. The upcoming WP v1.5 (currently in non-public beta) is.

Would the incompatibilities cause a MySQL server to crash during install? I get through most of step 2, but when it’s inserting the geo elements into wp_options, I lose my connection and the server crashes.

I’ve just installed PHP 5.0.3 and MySQL 4.1.9 on an XP box running Apache 2. I know there’s all sorts of problems with that set-up, but I’m just trying to get something working at home so I can test changes to the blog without an internet connection. I can’t get WP installed locally with this set-up, though. Is it just PHP 5 problems, or is it something more serious?

Any help would be much appreciated. Thanks!
–Michael

More specifically – the problem is with the following query (line 663 in wp_install.php of the current stable release):

"INSERT INTO $tableoptions (option_id, option_name, option_type, option_value, option_description, option_admin_level, option_width) VALUES(86,'default_geourl_lat ', 8, 0.0, 'The default Latitude ICBM value - <a href=\"https://www.geourl.org/resources.html\" target=\"_blank\">see here</a>', 8, 20)",

I’ve run this query in the command line MySQL client, through phpMyAdmin, and in the WP install. It always crashes my MySQL server. I don’t see anything wrong with it, but I’m new to all this fancy coding stuff. Help?

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 isna€?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 ita€?s working OKAY, but recently I installed the SQLiteManager application which requires httpd-www authentication functionality, and since the CGI mode doesna€?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 wasna€?t able to install on my server. The installation failed during Step 3, causing the Apache Server to produce a a€?fatal errora€? 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 didna€?t function correctly a€“ 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 doesna€?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 wasna€?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: https://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:

a€? 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.a€?

It looks to me as if the php5apache2.dll cana€?t handle the db class of the ez_sql.php, which could lead to the conclusion that this class isna€?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 a€?fatal errora€? messagebox (there are probably more actions in phpMyAdmin which will trigger this error): 1. When I used the a€?Browsea€? function. 2. When I tried to execute a SQL Query like: DESC name_of_a_column;

The problem ISNa€?T directly related to the a€?DESCa€? 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 ISNa€?T directly related to the a€?DESCa€? query, is because it works OK when I test it in another small test program: https://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.

Best regards,
listen

I have the same problem described above with browse in phpmyadmin,…and I am using IIS5