--- Comment #4 from Roan Kattouw <> ---
(In reply to Alex Monk from comment #3)
> James suggested I tackle this bug. I messed around with the API for a little
> bit and assuming I didn't miss anything:
> I think that if we tried to fill out the 'blockedtext' message properly on
> the client we'd have to:
> * Query the API for the user's blockinfo to determine whether or not they're
> blocked. If they are:
> ** Query the API for more info about this block which
> meta=userinfo&uiprop=blockinfo doesn't provide but we need to substitute
> into the message (expiry, user, timestamp).
> ** Query the API to parse the blockedtext message because it can't be done
> on the client (even the default message includes stuff mw.msg can't handle)
> ** Substitute the data we have into the message (and we still won't have $3
> - the current IP)
> *** Mess around with dates/times because they won't be in the right format.
> Another way we could do this is return the full warning from
> action=visualeditor&paction=parse (therefore adding no extra API requests)
> which would cause the client to stop loading. I don't like this idea because
> obviously that paction is not intended for checking this kind of thing...
> Or we could ignore the core blockedtext message and use our own "Your
> username or IP address has been blocked", possibly with the info that just
> meta=userinfo&uiprop=blockinfo provides (block ID, performer, reason).
> Or we could add a new API module/paction that can be queried once and
> provides all the relevant info. I don't like this idea either but it seems
> the nicest.
We already put random junk in the paction=parse response, I wouldn't be opposed
to adding blocked-ness to that. Another paction would be OK too, but then we'd
have to make two API requests.

There are significant speed benefits in combining everything into one API
request. I think we should stop kidding ourselves that paction=parse is a
clean, only-does-one-thing action, and perhaps rename it if we want, rather
than trying to split it into separate actions, because the latter would just
make client-side performance worse.

You are receiving this mail because:
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to