Related URL: https://gerrit.wikimedia.org/r/60080 (Gerrit Change Id3b88102e768318e3605a19e9952121091a40915)

God help me. Just when I thought the Services_JSON class was gone for good...

(In reply to comment #2)

God help me. Just when I thought the Services_JSON class was gone for good...

I do of course agree with the "upstream" classification. MediaWiki shouldn't
have to work around the problem, but rather PHP should be fixed. The main
reason I reverted the changes on REL1_21 was to avoid a worst-case scenario
in which the problem would remain uncorrected, and in response, Debian
and Fedora would start compiling PHP without JSON support, and MediaWiki
1.21 would not work for users of these Linux distributions.

(In reply to comment #0)

Until such time a version of the native JSON extension exists that does
not depend on any non-free component, MediaWiki should continue to provide
a pure PHP fallback under the terms of the GPL or another free license, or
at least make one easy to use if necessary.

Reverting the change on REL1_21 means we have six months to either fix the
problem upstream or work around the problem in MediaWiki. I'm investigating
the former: the feasibility of replacing Crockford's JSON_checker with
a different library.

It appears that the assignee listed on the PHP bug report (remi) has already
forked the JSON extension; asked for a status update on the report.

Marking as blocker for the 1.22 release. Though that is still various months away, we can't risk releasing a MediaWiki version that does not work on a PHP version compiled by Debian or Fedora.

So before 1.22 we need to either revert this whole stack (like we did for 1.21, but then in master + 1.22) or ship with free polyfills for it.

Krinkle: I have been working on a "polyfill" to emulate all PHP 5.5 JSON features as accurately as possible while exceeding the performance of Services_JSON.

So far, I have an implementation of json_encode() that seems to work OK, although I shall perform more extensive testing. I'll see if I can start
working on the decoder this week.

The JSON license doesn't seem like it has a copyleft. We could just fork the code and re-license it without the good/evil clause.

(In reply to comment #7)

The JSON license doesn't seem like it has a copyleft. We could just fork the
code and re-license it without the good/evil clause.

[This is exactly what Remi has been working on.][1]

As I noted above, he is attempting to replace the modified version of
Crockford's JSON_checker (the original was merely a JSON validator) with
the [JSON-C library][2].

The remaining portion of the JSON extension (most of the encoding code)
can be kept.

[1]: https://github.com/remicollet/pecl-json-c
[2]: https://github.com/json-c/json-c

Related URL: https://gerrit.wikimedia.org/r/64549 (Gerrit Change I11b917a371e07267dfa98b8449776d0c1cb29b15)

(In reply to comment #6)

Krinkle: I have been working on a "polyfill" to emulate all PHP 5.5 JSON
features as accurately as possible while exceeding the performance of
Services_JSON.

So far, I have an implementation of json_encode() that seems to work OK,
although I shall perform more extensive testing. I'll see if I can start
working on the decoder this week.

Debian has now packaged PECL jsonc under the php5-json package name (which
used to be a "virtual package" pointing to php5-common). Right now, the new
package is only in sid (unstable) and is not part of a released version of
Debian. I have not yet tested it with MediaWiki.

http://packages.debian.org/sid/php5-json

JsonFallback status update: I have been working on the tokenization and
string unescaping routines, and hopefully, the decoder will be ready
sometime next week.

• Bug 49122 has been marked as a duplicate of this bug. ***

Change 78941 had a related patch set uploaded by PleaseStand:
Introducing JsonFallback

https://gerrit.wikimedia.org/r/78941

The first two patches got merged, the third patch in https://gerrit.wikimedia.org/r/#/c/78941/ still needs reviews.

From Remi's comment on the PHP bug, I understand that Debian will configure PHP with --disable-json, and distribute jsonc separately. So if MW is going to run out of the box on a plain Debian PHP package, we will need a pure-PHP implementation.

(In reply to comment #14)

From Remi's comment on the PHP bug, I understand that Debian will configure
PHP with --disable-json, and distribute jsonc separately. So if MW is going
to run out of the box on a plain Debian PHP package, we will need a pure-PHP
implementation.

Why not have MediaWiki depend on php5-json? My understanding is that php5-json is both properly free and packaged for all versions of Debian that will configure PHP without JSON support.

(In reply to comment #15)

(In reply to comment #14)

From Remi's comment on the PHP bug, I understand that Debian will configure
PHP with --disable-json, and distribute jsonc separately. So if MW is going
to run out of the box on a plain Debian PHP package, we will need a pure-PHP
implementation.

Why not have MediaWiki depend on php5-json? My understanding is that
php5-json
is both properly free and packaged for all versions of Debian that will
configure PHP without JSON support.

I've been wondering this as well. I note that a Debian or Ubuntu user is likely to have to install at least php5-mysql or another such package to have database support. We could as easily mention the requirement for php5-json at the same time.

(In reply to comment #16)

I've been wondering this as well. I note that a Debian or Ubuntu user is
likely
to have to install at least php5-mysql or another such package to have
database
support. We could as easily mention the requirement for php5-json at the same
time.

If we do decide to not include a pure-PHP implementation, I will have to make two small changes to the installer, though that shouldn't be a big deal at all.

(a) Adding a new environmental check for json_encode() or json_decode()
(b) Removing one of the two uses of Xml::encodeJsVar. This is for JS encoding an array of database types that doesn't seem to be used anywhere, and which in any case should be alphanumeric (thus simple to encode).

I'll also note that compatibility code does not necessarily have to be included in core MediaWiki, if loading extension code early in the startup process (including the installation process) is allowed for.

Requiring php5-json and avoiding the reintroduction of a pure-PHP JSON parser would be fine with me, but it would be a shame to see PleaseStand's improved JSON implementation go to waste. So ideally, I would like it to be submitted to PEAR.

Change 78941 abandoned by PleaseStand:
Introducing JsonFallback

Reason:
Per bug 47431 comment 18, this code is not going to be maintained as part of MediaWiki. Reviewers, thank you very much for your comments.

https://gerrit.wikimedia.org/r/78941

(In reply to comment #18)

Requiring php5-json and avoiding the reintroduction of a pure-PHP JSON parser
would be fine with me, but it would be a shame to see PleaseStand's improved
JSON implementation go to waste. So ideally, I would like it to be submitted
to
PEAR.

And thus I am closing this RESOLVED FIXED, as having been fixed by Debian. I will shortly open a bug to track the installer changes necessary to ensure the package is not missing.

(In reply to comment #20)

installer changes necessary to ensure the
package is not missing.

bug 54774

I have updated https://www.mediawiki.org/wiki/MediaWiki_1.22 and
the installer (in gerrit 86696).

However, something that slightly worries me is that according to
http://packages.ubuntu.com/saucy/php5-json, php-json (pecl-json-c)
is in "universe" (i.e. is not an officially supported Ubuntu package).
That means Canonical won't necessarily issue security updates for it.

https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures#Responsibility

For anyone that finds this to be an issue with Ubuntu 13.10, the solution is indeed to do apt-get install php5-json...