https://bugzilla.wikimedia.org/show_bug.cgi?id=59835
--- Comment #6 from Quiddity <[email protected]> --- This patch was merged, but there's an extensive commit message, which might need further bugs filed, so I'll paste that, and leave this bug open: ConfirmEdit, captcha version This will now display the captcha to be solved in the error message. Some caveats we may want to keep in the back of our heads: 1/ Biggest potential problem here is, upon successfully completing the submitted post (with ConfirmEdit solution), the API will respond that the ConfirmEdit params were unused. This happens because those params aren't requested via the API's designated getParameter methods (or even defined in the API's getAllowedParams). ConfirmEdit just fetches them from the Request object. Basically, this happens because I treat the ConfirmEdit implementation as not- API. It has *some* (very limited) API stuff that I *could* use (if I modified ConfirmEdit a bit). However, ConfirmEdit's API part doesn't render the form, so that would be left up to us (= Flow), which is something I don't want to have to do, since there are multiple Captcha types. So basically, due to how this is implemented, the API will always respond with a warning after succesfully submitting the correct captcha solution. That warning won't affect anything, but might potentially be confusing to bot authors. 2/ Along with the captcha form HTML, some captcha implementations need some CSS/JS. Those are extracted from $wgOut & responded along with the form HTML. There's no arguing that this is not the best kind of programming, but since ConfirmEdit is messy, has multiple different implementations & completely outside of Flow, this currently seems to be the best solution. And it works ;) -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
