Template talk:ExtensionInstall

Misleading for developers, just use git
Pointing developers to Special:ExtensionDistributor is a bad idea if the extension has a git repository, and I think all the extensions it supports have one. Developers want the latest code, and want to be set up for git updates. ExtensionDistributor seems to just get a tagged release from github, so you might as well use git and pick a tag or branch.

One approach is to check out a particular branch of core, then use  to get all the extensions that WMF uses (whether or not you deploy them all), then check out master of particular extensions you're developing: -- S Page (WMF) (talk) 04:15, 11 January 2014 (UTC)
 * I updated the template to tell developers to use git clone instead. -- S Page (WMF) (talk) 04:23, 11 January 2014 (UTC)
 * I've added the parameter "repo-name" to the template, to be filled with the git repository name for the extension. When filled, it generates the "git clone" command to be used. --Sophivorus (talk) 20:52, 9 February 2014 (UTC)


 * This is incorrect. MediaWiki-associated branches are branches, not tags. They are in git. ExtensionDistributor gets them directly from Git. There is already a dedicated Git-download section on most extension documentation pages, plus there's several pointers about Git in the extension infobox. Having another dedicated block about it in the install section is rather excessive and imho confusing to the user. And the extension distributor snapshot is exactly the same as what you'd get when cloning the repository. I don't see how that would be a bad idea. If you're experienced issues with outdated snapshots or missing submodules, please file a bug. Krinkle (talk) 15:11, 13 September 2014 (UTC)

different names and different names for php files
hi please add support for extension with different name for the extensions and different names for the php file please for example wikibase has three main files it has repo and lib and client. 86.135.250.146 18:54, 25 January 2014 (UTC)

__DIR__, $IP or nothing
I noticed that the $IP has been replaced by __DIR__, allegedly because it's the "preferred way". But isn't it just the same to omit $IP or __DIR__ altogether? Are there some cases in which they may become necessary? --Sophivorus (talk) 20:28, 9 February 2014 (UTC)

Yes, "__DIR__" crashes (on a wiki I host at DreamHost) because apparently I'm still using an old version of PHP. Both "dirname( __FILE__ )" and "$IP" seem to work fine for me. While sometimes there are good reasons to mandate newer versions of PHP, this looks like a gratuitous unnecessary incompatibility. I see people recommend replacing every "__DIR__" with "dirname( __FILE__ )" for compatibility reasons -- so the PHP scripts work in both old and new versions of PHP. . I would prefer to omit them entirely from these instructions if none of "$IP", "dirname( __FILE__ )", or "__DIR__" are necessary. So I repeat Sophivorus's question: Are there some cases in which they may become necessary?

So I reverted the edit that added "__DIR__", since it doesn't work for me. --DavidCary (talk) 18:49, 18 February 2014 (UTC)


 * Recently there have been so many changes to this template regarding how to invoke extensions that I stopped caring about which one might be the preferred method or not. What I do not like about this frantic editing is that is just confuses everybody. Thus I suggest to protect this template so only admins may edit it after or before we get our act together. Cheers --&#91;&#91;kgh&#93;&#93; (talk) 19:07, 18 February 2014 (UTC)
 * $IP is definitely preferred, and will break less things. I've restored it to the way it originally was. Legoktm (talk) 22:45, 21 February 2014 (UTC)
 * Would you care to explain why, Legoktm? --Sophivorus (talk) 14:43, 1 March 2014 (UTC)
 * Using __DIR__ or dirname( __FILE__ ) assumes that the file with that line in it is in the same directory as the "extensions/" directory. Using $IP doesn't. Legoktm (talk) 23:53, 1 March 2014 (UTC)
 * That seems like an argument for using __DIR__, which is what I recommend doing. Why would you use a global? If you have a file in a dir or a subdir, then __DIR__ is the right tool for the job. --Jeroen De Dauw (talk) 23:59, 1 March 2014 (UTC)
 * The whole point of using $IP is that you don't want to make the assumption that it is in the same directory. Legoktm (talk) 00:27, 2 March 2014 (UTC)
 * Dear Jeroen De Dauw, I tried all three of "__DIR__", "dirname( __FILE__ )", and "$IP". I found that the LocalSettings.php MediaWiki script halts with an error message when I use "__DIR__" in any of the lines that set up a MediaWiki extension. I found 3 links to people who discuss situations where "__DIR__" doesn't work for them, either. Does that answer your question? --DavidCary (talk) 15:45, 3 April 2014 (UTC)

Any arguments to this template end up outside of the box!
Any arguments to this template end up outside of the box! See e.g., Extension:MobileFrontend. Jidanni (talk) 06:43, 1 April 2014 (UTC)

Installing without command prompt access
Extension:Checkuser has one such section. This is not extension-specific so it should not be maintained on an extension page. Should it be handled by the template when an extension needs install.php/update.php, or live in some manual page and be linked from it? Cf. Thread:Project:Current_issues/Installation_guide_consolidation. --Nemo 17:32, 29 May 2014 (UTC)


 * It shouldn't be necessary if the extension is doing the right thing and using the necessary hooks to perform the custom installation steps through MediaWiki's installation script (either the web updater or update.php), which sadly it's not the case (see ). --Ciencia Al Poder (talk) 09:12, 30 May 2014 (UTC)

Template completely broken in conjunction with translations
The recent changes to the template completely broke it. When looking e.g. at Extension:TitleKey or Extension:Cite you can see it in action. Does not matter if it is using TNTN or TNT. Perhaps User:Shirayuki knows what to do. A fix will be cool since quite a substantial number of pages is affected. --&#91;&#91;kgh&#93;&#93; (talk) 08:19, 27 May 2015 (UTC)


 * Me too I remove the code from inside the source tag since it carnt when  is wrapped around it. Paladox2017 (talk) 11:55, 27 May 2015 (UTC)
 * I rolled back your edit, because you made the code, generated when using the  parameter invalid, which isn't acceptable :) And, btw., i don't see a problem with this extension on the extension you named and Extension:ConfirmEdit?!--Florianschmidtwelzow (talk) 13:22, 27 May 2015 (UTC)
 * Sorry. I reverted your edit but added back // but remove you carnt use in a pre tag. please revert if it still doesent fix problem. Paladox2017 (talk) 13:28, 27 May 2015 (UTC)
 * ✅. We can use translate tags in source tags.--Shirayuki (talk) 20:17, 27 May 2015 (UTC)
 * Oh did not know that I throught that was the reason why it was causing the problem. Paladox2017 (talk) 22:30, 27 May 2015 (UTC)

Template broken on its own
When this template is used on its own (without TNTN or TNT), it is now totally broken (since May 26). Compare Template:ExtensionInstall/test with Template:ExtensionInstallOld/test. Kaldari (talk) 22:26, 27 May 2015 (UTC)
 * You can see this breakage on numerous pages, including Extension:ExcludeRandom. Kaldari (talk) 23:39, 27 May 2015 (UTC)
 * This is a known issue, I think. Any transcluded page (usually templates) that use translate tags, needs to be transcluded through TNT or TNTN templates, otherwise the translate tags are leaked into the page. This is a known issue, I think, and what needs to be done is to use a bot to change the way this template is transcluded, as I already suggested. --Ciencia Al Poder (talk) 09:16, 28 May 2015 (UTC)
 * TNT transcludes Template:ExtensionInstall/en instead of Template:ExtensionInstall. So TNT should be added automatically. --Shirayuki (talk) 11:47, 28 May 2015 (UTC)
 * That's correct, but TNT is not being added automatically. Someone needs to add that template manually on each page where this template is being used directly, or use a bot for doing that. --Ciencia Al Poder (talk) 14:36, 28 May 2015 (UTC)
 * Any transcluded page (usually templates) that use translate tags, needs to be transcluded through TNT or TNTN templates, otherwise the translate tags are leaked into the page. But why is that? What is it about transclusion that makes " vagrant>Vagrant, install with Vagrant, install with Revi 04:49, 28 September 2015 (UTC)


 * Try using  --Ciencia Al Poder (talk) 09:30, 28 September 2015 (UTC)


 * I've updated the documentation to include this information. Sam Wilson 01:00, 22 December 2016 (UTC)

Extension switched do new loading system later
This template assumes that the switchover for every extension was MW 1.25. What about extension which were switched over at a later point like the ConfirmEdit with MW 1.26. It will be nice to have an option to specify the branch for the switch. Thanks and cheers --&#91;&#91;kgh&#93;&#93; (talk) 17:34, 11 February 2016 (UTC)


 * That's pretty annoying. Some extensions start out with MW 1.25, some with MW 1.26 ... This should be fixed. --&#91;&#91;kgh&#93;&#93; (talk) 08:30, 12 March 2016 (UTC)


 * There was an effort but it is failing. --&#91;&#91;kgh&#93;&#93; (talk) 21:13, 1 December 2016 (UTC)


 * That's because nobody marked that edit for translation --Ciencia Al Poder (talk) 19:18, 2 December 2016 (UTC)


 * Ah, now I get it. I was really wondering why this was not working since the code looked very much ok to me. Thanks for the info. @Shirayuki Will you be so kind to accept the changes. It is pretty important to be able to set this. Thanks and cheers --&#91;&#91;kgh&#93;&#93; (talk) 21:24, 2 December 2016 (UTC)


 * @Shirayuki Thanks a lot. I hate to tell but after the change got trough I say that the text now does not make sense so I had to tweak. Anyways, at least the very important part is in. --&#91;&#91;kgh&#93;&#93; (talk) 22:27, 2 December 2016 (UTC)


 * This problem still exists and is currently causing Support Requests. Please make sure that the current content from Template:ExtensionInstall really gets used! Currently extension pages like Extension:CategoryTree are still showing some old junk. The part "since MediaWiki 1.25" is still displaying there and it is just wrong. This already forced users to manually do additional edits to extension pages, telling that the texts from this template are wrong. --83.135.237.110 15:59, 2 January 2017 (UTC)


 * On Extension:CategoryTree I see now To users running MediaWiki 1.27 or earlier: (...), so the problem seems fixed. --Ciencia Al Poder (talk) 10:21, 3 January 2017 (UTC)
 * That line was not the problematic one, it was the following sentence, which always had the number 1.25 in it. And that number was just wrong. When I checked yesterday, Template:ExtensionInstall had already been fixed so that this wrong number no longer was there. But pages like Extension:CategoryTree still showed the old sentence with the wrong number. Do you know, how that was fixed between yesterday and now? I see you have not edited the template. There only was an edit by FuzzyBot, which updated the English translation - has this fixed the problem? If so, how can I trigger such a bot run? --87.123.253.9 13:15, 3 January 2017 (UTC)
 * Ah, that's because a translation admin marked the current version for translation. Translated templates act like Flagged Revs. Only a translation admin can do that. Even normal sysops like me can't do that. --Ciencia Al Poder (talk) 21:46, 3 January 2017 (UTC)
 * Oh, ok. Thanks for the info! Things are getting complicated by the fact that you can edit the basic page with English content, but for it to get used, a bot has to be run, to update translations, while in fact it is no translation, but the English original, which should be used, and which is used after all. This, and the fact that it needs special permissions to make the English page being used while you can edit all normal English pages without such special permission, adds unnecessary complexity here. --83.135.239.229 13:12, 6 January 2017 (UTC)

Composer instructions should use the "composer-merge-plugin"
The composer instructions IMO should instruct users to use the composer-merge-plugin, like on Wikibase/Installation instead of directly running composer in the extension dir. Unless someone objects, I will change this soon… or we might want to add a new  parameter. -- Hoo man (talk) 14:01, 4 April 2019 (UTC)


 * Do you mean where it currently says ? I think it's great idea to recommend people add to composer.local.json instead, but there are some issues with that aren't there? Mainly, that if MediaWiki is installed from a Git tag, then then  is a submodule and would become out of sync if Composer is run in the root directory. My understanding is that is why it's recommended that extensions get their dependencies installed in their own directories. But I might be misunderstanding. —Sam Wilson 14:38, 4 April 2019 (UTC)

"When installing from Git" should include direct downloads
The phrase "When installing from Git run Composer to install PHP dependencies" leaves out direct downloads. It's possible to simply download a snapshot of an extension and these will usually also require composer to be run, like for the TemplateStyles extension. But since this explicitly refers to Git, it makes it seem like the static downloads come with dependencies. 95.97.234.31 15:32, 24 May 2020 (UTC)