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.
- Mentioned In
- T302040: [Request for Comment] New "Event" and "Event Talk" namespaces
T251023: EditPage::getCurrentContent unexpectedly changes $currentModel and $currentFormat
T230842: Contributor creates a page
T170184: Refactor anti-spam/vandalism checks out of EditPage.php
- Mentioned Here
- T252962: Move "templates on this page" logic out of EditPage
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
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).
Unused hooks that should be removed as part of the cleanup:
- EditPageTosSummary (1 registered handler in a github repo extension that is an empty function)
 Needed to move EditPage::showTosSummary to EditViewer without needing to inject a HookRunner
Methods that are candidates to move to EditViewer without requiring EditViewer to be a service with dependencies injected, and not covered in the initial patch (only used in action=edit, not api):
- Will need current content (EditPage::getContentObject) passed
- Will need oldid passed
- Will need content length passed
You may want to consider the editing APIs as part of this. The editing team had to create ApiVisualEditor(Edit).php to fetch all the data needed for a full editing experience (e.g. loading edit checkboxes and other metadata), and in places we had to expose methods in EditPage to achieve this.