I have a media wiki version 1.23 and php version : 5.5.6. Now I want to upgrade it to media wiki 1.42 and php 8.3. How can I do this? I am using XAMMP server in Windows.
Manual talk:Upgrading
About this board
Please do not post support questions here.
Instead, use one of these channels:
Further options for contacting appropriate people can be found at Communication.
 Archives | ||
|---|---|---|
| ||
I already replied below, but...
The starting point would be to read Manual:Upgrading carefully, because that's a big jump. As it says there, if you want to upgrade without losing data you're going to have to do it in (at least) two stages: First you'll need to upgrade to 1.35, as it's not safe to upgrade from older versions to 1.39 or later. Then when you've got it upgraded to 1.35, you can upgrade to 1.42.
When actually doing the upgrades, you should follow the instructions found in the UPGRADE text file in each distribution (first 1.35, then 1.42).
I just updated the FAQ entry on online upgrading to be a bit more current, and to include the necessary code from task T151833 since it's no longer a "workaround", it's just a necessary part of the process.
But then I noticed: The instructions are, effectively, to unpack the new version into a separate directory, transfer the locally-modified files over from the old installation to the new one, set the wiki read-only in the old directory, and then "Run the update script or the web updater in the new directory." before swapping the new directory in for the old.
How are you supposed to run the web updater from the new directory, before swapping it in as the live configuration? It's (presumably) not reachable via the webserver, unless the user also modified their server configuration to make it available (something the instructions never even hint at).
Seems to me, running the online update tool necessarily has to wait until after the new directory is made live, which sort of defeats the purpose of performing the update while the wiki remains online.
I get the impression someone shoehorned the web updater into these instructions at some point, because they want to present it as an alternative to using update.php for maintenance tasks. But this particular procedure really does rely (even hinge) on performing the (live) update via the command-line script, rather than the web updater.
Looks like the instructions were originally suggesting using git for install and upgrades, because the first paragraph mentions git. When using git you don't have to unpack the contents to a new location, because git already deletes old files that are no longer present on the new version.
@Ciencia Al Poder: I suspect you're right, yeah. Fortunately someone must've realized that a cloned git tree is also incompatible with no-downtime live upgrades, since updating the MediaWiki code in-place always necessarily risks taking down the wiki for however long it takes update.php to perform the necessary database adjustments. Swapping source directories after the completion of an update.php run is the only safe way to update a live MediaWiki instance, and neither git nor the web updater are able to do that.
(I mean, a wiki administrator can certainly use git as their method of obtaining the "new version" directory for the swap. But they can't just git pull new code into the same directory their wiki is actually executing from, without it potentially breaking until the database has been reconfigured accordingly. A process which takes a very long time, for large wikis, and so the entire point of the live-update FAQ is to detail an upgrade process that avoids all that downtime.)
I have a media wiki version 1.23 and php version : 5.5.6. Now I want to upgrade it to media wiki 1.42 and php 8.3. How can I do this?
@Raaz2 Well, the starting point would be to read Manual:Upgrading carefully, because that's a big jump. As it says there, if you want to upgrade without losing data you're going to have to do it in (at least) two stages: First you'll need to upgrade to 1.35, as it's not safe to upgrade from older versions to 1.39 or later. Then when you've got it upgraded to 1.35, you can upgrade to 1.42.
When actually doing the upgrades, you should follow the instructions found in the UPGRADE text file in each distribution (first 1.35, then 1.42).
I have tried to upgrade the MediaWiki installation on wikigenialogie.ch to version 1.42.2. When updating the 'genwiki' database, the update was cancelled with the following error message:
An error occurred:
Error 1044: Access denied for user 'genwiki'@'localhost' to database 'virtual'
Function: Wikimedia\Rdbms\DatabaseMySQL::doSelectDomain
Query: USE `virtual`
My hoster says, «Unfortunately we cannot offer you support for MediaWiki updates. We cannot do anything with the error message.»
This is the first time I've tried to upgrade in the production environment. The upgrade in the local installation on my PC worked straight away.
I am grateful for any useful information from the community that helps to solve the problem.
Installed software
| Software | Version |
|---|---|
| MediaWiki | 1.42.1 |
| PHP | 8.2.20 (fpm-fcgi) |
| ICU | 50.2 |
| MariaDB | 10.6.18-MariaDB |
Turn on debug logging for your upgrade. As a first step, I would add the following to the end of your LocalSettings.php:
$wgDebugDumpSql = true;
$wgDebugLogGroups['rdbms'] = "/tmp/sql.log";
When the upgrade fails, post the last few lines from the /tmp/sql.log file here.
I added the two lines to the end of my LocalSettings.php. The folder 'tmp' remained empty. Instead of the 'sql.log' I insert the last lines from the output window.
...site_type key doesn't exist.
...iwl_prefix_from_title key doesn't exist.
...video table already exists.
...oldvideo table already exists.
...abuse_filter table already exists.
...index afl_ip_timestamp already set on abuse_filter_log table.
...index afl_wiki_timestamp already set on abuse_filter_log table.
...skipping: index filter_timestamp doesn't exist.
...abuse_filter_log table does not contain afl_filter field.
...have af_actor field in abuse_filter table.
...have afh_actor field in abuse_filter_history table.
An error occurred:
Error 1044: Access denied for user 'genwiki'@'localhost' to database 'virtual'
Function: Wikimedia\Rdbms\DatabaseMySQL::doSelectDomain
Query: USE `virtual`
Does the word "virtual" appear anywhere in your LocalSettings.php?
No 'virtual' does not appear in LocalSettings.php.
For me patching always results in errors. A while ago it worked very smoothly, but since 1.35 I cannot use it any more. Just tried to patch a 1.39.5 to 1.39.6
Hunk #1 succeeded at 6 with fuzz 2. Hunk #2 succeeded at 24 (offset 6 lines). Hunk #3 FAILED at 43. Hunk #4 FAILED at 494. Hunk #5 FAILED at 535. Hunk #6 succeeded at 4073 with fuzz 2 (offset 3465 lines). 3 out of 6 hunks FAILED checking file vendor/composer/autoload_files.php Hunk #1 FAILED at 10. 1 out of 1 hunk FAILED checking file vendor/composer/autoload_psr4.php Hunk #1 FAILED at 28. 1 out of 1 hunk FAILED checking file vendor/composer/autoload_real.php Reversed (or previously applied) patch detected! Assume -R? [n]
Same here. any solutions?
I'm running `php maintenance/run.php update.php`
This is kind of a ridiculous message to get. Is there a way to proceed with the upgrade to 1.41.0?
That's indeed a bogus message. I'd recommend to Bugreport it.
Try using a newer mysql version.
We're running ProxySQL, which reports just "5.7". I edited a couple files to say "5.7." instead of "5.7.0" and the update ran without a hitch.
I recently installed and configured Mediawiki on dcwwiki.org. However, after my installing some Extensions today, I'm confused as the site shows a fatal error. Can someone help? I used some Commond prompts but it doesn't appear to help. After I enter my SSH details and the command, it says "-bash: $: command not found". Any ideas?
I understand that it needs an update.php but I'm really confused on how to run it.
To run update.php, change to your MediaWiki directory, then type php maintenance/update.php. Hope that's all it needs!
It returns an error saying "Could not open input file: maintenance/update.php".
I'm sure I must have missed something.
The only things I can think of are a corrupt/incomplete installation, a typo, or not being in the MediaWiki directory when you told it to update.
I was able to run the update. Thanks to Robertsky. Everything was perfectly fine and I learned running update.php for our site.
Estou utilizando a versão mais antiga da mediawiki, a versão 1.26.3.
Gostaria de saber se é possível realizar a atualização da mesma. Da pra atualizar da 1.26.3 diretamente para a versão 1.41.0 ? Ou tenho que instalar versões intermediárias antes?
If you can't upgrade regularly, it's better to stay on a LTS, which will be supported for more time. Instead of upgrading to 1.41, upgrade to 1.39.
There are several warnings on the page, one of them says:
- Since Version 1.36, MediaWiki only commits to supporting upgrades from two LTS releases ago (see phab:T259771). Upgrades from older versions of MediaWiki will have to be performed in multiple steps. This means that if you want to upgrade to 1.41 from 1.34 or earlier, you'll first have to upgrade your 1.34 wiki to 1.35 (or 1.39), and, from 1.35 (or 1.39), you'll be able to upgrade to 1.41.
Basically, upgrade from 1.26 to 1.35 first, then from 1.35 to 1.39
In the FAQ section appear these words: "If you are upgrading from MediaWiki 1.5 or newer to 1.35". Is that a mistake? Is that like saying "The price increased from $1.50 to $1.35"?
Version numbers are not decimal numbers---major (before the decimal) and minor (after the decimal) numbers are ordered separately. Thus version 1.5 is much older than 1.35 since 5<35. See Release notes for version history.
You're right! I don't know why I didn't pick up on that in that particular sentence, when it hasn't been a problem for me in countless other sentences about software versions. Maybe it's the lack of a 0 before the 5, or maybe it's the difference between something as obvious as "from version 5 to version 35" and ... well, as you said, the appearance of decimal numbers.
Now you have me wondering whether people naming software tend to pick a set number of decimal digits and then not to exceed it—e.g., if a they start with 1.x.y, x and y will always be one digit each (so the span is just 0–9), but, if they start with 1.xx.yyy, then xx will always be two digits (so the span is 00–99, not 0–99) and yyy will always be three digits (so the span is 000–999, not 0–999).
In the end, this is why I prefer colons to points (which scream "decimal point"). With a colon, it's obvious to me that 2:9 comes after 2:1 and before 2:10.
If you are using php-fpm on your wikimedia site, you should restart this service after running php update.php as it caches the php files. If you do not restart php-fpm, you will get errors loading your wikimedia site as the old code tries to use the new database.
The command is:
systemctl restart php-fpm
This is relevant on CentOS (Stream) installations, for example.
The default opcache options for php-fpm automatically reloads php files when they're modified. If you've changed opcache configuration to not check for updates unless you restart/reload php-fpm that's a particularity of your installation that you should be aware of, like any customizations.
I am upgrading my mediawiki 1.35.1. I found the upgrade instructions confusing, as the 1.4 block says you must upgrade to 1.5 "first", but the 1.35 block says you can "upgrade in one step" (to 1.5). I think I fixed one typo, but I am not sure because those two blocks of instruction seem to be in conflict.
Upon re-review, I think the typo I fixed was a correct fix, but I could use another set of eyes as I am no expert. Thanks.
Ah i was confused, 1.5 is very low, I was thinking it was higher than 1.35. Sorry I will undo my change.