Using 7zip for extracting the downloaded .tar.gz does not work. I ran into this issue myself and found a thread by someone who had the same problem: Topic:Vp73pxywm362a3t5 Using the tar command that was brought over to Windows 10 a few releases ago did work, though. This download help page should be updated accordingly.
Talk:Download
thanks @Itschotsch!
btw, tar is on board since Windows 10 build 17063 [1] (so since 21 Dec 2017[2])
[1]: https://www.addictivetips.com/windows-tips/use-tar-on-windows-10/
[2]: https://www.windowscentral.com/windows-10-build-17063-pc-everything-you-need-know
Thank you for this comment, I came here to do the same.
It's disappointing to discover that no action has yet been taken on something so fundamental.
I have wasted two days trusting the instructions as they stand.
I see where 7.4.0 to 7.4.2 is not compatible, but I'm about to upgrade from 7.0.33 to 7.4.5. Can someone verify PHP >7.4.2 is good?
7.4.3 works
1.39.4 is labeled "legacy", but according to MediaWiki 1.39, "MediaWiki 1.39 is the current long-term support release of MediaWiki." (emphasis mine). I tried changing it myself, but there were so many nested templates that I had to give up😔
Done. Apparently only Template:DownloadMediaWiki needs to be updated, commenting / uncommenting the relevant lines, to avoid invalidating translated texts.
I've made one change, to Template:DownloadMediaWiki (see Topic:W9xkf3yz1ztx9h2u) but there are other parts of the Download page to change too. I apologise if I didn't do the edit correctly.
Hi
I would like to help set up a wiki for a charity and being a regular Wikipedia editor I know how useful Visual Editor is. However the instructions to install Visual Editor all kinds of complicated and scary compared to installed MediaWiki. Would it be possible/how much extra work would it be to providea version of the MediaWiki installer which included VE?
Thanks :)
The instructions are 'scary' because it is complicated. In a few years it might be simpler, but that is not likely any time soon, sorry.
That's a disappointing perspective. I'm sure if enough people are frustrated they will make downloading it simple. John Cummings, do you have/know a contact inside Wikipedia who could change the downloading process? It didn't download for me, either.
The instructions aren't just "scary," they're lacking, vague on specific steps necessary to get it all to work.
I can see that there is no link to download 1.35, but the link for 1.39 appears twice. The parapgrahps under the links doesn't make sense neither:
- MediaWiki 1.39.1 (download .zip, download .tar.gz) - stable
- MediaWiki 1.38.5 (download .zip, download .tar.gz) - legacy
- MediaWiki 1.39.1 (download .zip, download .tar.gz) - long-term support (LTS)
To users of MediaWiki versions version 1.36, 1.37 and 1.34 and earlier: These versions are no longer supported. Please update to a newer version of MediaWiki.
I think that the third link (second time refering to 1.39.1) should point to 1.35.5 as the LTS, right?
lol we had this wrong since the release of 1.39 it seems...
I think I've fixed it
It is fixed (I am the original user). Thanks!
How often has been Mediawiki downloaded until now. Is there somewhere a page with information about that. I currently want to get a overview about how much software that is partly developed by volunteers is used.
I don't know if download counts would give you meaningful information about software usage. Note some hosting companies offer one-click installs and other solutions offer bundled software. Also, it may be available from linux distros.
WikiApiary has stats of live wikis using MediaWiki. https://wikistats.wmcloud.org/ may also be useful to get numbers on wikis inside wikifarms.
There is no link in the signature download section for MW 1.35 and the MW 1.36 is marked as Stable LTS which is incorrect
It is quite common for web hotels to only handle zip archives. We only provide gz compressed tar archives, thus the archives has to be recompressed before uploading. This souldn't be much of a hurdle, but it seems like some archive tools occasionally fails to include all files in large archives. This happen at least in Ubuntus fileroller, but reports it might imply it also happen to other tools. When this happen the vendor folder is left out, leaving the user with a rather non-explanatory error message "Installing some external dependencies (e.g. via composer) is required."
Without a proper investigation, only assumptions, it seems like some of the gui tools tries to select the actual files when an archive is created. For a gui tool this makes sense. This selection is then feed into the actual archive command. Between the actual selection and the archive operation there can be a race condition, as the selection isn't quite done and archive operation is started. This will happen if the pending selection is large enough, our archive contains ~14k files, and then the created archive will be incomplete. In our case this will typically lead to a missing or incomplete vendor folder.
Check the zip archive before it is uploaded to the web hotel, and verify that it includes the vendor folder. If not recreate the zip archive, and give whatever gui tool necessary time to select all files.
A quite simple fix could be to provide the archive in several formats. That would avoid the extraneous recreation step, and less people would stumble into this "bug".