Take out unnecessary compat functions from compat.php

[markjaquith]

Now that we require PHP 5.2.4, let's take out anything in compat.php that is no longer necessary. If you'd like to tackle this, please say so. Please also verify for certain that the functions you're removing are present in ALL PHP 5.2.4 installs.

[ptahdunbar]

Functions in compat.php

• http_build_query() - PHP 5.0.0
• _() - PHP 5.0.0
• stripos() - PHP 5.0.0
• hash_hmac() - PHP 5.1.2
• mb_substr() - PHP 5.0.0
• json_encode() - PHP 5.2.0
• json_decode() - PHP 5.2.0
• pathinfo() - updated in PHP 5.2.0

All of them can be removed. I left the file there but empty for future use. In addition, pathinfo52 can be updated to pathinfo where the PATHINFO_FILENAME constant was added used in wp-admin/includes/image-edit.php:554.

[nacin]

We should kill the file and the include. We know where to find the template for future functions.

Services_JSON can go too.

[ptahdunbar]

ticket.16918.2.diff removes the compat.php file and replaces instances of _http_build_query() with http_build_query().

[hakre]

Related: #16920

[hakre]

Some more to go

[hakre]

Consolidated patch, another _http_build_query() was left in class-http.php (the only one I could find from the whole compat functions list), some references to said functions were left in comments.

[hakre]

Some more to go

[hakre]

Consolidated patch, removal of class-json.php / Services_JSON as suggested

[hakre]

_http_build_query() vs http_build_query()

[hakre]

In #16932, looking into add_query_arg() and friends I've been running over _http_build_query() again.

In this ticket we said, it's compat to ​http_build_query(), but it's not. The $key parameter is undefined and the $urlencode parameter is undefined.

It looks like that _http_build_query() has been designed pre 5.3.6 (makes sense) and that it's overloading optional parameters that are now used in a different context and therefore render the compat function incompatible.

The udpated patch reflects that for that one call in build_query().

[nacin]

The usage of _http_build_query() is clearly reliant on the requirement to not URL encode there.

[hakre]

Replying to nacin:

The usage of _http_build_query() is clearly reliant on the requirement to not URL encode there.

Will provide a fix.

[hakre]

Please review.

[nacin]

Looks good. We should probably also deprecated _http_build_query() unfortunately.

[hakre]

_http_build_query() now deprecated

[hakre]

build_query() in backwards compatible mode (fix)

[hakre]

Next to _http_build_query(), shouldn't we consider wp_clone() to be a "compat" function that's to be deprecated now? There is a patch​ in Related: #16813.

[hakre]

Would love to keep the progress going. Some dev-feedback on _http_build_query() and wp_clone is appreciated.

[ryan]

(In [17603]) Take out unnecessary compat functions from compat.php. Props hakre, ptahdunbar. see #16918

[hakre]

_http_build_query (from php.net manual) is reflected so far (thx ryan, Related: [17603]), wp_clone still pending (is less trivial than previous changes so very much OK).

however would like to see more traction which includes close (esp. in favor of #16920) of this ticket.

Subject to opinion (but?) I think this ticket can already considered closed [that's merely self-criticism].

Feedback appreciated.

[aaroncampbell]

It looks like in doing this we removed _() which is part of ​gettext right?If I'm reading this right ​gettext is optional. Should we be dropping _() back into compat.php and putting it back? See: #17064

[aaroncampbell]

Add compat.php back with _()

[joostdevalk]

mb_substr has now been removed, apparently, but mb_ functions are not a default in each PHP install, from ​http://php.net/manual/en/mbstring.installation.php :

"mbstring is a non-default extension. This means it is not enabled by default. You must explicitly enable the module with the configure option. See the Install section for details."

Please put it back as it was, as it was already throwing errors on yoast.com.

[aaroncampbell]

I decided to double check everything:

• http_build_query() & _http_build_query() can be removed: ​http://php.net/manual/en/url.installation.php
• _() cannot be removed: ​http://php.net/manual/en/gettext.installation.php
• stripos() can be removed: ​http://php.net/manual/en/strings.installation.php
• hash_hmac() & _hash_hmac() can be removed: ​http://php.net/manual/en/hash.installation.php
• mb_substr() & _mb_substr() cannot be removed: ​http://php.net/manual/en/mbstring.installation.php
• htmlspecialchars_decode() can be removed: ​http://php.net/manual/en/strings.installation.php
• json_encode() & json_decode() can be removed: ​http://php.net/manual/en/json.installation.php
• pathinfo52() can be removed according to notes: ​http://php.net/manual/en/function.pathinfo.php

I don't see why we have _mb_substr() so I combined it with mb_substr() and made a new patch.

[aaroncampbell]

Add compat.php back with _() & mb_substr()

[markjaquith]

(In [17620]) Add _() back to compat.php (it is non-default). see #16918. props aaroncampbell

[markjaquith]

(In [17621]) Add mb_substr() back to compat.php (it is non-default). see #16918. props joostdevalk

[markjaquith]

(In [17622]) Restore compat.php includes. see #16918

[markjaquith]

I think we're done here.

[sanb]

Symptom: wordpress 3.2 post-install complains of missing 'hash_hmac' function

Environment: My host is running PHP 5.2.11-pl0-gentoo

Fix: restore hash_hmac to compat.php

[aaroncampbell]

What host are you on? If they don't have hash_hmac it means they had to explicitly disable it by using the --disable-hash switch.

[ryan]

PHP needs to be reemerged with USE=hash.

[lloydbudd]

Joyent Shared Hosting has PHP Version 5.2.12 (SunOS 5.11), but defaults to --disable-json so is missing json_encode() & json_decode() and that means image editor (backend) oembeds (front end) don't work and (WordPress.com JetPack is also broken).
​http://oldwiki.joyent.com/shared:php?s[]=disable&s[]=json

I wonder how common this is. I'm contacting Joyent support to see if they will change their default.

[bsdguru]

json.so can be enabled in the relevant php.ini file (~/etc/php5/php.ini or ~/domains/domain.name/etc/php5/php.ini). If it's enabled by default it would not be retroactive - will follow up tomorrow morning about this.

[azaozz]

Replying to lloydbudd:

I'm wondering what is the reason for disabling json. It seems we will be using it more and more, expecting other functions to be transferred to json in 3.3.

[lloydbudd]

Replying to azaozz:

Replying to lloydbudd:

I'm wondering what is the reason for disabling json. It seems we will be using it more and more, expecting other functions to be transferred to json in 3.3.

Joyent's support says it is an optimization to keep the php runtime unbloated.

Looks like it's coming back with #18015: Restore compat Services_JSON (class-json.php), json_encode, json_decode

[azaozz]

Replying to lloydbudd:

Yes, seems some hosts have the right version of PHP but no JSON support for no apparent reason. Don't think "unbloated" is good enough excuse, loading it as PHP code would "bloat" it far more :)