Last modified: 2011-11-09 17:37:10 UTC
Using URL parameters to (un)check the checkboxes on Special:Block no longer works. In 1.17 and before URLs like /wiki/Special:Block/127.0.0.1?wpWatchUser=1 etc. used to work, i. e. the checkbox was checked when the page was opened. (I didn't test this myself, but an admin on de.wikipedia told me that it works.) This worked for wpAnonOnly, wpCreateAccount, wpEnableAutoblock, wpEmailBan, wpWatchUser, wpAllowUsertalk. While I am still able to fill the inputs for the text (expiry, reason) I can't find a way for the checkboxes, neither in 1.18 (tested in a wiki I installed from trunk a few days before the re-branch) nor in the current trunk.
HTMLTextField has no own loadDataFromRequest HTMLCheckField has a own loadDataFromRequest and is checking there against the method of the form (r84814), but that is always 'post' and so the values from the request are not used. Setting $form->setMethod( 'get' ); in SpecialBlock.php fixed this, but than also a validation of the input fields is done on 'get' and the special page shows a error at the first visit.
(In reply to comment #1) > Setting $form->setMethod( 'get' ); in SpecialBlock.php fixed this, but than > also a validation of the input fields is done on 'get' and the special page > shows a error at the first visit. And more importantly would submit the form via a GET request, which has a variety of negative security implications.
*** Bug 31273 has been marked as a duplicate of this bug. ***
Created attachment 9210 [details] Patch to use the request-supplied value for checkbox variables Right now, HTMLCheckField guesses if the form is being submitted (i.e. it's a method="GET" form or it supplies wpEditToken). If not, it completely ignores the request-supplied value in favor of the form's default. Perhaps the thing to do is to always use the request-supplied value any time there is one, as well as when it thinks the form is being submitted. This should result in the appropriate logic for forms such as Special:Block: ?wpWatch=1 forces the checkbox on, ?wpWatch=0 forces it off, and not specifying wpWatch at all gives the form default.
bug 31770 most probably has the same root cause.
Patched with r101464 pending code review. Will need to be merged back to REL1_18.
*** Bug 31851 has been marked as a duplicate of this bug. ***
Marking this one as resolved. Pending merge to 1.18 for tarball release.
merged in 1.18 by r102533
