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.42.3 • 1.41.4 • 1.39.10
Classes:	Find code • Find documentation

it would be like this:

MediaWiki file: importImages.php Location: maintenance/ Source code: master • 1.42.3 • 1.41.4 • 1.39.10 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 Topic:Vho2o28hvu52yik1
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)