Support Facebook's HipHop

[ChenHui]

Various changes to make WordPress compatible with HipHop, Facebook's
PHP-to-C++ transformer. With this patch, WordPress' codebase can be
tranformed to C++ and then compiled to binary that runs much faster
than the current PHP version.

Summary:

• sanity checks for environmentals

• string in HipHop doesn't have 'error' property

• array_merge takes only array arguments since PHP 5 ​http://php.net/manual/en/function.array-merge.php

• $user needs instantiation first before being used

• always replace existing variables in registering new users ie. use EXTR_OVERWRITE in extract() by default

Patch to support HipHop

I may be mistaking, but the extr_skip in users is there to protect $wpdb from being overwritten by a nutty user. or $userdata itself.

Why was hiphop chocking on users but not posts or terms?

create_function ...

​http://talks.php.net/show/confoo10/15 (HipHop gotchas)

In HPHP, extract() doesn't overwrite some global variables (such as ID) which are needed by the insert_user function. PHP doesn't have such problem.

$wpdb could be removed from $userdata before extracting for safety.

Replying to Denis-de-Bernardy:

I may be mistaking, but the extr_skip in users is there to protect $wpdb from being overwritten by a nutty user. or $userdata itself.

Why was hiphop chocking on users but not posts or terms?

The create_function issue has been covered by another ticket submitted by Scott.

http://core.trac.wordpress.org/ticket/14424

Replying to hakre:

create_function ...

This one is rather old (Mar.11, 2010) and both WordPress and HipHop have evolved a lot since then.

This patch (combined with the create_function one) was proved to work with WordPress 3.0. Read my blog posts:

​http://huichen.org/en/category/wordpress/

and announcement in HipHop mailing list:

​http://groups.google.com/group/hiphop-php-dev/browse_thread/thread/8a1621c86f3aca2f/bc7c0c1e86d82b55

Replying to Denis-de-Bernardy:

​http://talks.php.net/show/confoo10/15 (HipHop gotchas)

We use EXTR_SKIP in about 50 times in core. If HPHP doesn't support it, then it will take a lot more patching than that one instance.

(In [16377]) Properly check, initialize, or cast a number of variables. props ChenHui. see #14642.

The other array casts seem to be deficiencies in the HPHP engine.

• $qs will always be an array as it is used as the by reference argument for parse_str.
• $r will always be an array, as it is either the result of get_object_vars(), $args within an is_array() check, or again parse_str.
• $kayvees will always be an array as it is func_get_arg(0) within an is_array() check.

I'd rather not add casts just to add casts, when these should be reported upstream I think.

I'm just now seeing http://core.trac.wordpress.org/ticket/14642#comment:8 which explains that HPHP declines to extract the 'ID' key, hence why we need to kill EXTR_SKIP there specifically. I'm not convinced we should make our code more convoluted there for that one change. But, if it's the only thing to stop us from full support, then it could be considered.

In the meantime, we have more create_function calls to remove.

Replying to nacin:

The other array casts seem to be deficiencies in the HPHP engine.

• $qs will always be an array as it is used as the by reference argument for parse_str.
• $r will always be an array, as it is either the result of get_object_vars(), $args within an is_array() check, or again parse_str.
• $kayvees will always be an array as it is func_get_arg(0) within an is_array() check.

I'd rather not add casts just to add casts, when these should be reported upstream I think.

I'm just now seeing http://core.trac.wordpress.org/ticket/14642#comment:8 which explains that HPHP declines to extract the 'ID' key, hence why we need to kill EXTR_SKIP there specifically. I'm not convinced we should make our code more convoluted there for that one change. But, if it's the only thing to stop us from full support, then it could be considered.

This reads very much like a bug in HPHP that would affect a lot more than just us and could randomly affect other places extract is used too :-(

The change to wp-admin/includes/user.php, initializing $user as a WP_User object, is highly destructive. It causes existing passwords to be double-hashed on save. It may have other ramifications as well.

This was quite the fun bug hunt; thanks wpdavis for tipping me off.

(In [16443]) We don't want a populated WP_User object here. see #14642.

We are past freeze and basically in beta. This doesn't seem like just a bug fix, and all committing developers should be focusing on bugs now, not enhancements. This should be punted to future release unless a lead developer believes it is a bug, not an enhancement.

Done with this for 3.1. Let's get back on it for 3.2-early.