Template talk:MW file

Moving this box to the right?

Could we move this box to the right side of the screen? What do you all think? Adamtheclown 06:36, 22 November 2010 (UTC) Example:

Instead of this:

MediaWiki file: importImages.php
Location:	maintenance/
Source code:	master • 1.45.1 • 1.44.3 • 1.43.6
Classes:	Find code • Find documentation

it would be like this:

MediaWiki file: importImages.php Location: maintenance/ Source code: master • 1.45.1 • 1.44.3 • 1.43.6 Classes: Find code • Find documentation

Adamtheclown 06:38, 22 November 2010 (UTC)

translation tags broken

It seems, that one of the last changes to this template breaks the usage, e.g. see Manual:GlobalFunctions.php (you can see the closing translate tags, that shouldn't be). Please fix it :) @Fabsouza1 and Shirayuki: --Florianschmidtwelzow (talk) 19:42, 23 January 2015 (UTC)

@Florianschmidtwelzow: Fixed. Thanks. --Shirayuki (talk) 00:39, 24 January 2015 (UTC)

Great, thanks :)

Links to non-existent code in older/newer releases

Look at Manual:HTML_templates#TemplateParser_(server-side). TemplateParser.php is a brand-new file in 1.25, so the links to

1.24.2 • 1.23.9

are broken. Conversely, Manual:DumpInterwiki.php is so old that its release links and Classes generated (from master) documentation link are all 404. Is there a way to hint to the template "Don't bother providing links to {{MW stable release number }} and {{MW legacy release number }}, the code wasn't available? Ideally it would do the right thing when the stable and release versions advance and the file becomes available in those releases. Easier said than done :)

-- SPage (WMF) (talk) 23:55, 2 April 2015 (UTC) (edited)

The last resort is adding a "added in" parameter as for some other templates. --Nemo 05:31, 3 April 2015 (UTC)

Yes, if Template:MW file supported starting and ending release parameters (like {{MW version }}'s Version=1.7|Version 2=1.19 parameters), and if the template could do semantic versioning comparisons of these against {{MW stable branch number }} and friends, then then the template could infer to leave out links. Sounds like a lot of work... -- SPage (WMF) (talk) 01:27, 8 October 2015 (UTC)

-- Wladek92 (talk) 15:55, 29 February 2020 (UTC)

Similar remark for Manual:MimeMagic.php see Project:Village Pump/Flow/2020/02#h-What_about_page_Manual:MimeMagic.php_?-2020-02-28T22:25:00.000Z
Not fine to see link to releases appearing AFTER the product has been removed.

link to doxygen doc?

I stumbled across Manual:Code/Entry, which fabricates links to doxygen docs for entry points. I wonder if we could add something similar to this template. E.g. includes/actions/Action.php is at https://doc.wikimedia.org/mediawiki-core/master/php/Action_8php.html . This file documentation rarely has anything interesting, but it usually lists the class(es) in the file, and their doxygen is sometimes good, e.g. class Action. -- SPage (WMF) (talk) 06:36, 5 August 2015 (UTC)

Removed in version

Files get removed... We should be able to document them as such Reedy (talk) 01:05, 25 March 2022 (UTC)

Support file moves

Sometimes, files get moved. For example, Manual:LinksUpdate.php has (as of this writing) the correct path /includes/deferred for versions <= 1.37, but for >= 1.38 the location is /includes/deferred/LinksUpdate (An all-new directory :D) and the link to source is broken. How should this template work for none of these links to be broken? Something like adding optional parameters legacyLoc=, ltsLoc=, stableLoc= that can be changed or something? 92.66.237.19 15:35, 21 June 2022 (UTC)

Yeah… there is stable= and legacy=, but… I have no idea what are they good for, as they seem to get appended to the current path parameter. --Mormegil (talk) 14:52, 15 November 2022 (UTC)

Broken doc.wikimedia.org URLs

The class1 parameter doesn't always translate to a valid URL. See for instance, Manual:VueComponentParser.php, where the link points to https://doc.wikimedia.org/mediawiki-core/master/php/classVueComponentParser.html. The assumption that for every class there is an equivalent page might be mistaken, or maybe doc.wikimedia.org just applies different rules. Anyway, I don't see how we could fix that, but we could at least add a simple warning to the template. Or follow the suggestion above (from 2015!) and send the user to pages about files instead, e.g. https://doc.wikimedia.org/mediawiki-core/master/php/VueComponentParser_8php.html, which does exist.

Cavila 19:44, 1 December 2023 (UTC)

Hi, you can fix this issue by including the fully-qualified name in the class1/interface1 parameter, for example with Manual:APIQueryRevisionsTokensHook.php, the interface is MediaWiki\Api\Hook\APIQueryRevisionsTokensHook. Hope this helps! SamanthaNguyen (talk) 20:47, 1 December 2023 (UTC)

Aha, I guess the interface links might be broken, but I adjusted the page for Manual:VueComponentParser.php so that it works now. I'll look into interface links otherwise. Thanks! SamanthaNguyen (talk) 20:50, 1 December 2023 (UTC)

Thanks, it's working. Cavila 11:15, 2 December 2023 (UTC)

Add link to hooks documentation

Many of the hook handler interfaces are also documented separately on pages beginning with Manual:Hooks/. It would be more transparent if this template automatically showed a link to such pages. Cavila 08:03, 28 August 2024 (UTC)

Please restore the legacy LTS link

I noticed the legacy LTS link has been removed quite recently. Please consider adding it back in again so we can better service developers who need to upgrade their skins or extensions from one LTS release to another. Rand(1,2022) (talk) 12:28, 7 January 2026 (UTC)