Last modified: 2013-07-24 06:39:44 UTC
The code in EditPage.php doesn't separate DB and UI logic properly, and desperately needs to be totally rewritten. This lack of separation means, among other things, that calling the API action=edit module internally from a SpecialPage is horribly broken and that the API action=edit code itself is ugly.
I'd like to add that customising the edit page, or rather using its components elsewhere is very hard if not impossible.
I might try rewriting it as a special page? [[Special:EditPage]]?? Cf bug18789, bug11456, etc. Would that have a reasonable likelihood of being implemented if it worked? With the write API now well-developed, anything that breaks from making &action=edit redirect to Special:EditPage *deserves* to break. We'd need to fix bug18789 for UI consistency, but that shouldn't be too difficult (should probably be implemented in SpecialPage so it can be used by SpecialMovePage, SpecialStabilization, etc etc).
(In reply to comment #2) > I might try rewriting it as a special page? [[Special:EditPage]]?? Cf > bug18789, bug11456, etc. Would that have a reasonable likelihood of being > implemented if it worked? With the write API now well-developed, anything that > breaks from making &action=edit redirect to Special:EditPage *deserves* to > break. Sounds like a plan, as long as such an implementation separates UI and DB logic properly, with the former going into SpecialEditPage.php and the latter in something like Edit.php (the point being that the API should be able to do all its edit stuff through the Edit class without needing the SpecialEditPage class).
Would it also be possible to finally separate section title input from edit summary input? Right now they are both set with the same input, which makes the API syntax confusing.
I don't think reducing technical debt counts as an enhancement request. Futzing with the bug settings accordingly.
