Last modified: 2013-06-18 14:44:37 UTC
$wgAllowUserSkin/$wgAllowRealName/$wgExtensionAliasesFiles/$wgExtraRandompageSQL Linker::tooltip() (from 1.14!) since 1.16. Most are calling each other, so can be generally cleaned up Linker::makeBrokenLink() Linker::makeLinkObj() Linker::makeKnownLinkObj() Linker::makeBrokenLinkObj() Linker::makeColouredLinkObj() Linker::makeImageLinkObj() LogReader and LogViewer but that's bug 24711 Seems the Linker ones are the bigger issues...
$wgExtensionAliasesFiles is another
makeBrokenLink is called by Interlanguage Extension makeLinkObj is called by AjaxShowEditors, FCKeditor and SemanticForms makeKnownLinkObj is called by SemanticForms (x2) and in Linker::makeColouredLinkObj makeBrokenLinkObj is called by Linker::makeBrokenLink makeColouredLinkObj is called by Linker::makeColouredLinkObj (deprecated in 1.17) makeImageLinkObj killed
(In reply to comment #1) > $wgExtensionAliasesFiles is another I think we should keep that around a little bit longer so extensions don't break back-compat. Maybe next release.
It should be fine to start removing the code for 1.18
moving to low priority since we're not desperate to get this done.
Not a 1.18 blocker, and one that we shouldn't do for the sake of doing. If there's a feature that we're working on that breaks these, then we can remove them as part of that work, but we shouldn't break backwards compatibility just for giggles.
(In reply to comment #6) > Not a 1.18 blocker, and one that we shouldn't do for the sake of doing. If > there's a feature that we're working on that breaks these, then we can remove > them as part of that work, but we shouldn't break backwards compatibility just > for giggles. Well stuff that's already marked for deprecation can be slowly phased out once extensions have all been updated (and then the general consensus is to wait at least one more release). When we mark stuff @deprecated these days we generally mention when they were first deprecated so we can properly remove them over time. But yes, removing deprecated code shouldn't be a blocker unless it's breaking something by remaining there.
Changing default assignee per IRC
No real reason for this to explicitly stay open
