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 git-submodule 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:

$ git checkout 1.23wmf10
$ git submodule update --init --recursive
# takes a while...
$ cd extensions/MyActiveExtensionImWorkingOn
$ git checkout master

-- 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. ( [1] ) ( [2] ) ( [3] ). 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 --[[kgh]] (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 bug 27431). --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. --[[kgh]] (talk) 08:19, 27 May 2015 (UTC)

Me too I remove the <translation> code from inside the source tag since it carnt when <pre> is wrapped around it. Paladox2017 (talk) 11:55, 27 May 2015 (UTC)

@Paladox2017: I rolled back your edit, because you made the code, generated when using the registration 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) @Nemo bis and Shirayuki:

Sorry. I reverted your edit but added back // but remove <translation> you carnt use <translation> in a pre tag. please revert if it still doesent fix problem. Paladox2017 (talk) 13:28, 27 May 2015 (UTC)

 Done. 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

Tracked in Phabricator
Task T47096

@Shirayuki and Paladox2017: 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 <tvar <translate>" leak onto on a page, when the same tags in the parent page don't appear? (Don't answer here, link to some i18n page explanation. Thanks!) -- SPage (WMF) (talk) 01:43, 16 July 2015 (UTC)

Remove the first <translate> tag from this template and preview. The same "vagrant>Vagrant</>, install with <tvar <translate>..." appears. --Shirayuki (talk) 13:27, 9 August 2015 (UTC)

registration only

If the extensions' required version is +1.25, then below 1.24 part of |registration= is useless. Can someone remove it? (I am not that brave to touch this.) — Revi 04:49, 28 September 2015 (UTC)

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

@-revi and Ciencia Al Poder: I've updated the documentation to include this information. Sam Wilson 01:00, 22 December 2016 (UTC)

@Ciencia Al Poder and Samwilson: Even still — especially now, five years later — I wonder if it doesn't make sense for the template to take a minimum MediaWiki version supported, as an argument. Either instead of or in addition to the registration=required support. If an extension only supports MW 1.35+, it doesn't really matter what the registration argument is, those < 1.24 instructions shouldn't be shown.

That seems simpler, especially now that it probably describes most or all of the extensions that are still being developed, than gating on "registration supported/required". And having the minimum version as an argument could come in handy for other purposes down the road. -- FeRDNYC (talk) 21:27, 29 October 2021 (UTC)

Some extensions may not support extension registration. For example, Extension:SocialProfile, and it doesn't matter if it requires the latest version, --Ciencia Al Poder (talk) 14:22, 30 October 2021 (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 --[[kgh]] (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. --[[kgh]] (talk) 08:30, 12 March 2016 (UTC)

There was an effort but it is failing. --[[kgh]] (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 --[[kgh]] (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. --[[kgh]] (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#Fetch_all_dependencies 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 composer-merge-plugin parameter. -- Hoo man (talk) 14:01, 4 April 2019 (UTC)

@Hoo man: Do you mean where it currently says "Run Composer to install PHP dependencies, by issuing composer install --no-dev in the extension directory. (See T173141 for potential complications.)"? 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 vendor/ 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)

Installing / downloading

Coming here from Extension talk:JSBreadCrumbs#git clone doesn't put extension into the needed directory name. Installing an extension from a tar/gz file is more awkward when scripting the install, so I like to clone from git. This option is not addressed by the install template at all. You get a hint that its possible from the "Download" portion of Template:Extension, but the place it sends you to on gerrit provides instructions that don't work unless you have a dev account. And if you clone from Github instead then the repository doesn't necessarily have the right name, so you'd need to add that to the clone command.... and none of that is addressed in the "Download" portion of Template:Extension. So... would it maybe be better if there either was no download portion and all the info lived in an expanded Template:ExtensionInstall, which could include a subsection or even a collapsed section on how to install from git instead? Tenbergen (talk) 01:59, 24 November 2021 (UTC)

Hey there @Tenbergen, can you explain what you mean by "the place it sends you to on gerrit provides instructions that don't work unless you have a dev account"? The download link from this template to e.g. Special:ExtensionDistributor/CategoryTree doesn't have a link to gerrit AFAICS.

If we added a link to https://gerrit.wikimedia.org/r/admin/repos/mediawiki/extensions/CategoryTree that has a non-authenticated HTTPS git clone link which should work for everyone, but I don't know where the link you're seeing is coming from so don't know how to correct it. Jdforrester (WMF) (talk) 09:58, 24 November 2021 (UTC)

Hello @Jdforrester (WMF), I don't mean ExtensionDistributor at all, I have my mediawiki install set up as a script that pulls all the required extensions. Even if I have to download a single extension to test it, I find the distributor a pain, since it downloads to my PC and I then have to re-upload to my VPS. I am talking about the links inside either the Template:ExtensionInstall or the Template:Extension. For example, see the download section in the Extension template in Extension:JSBreadCrumbs; if you follow the link to "browse repository" it takes you to gerrit, and if I use the link at the top of that gerrit page it doesn't work. Sorry, is that clearer? Tenbergen (talk) 03:29, 26 November 2021 (UTC)

Yes. On that page there is exactly one line called "download" in that section caused by this template, which goes to Special:ExtensionDistributor/JSBreadCrumbs.

What link are you following? Jdforrester (WMF) (talk) 14:28, 29 November 2021 (UTC)

Installing newest/dev version via composer

Extension:Semantic MediaWiki has a master version that is quite behind by now. When I flagged it there, I was told to install a dev version, and how to do it. I had done this for non-composer extensions before, but didn't even know this is possible for extensions that use composer. Considering installing the newest version is often something the developer of an extension will suggest to fix something, should instructions for this be included? The trick I had not known about is that you can find the name of the dev master on Packagist then use composer to install it. The details of this are probably too much to actually include in this template, but it would be helpful if there were at least links to such instructions from the install section here. Maybe this and what I said above in #Installing / downloading could be addressed by adding a link to advanced or dev/test install instructions to this template. Tenbergen (talk) 01:59, 24 November 2021 (UTC)

It's a useful trick, in some rare circumstances, but for most extensions I wouldn't want to go installing their master version without knowing more about it. On the face of it this seems like a workaround to a problem that shouldn't exist — i.e. wouldn't it be better, if the newest version in master is actually ready for production, for the maintainers to just tag a release? To my mind, that's the huge benefit of using Composer to install extensions: it's easy to get minor updates and avoid major ones. Sam Wilson 01:01, 25 November 2021 (UTC)

Edit request

Please change [[Special:MyLanguage/Manual:LocalSettings.php|LocalSettings.php]] to <code>[[Special:MyLanguage/Manual:LocalSettings.php|LocalSettings.php]]</code> which appears as: LocalSettings.php. 105.105.32.74 18:18, 6 June 2022 (UTC)

Done. Sam Wilson 02:46, 7 June 2022 (UTC)

composer=always

@Lectrician1: With the new |composer=always it now says Run Composer to install PHP dependencies, by issuing composer install --no-dev in the extension directory., but is that correct even for extensions downloaded via ExtensionDistributor? They should already have a vendor directory, and there should be no need to run composer install. Sam Wilson 00:50, 11 January 2023 (UTC)

@Samwilson According to Extension:StructuredDiscussions#Post_install you need to run composer update even if you don't download it from Git. I haven't tried this myself though so I don't know if this is actually the case. I can try if you'd like. Lectrician1 (talk) 01:15, 11 January 2023 (UTC)

There's suspision that this isn't true here too: https://www.mediawiki.org/wiki/Topic:Vmw2cr7l5wc6ve3w Lectrician1 (talk) 01:17, 11 January 2023 (UTC)

@Lectrician1: Hmm, that's interesting. I can't see any reason for needing to run composer update when installing StructuredDiscussions. It also says to run it on the folder where MediaWiki is installed, which also doesn't make any sense unless it also says to add the extension to composer.local.json. I thought perhaps it might've had some post-update script, but it doesn't. I think that instruction should probably be removed, and that {{ExtensionInstall }} can be kept simpler. Sam Wilson 01:24, 11 January 2023 (UTC)

@Samwilson Okay, I tried installing it with ExtensionDistributor and it looks like it comes packaged with the relevant class that was missing when forgetting to run composer update (Pimple/Container) and works. Must have just been previous user confusion. Lectrician1 (talk) 04:14, 11 January 2023 (UTC)

Oh terrific. Thanks for digging into it. Sam Wilson 04:24, 11 January 2023 (UTC)

Only when installing from Git, run Composer to install PHP dependencies, by issuing composer install --no-dev in the extension directory. (See task T173141 for potential complications.)

Isn't that misleading though? It creates the impression that you don't necessarily need to run Composer whereas some extensions require you to run Composer in order to install dependencies. Rand(1,2022) (talk) 20:57, 25 June 2023 (UTC)

Don't display require_once instructions if the relevant version is older then than the oldest supported LTS

There are current hundreds of pages that say "To users running MediaWiki 1.24 or earlier:". Nobody's doing that these days, so there's no point in displaying the instructions. * Pppery * _{it has begun} 19:02, 9 December 2023 (UTC)

 Done the actual threshold I used is four versions older than the oldest supported LTS (hence 1.34 or lower gets suppressed, 1.35 or higher still displays). * Pppery * _{it has begun} 21:36, 22 December 2023 (UTC)