Tweak wp-db.php so running WordPress on HHVM doesn't require hacking the core

[dave1010]

Running WordPress on HHVM currently requires manually editing wp-db.php as HHVM doesn't support case-insensitive constants. Adding a check for HHVM in wp-db.php would allow it to run without any hacks to the core and not break BC.

This would be as simple as:

if (! defined( 'HHVM_VERSION' )) {
    define( 'OBJECT', 'OBJECT', true );
} else {
    define('OBJECT', 'OBJECT');
    define('Object', 'OBJECT');
    define('object', 'OBJECT');
}

See the [HHVM blog post](​http://www.hhvm.com/blog/113/getting-wordpress-running-on-hhvm) for more background on this.

Note: there's a small chance that plugin / theme authors are checking for something like oBjEcT, instead of object, OBJECT or Object, so removing case-insensitivity by default would be a (tiny) BC break.

[pento]

I did a quick search through the plugin repo, I could only find instances of OBJECT or object, though I may've missed some.

Is there any reason why HHVM can't fix their implementation of define()?

[nacin]

I spoke about this with Sara Golemon of Facebook (the author of this post) at a conference last year. We were talking HHVM + WordPress and she mentioned this was the only remaining incompatibility. From what I recall it simply issued a notice of sorts in HHVM, versus preventing compilation. She was concerned WordPress required it, while after inspection it was clear this is now just for back compat. So, someone running HHVM + WordPress could simply ignore this issue.

While it wouldn't be difficult for HHVM to support case-insensitive constants (​https://github.com/facebook/hhvm/issues/129), it doesn't look like HHVM will do so. I don't exactly blame them; it's a pretty terrible concept.

Anyway, when looking into this with Sara I had no idea we had this little artifact in WordPress. It dates to ezSQL (and still exists ​upstream) and somehow managed to be dropped from ARRAY_N and ARRAY_A in [1180]. It stayed for OBJECT for whatever reason.

I think we have a few options here:

1. Define object as OBJECT and do nothing else.
2. Define object and Object as OBJECT and do nothing else.
3. Add support in get_results() and get_row() for OBJECT in a case-insensitive fashion, and also define object as OBJECT, thus making it so only Object or ObJeCt actually catches the fallback.
4. Add support in get_results() and get_row() for OBJECT in a case-insensitive fashion and do nothing else.

I could only find three non-OBJECT uses in the plugins directory, all of them being object:

plugins/author-profiles/author_widget.php:107:$comment_counts = (array) $wpdb->get_results("{$get_results}", object);
plugins/cbpress/lib/class.cats.php:280:		$result = $wpdb->get_row($query,object);
plugins/lemonnews/classes/class-lemon-news-model.php:102:		return $wpdb->get_row( $sql, object );

object seems like it's not a big deal to support, but it's inconsistent with ARRAY_A, ARRAY_N, and OBJECT_K. And, OBJECT is the default in all cases it is used, so it's not like we benefit from more ways to specify it.

I wouldn't mind removing this artifact. The attached patch, 27231.diff​, implements point 3, though removing the define( 'object', 'OBJECT' ) also takes care of point 4.

[nacin]

pento pointed out to me that we also accept these constants as arguments for functions like get_post() and such. So, defining object as OBJECT would still be prudent. I am not interested in Object. The fallback code in wp-db.php is sufficient to catch weird stuff for DB queries, along with letting PHP issue a notice.

[nacin]

In 27377:

Make OBJECT a case sensitive constant, for HHVM compatibility and general sanity.

Support object explicitly, and other forms using a fallback in wpdb.

fixes #27231.