Last modified: 2014-05-16 20:00:41 UTC
See the following URL: https://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=brand&srlimit=12&format=jsonfm Compare to a completely different query: https://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&format=jsonfm
Looks fine to me when clicking on your link.
(In reply to Brad Jorsch from comment #1) > Looks fine to me when clicking on your link. Seriously? The first link shows up as normal json without the linebreaks and other prettiness. Brandon saw this first and showed it to me.
(In reply to Chad H. from comment #2) > (In reply to Brad Jorsch from comment #1) > > Looks fine to me when clicking on your link. > > Seriously? The first link shows up as normal json without the linebreaks and > other prettiness. Brandon saw this first and showed it to me. Yes i feel its okay too. Its just the parser that does the formatting.
WFM too
Logged out works for me, logged in it's broken. Disabling the CirrusSearch BF fixes it for me.
(In reply to Kunal Mehta (Legoktm) from comment #5) > Logged out works for me, logged in it's broken. Disabling the CirrusSearch > BF fixes it for me. *Now* we're getting somewhere, I can reproduce with Cirrus enabled. Even https://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=brand&srlimit=12&format=jsonfm&srbackend=CirrusSearch works. This tends to indicate something in Cirrus rather than core, but I'll look into it more deeply before saying that for sure.
Bug found. It appears that Elastica defines JSON_UNESCAPED_UNICODE and JSON_UNESCAPED_SLASHES in its Elastica/lib/Elastica/Transport/Http.php and Elastica/lib/Elastica/Bulk/Action.php, which is confusing FormatJson into thinking that it can use the new PHP 5.4 features for json_encode instead of having to manually pretty print the JSON.
I'd say this is a bug in Elastica for polluting the define namespace, only because if something goes and defines JSON_PRETTY_PRINT too then FormatJson has no real hope of easy feature-detecting. OTOH, perhaps FormatJson should also be checking for all three constants instead of just the one, Just In Case. Either way, it has nothing to do with the API.
We're dealing with this upstream in Elastica. Once it's fixed there we'll update our library. See https://github.com/ruflin/Elastica/pull/613
Resolved now that we've updated?
(In reply to Nik Everett from comment #10) > Resolved now that we've updated? Yep, looks good in beta. It'll go out with the train.
