| MarkAHershberger | |
| Oct 6 2011, 2:39 AM |
| F8006: diff | |
| Nov 21 2014, 11:48 PM |
When changing a block, the block reason used to pre-load into the "reason" box on [[Special:Block]]. This seems to have been changed – now the reason box remains blank when you wish to change a block. (e.g. [http://en.wikipedia.org/wiki/Special:Block/95.76.70.248]) Could this be changed back?
Version: 1.18.x
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Amire80 | T23778 BiDi issue in RTL wikis at site notice with LTR text ending with Unicode characters with neutral directional | |||
| Resolved | None | T31876 1.18 post-deployment actions (tracking) | |||
| Resolved | None | T33405 Pre-load block reason |
http://en.wikipedia.org/w/index.php?diff=next&oldid=454279133
Normally, when deleting a CSD-tagged page the reason in the tag is automatically preloaded when one goes to delete the page. Doesn't seem to be happening today.
It is better if the previous reason is preloaded.
It is easier to delete a preloaded reason than to copy-and-paste it from before.
Please restore to past state.
happy.melon.wiki wrote:
I very much doubt these are the same phenomenon: the new SpecialBlock interface uses HTMLForm while the delete interface is still horrible hardcoded crappery in Article::confirmDelete().
happy.melon.wiki wrote:
(In reply to comment #1)
http://en.wikipedia.org/w/index.php?diff=next&oldid=454279133
Normally, when deleting a CSD-tagged page the reason in the tag is
automatically preloaded when one goes to delete the page. Doesn't seem to be
happening today.
Plus this is done by some JS trickery on enwiki, not anything in the default software. And it seems to be fixed now.
Created attachment 9211
Patch to properly handle the form default value for HTMLSelectAndOtherField
The problem with Special:Block is that HTMLSelectAndOtherField's loadDataFromRequest method doesn't parse the form's default value into the 'select' and 'text field' components, instead returning just the 'combined' value. And its getInputHTML method ignores the 'combined' value in favor of the 'select' and 'text field' components.
An easy fix is to just put "other" for the 'select' component and the default as the 'text field' component. Or we can go one better and actually split it apart, as in the attached patch.
Attached: