PHP4 + WordPress 3.2 = fatal error

[dd32]

example:

Parse error: syntax error, unexpected T_VARIABLE in C:\www\wordpress-commit\wp-includes\load.php on line 564

This is caused by using PHP5 language before the php version checks have been done.

Specifically:

function wp_clone( $object ) {
	return clone $object ;
}

Changing it to:

function wp_clone( $object ) {
	return clone( $object );
}

allows PHP4 to parse the file (as it see's a function call, to a not-yet-existant function) not a unknown language construct.

This happens as load.php is included before the version checks are run. An alternate method would be to move the version checks into wp-settings.php again.

I'm not sure if/how that affects the usage of the function, but it's how it was done in WordPress 3.1

As seen on the support forums: ​http://wordpress.org/support/topic/error-message-mysql

[nacin]

Let's do clone( $object ) and include a comment there.

That said, we'll need to make sure that load.php always parses for PHP4 in the future. Might be safer to move the version checks back into wp-settings.php.

[szadok]

+1 for checking php version on wp-settings.php
A solution for time being can be something like:

function wp_clone($object) {

return version_compare(phpversion(), '5.0') < 0 ? $object : clone($object);

}

[dd32]

A solution for time being can be something like:

no version checks need to be done, as WordPress 3.2 requires PHP 5.2.4.

The point of this is that we need files loaded before the version check to conform to the PHP4 Language constructs (and clone $x is a PHP5 syntax, whereas, clone( $x ) is a PHP4 syntax)

[nacin]

We could also move the PHP check to before wp-settings. I'm thinking wp-load, even. Needs to be run anyway, why not as early as possible?

[szadok]

So the function above is the solution, I think
Replying to dd32:

A solution for time being can be something like:

no version checks need to be done, as WordPress 3.2 requires PHP 5.2.4.

The point of this is that we need files loaded before the version check to conform to the PHP4 Language constructs (and clone $x is a PHP5 syntax, whereas, clone( $x ) is a PHP4 syntax)

[dd32]

We could also move the PHP check to before wp-settings. I'm thinking wp-load, even. Needs to be run anyway, why not as early as possible?

That's a long term solution. There's no real need to have the check done after more files load. It'll require juggling of version.php include as well (since that's got the version no's).

Personally I'd just say throw the parenthesis in for 3.2, and take a look at the loading order for 3.3.

[nacin]

szadok: Well, no. We're not supporting PHP4 anymore. So the issue has nothing to do with when that function runs (the script will die out in wp_check_php_mysql_versions(), but rather when the function is parsed. clone $object won't parse in PHP4.

dd32: That's perfectly fine.

[ryan]

With comment

[ryan]

In [18339]:

Avoid PHP 4 parse error prior to version checks. Props dd32. see #17880