The Page interface was introduced in r91123 (June 2011) as a temporary migration step on the way to splitting WikiPage and Article. Also as a temporary migration measure, all WikiPage public methods were duplicated into Article, proxying to WikiPage. Article::__get() and Article::__set() were added, to provide temporary access to WikiPage public member variables via Article. All of these temporary migration hacks still remain, 8 years later.
I believe that fixing this is feasible for a talented contractor.
Work plan:
- Hard-deprecate all methods of Article that say they are a "Call to WikiPage function for backwards compatibility", except for getActionOverrides().
- Hard-deprecate the following other Article methods: __get, __set, doDeleteArticle(), doUpdateRestrictions(), updateRestrictions(), doRollback(), commitRollback().
- Rectify any callers of the above methods in core and WMF-deployed extensions -
- Make Action::factory() and Action::__construct() take an Article as a parameter instead of a Page. Codesearch suggests that only Flow will be broken by this, requiring a simultaneous update.
- Add Action::getWikiPage() and Action::getArticle(). Soft-deprecate direct access to Action::$page in favour of these new accessors and fix such access in core.
- Soft-deprecate the Page interface.
- DELAYED TILL 1.36 Remove all type hints of the Page interface from core, replacing them with Article or WikiPage as appropriate. According to PHPStorm, there are only 7, all apparently quite feasible. - we have decided to delay this till 1.36, since then we will be able to replace it properly for either Article or WikiPage, and not Article|WikiPage
- Similarly, in WMF-deployed extensions, rectify direct access to Action::$page and type hints of the Page interface. - T248492