- 1 further plans
- 2 Extension Configuration
- 3 No shell access
- 4 Uninstall?
- 5 Temporarily uninstall extension?
- 6 Don't give me unexplained install alternatives
- 7 Installation by transferring installed files to the intended server
- 8 Composer working & not working some of the time
- 9 Composer not installing
- 10 composer.json galore
- 11 Composer on Plesk
There are many extensions witch helps to put extensions dependency under control (like Extension:Wiki Administration Tool). Is there a purpose to use composer instead or as a base? Exbe (talk) 21:41, 4 January 2013 (UTC)
Many extensions rely on or benefit from configuration. How is this accomplished with Composer? —The preceding unsigned comment was added by 126.96.36.199 (talk • contribs) 18:23, 15 December 2013 (UTC)
- I'm wondering the same. --Nemo 13:15, 1 January 2014 (UTC)
No shell access
Looks like a great step forward (congrats!), but how do we run this on a shared host? Cavila (MW 1.19.7, MySQL 5.1.72-2, Php 5.3.3-7, SMW 188.8.131.52, SF 2.5.2) 16:24, 16 December 2013 (UTC)
- My question has been answered elsewhere. You can't install this without shell access. Cavila (MW 1.22, MySQL 5.1.72-2, Php 5.3.3-7 squeeze, SMW 184.108.40.206, SF 2.6.1) 17:23, 8 January 2014 (UTC)
- Well, but the question remain. I really love composer where I have access to the shell, but some extensions must be installe with composer, and where you have not the shell you are in trouble. How overcome this issue? --Gborgonovo (talk) 21:24, 8 March 2014 (UTC)
- There is no solution, other than the workaround Nikerabbit explained above. If you use a FTP-only web host, you should be used to preparing your files locally and then upload them. --Nemo 09:19, 10 March 2014 (UTC)
- I guess you first have to remove the extension from composer.json and then remove it from LocalSettings.php. Maybe there is a command like
composer remove? I've never used that software. Perhaps you only have to remove the extension from composer.json and run
composer updateafterwards, but I guess the frist solution is the proper one. Tim (SVG) 15:07, 1 January 2014 (UTC)
- I tried above, but was unsuccessful. I'm not able to identify to what file Composer "installs" the extension, but it doesn't appear to be localsettings.php. Any guidance on this would be helpful--in fact, I think that if more and more extensions are going to be using Composer as a requirement), then uninstall instructions are essential Patelmm79 (talk) 16:14, 31 January 2014 (UTC)
- Removing a package can be done using `composer remove myVendor/myPackage`. For details, see .
Temporarily uninstall extension?
When debugging, it is sometimes quite useful to temporarily disable an extension. However, the only way to disable extensions using composer seems to be to remove them from composer.json and run composer update. This seems much more complicated (because it is not possible to comment out a line, it has to be deleted and later re-added) and wasteful (in terms of bandwidth) than temporarily commenting out a require_once in LocalSettings.php. Is there some easier way to do it? -- Tbleher (talk) 05:54, 25 June 2014 (UTC)
- There is a (long!) discussion about this at Thread:Talk:Requests for comment/Extension management with Composer/A way to disable extensions. --Nemo 06:23, 25 June 2014 (UTC)
Don't give me unexplained install alternatives
Download Composer. See the instructions on that download page for all options. Important to note is that one can simply get the composer.phar file and run Composer via this file.
Why is this important to note? What difference does it make? Since the composer page does a poor job of explaining what it does ("Just feed some random file on the web into php, what could go wrong(TM)?") it doesn't help at all to offer an alternative without comment.
Neither the composer download page nor this alternative suggest a directory in which to get composer.
- Not sure what makes you so upset but when looking at [0, 1] the installation guide is rather clear about what to do.
Installation by transferring installed files to the intended server
This method is recommended to users who don't have shell access to the server of their site, but it would help to know what files are supposed to get transferred and if that's sufficient. Obviously there are the files in the extensions folder, but what comes next? Composer.json? Or just certain lines from composer.json concerning the extensions you want to transfer? I tried adding a line to Localsettings.php in the old-fashioned way but that leads to an open base dir restriction of some kind, so apparently that's not the way to go. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 15:25, 28 November 2014 (UTC)
- If for some reasons you don't have directly access to a CLI (command-line interface) or internet it is recommended that you use `composer install` or `composer require` on a device that has both. After a successful installation (normally indicated by Composer outputting "... Writing lock file") transfer the new files (or more precisely the new/updated folders) (from the `/extension` and `/vendor` folder) to your server location. You may as well copy the `composer.json` and `composer.lock` file to keep an appropriate history of the installation process. The `/vendor` folder is important as it contains a generated autoloader that some extension make use of and not copying the folder will eventually lead to issues.
- Thanks for this. I was trying to find out if I could copy the Lingo and Semantic Glossary files over to my site, but I'm afraid that this approach won't work in my case. The site just hangs when the vendor folder is available. There are already several files in the vendor folder that I don't need and so could be interfering with the installation process, but more importantly, I'm using a Semantic Bundle version of SMW and other extensions. I was hoping, though not necessarily expecting, that the approaches would be compatible, because Composer is not used on my site (or at least not directly), but that's not the case apparently. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 14:14, 1 December 2014 (UTC)
- Mmm, I just tried a clean install with MW 1.24.1 and SMW 2.1, copied the SMW extension folder as well as 'vendor' to the new site (and added the json files), then added the 'enableSemantics' setting to the bottom of Localsettings.php, but all that this achieves is a blank page. I also tried my way around this by removing folders from 'vendor' that do not seem relevant to SMW (I would guess that 'twitter' and 'less' belong to the Chameleon skin), but that doesn't work either. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 13:23, 9 March 2015 (UTC)
- Four months later and it's finally working! There was a blank page at first, but it disappeared after a while (in less than two minutes I think) and the site could be accessed again. The system apparently needs some time to digest the changes. Cavila (MW 1.22, MySQL 5.5.37-0, Php 5.4.4-14 squeeze, SMW 1.9.2, SF 2.7) 12:12, 30 March 2015 (UTC)
Composer working & not working some of the time
So I'm setting up a new wiki. I load some extensions via composer and everything is great. I load other extensions through composer, but the extensions never show up in Special:Version. Just so we're clear I re-ran composer and I'm told nothing needs to be loaded since it's all been loaded. Nothing, however, shows in the composer.json file.
- Never mind. Solved my own problem. It was a wrong path issue.
Composer not installing
I tend to get this message with a recent installation:
# php composer.phar require mediawiki/maps "*"
./composer.json has been updated Package "mediawiki/maps" listed for update is not installed. Ignoring. Loading composer repositories with package information Updating dependencies (including require-dev) Nothing to install or update Generating autoload files
Any idea why the "ignoring" is being done? I have several successful installation with it and never ran into this issue. I did a self-update but to no avail.--Temptuousinsolence (talk) 08:23, 8 December 2014 (UTC)
There is a composer.json in root and in /vendor. I had the utmost supid idea to install an extra extension via composer. After trying to update with "composer update" the extension indeed gets updated and half the rest of the software gets removed from vendor leaving my wiki buried in a pile of surgar. This is painful and I am not sure what to do. Should I just copy the contents from the composer.json into the file in root??? This appeas pretty ridiculous to me but is the only thing I currently can come up with. --220.127.116.11 19:17, 29 December 2014 (UTC)
- Yeah, copying the required stuff from the composer.json in vendor into the file in root is the way out. composer.json is currently a thing to care about manually. So there is a second "config" file for MediaWiki apart from LocalSettings. Easy going is different I guess. --18.104.22.168 18:56, 30 December 2014 (UTC)