Manual talk:Upgrading

Please do not post support questions here.

Instead, use one of these channels:

• Project:Support desk
• the mailing list
• Wikimedia Developer Support

Further options for contacting appropriate people can be found at Communication .

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.

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]

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"?

Preslethe (talk) 18:39, 22 July 2023 (UTC)

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.

Preslethe (talk) 19:55, 23 July 2023 (UTC)

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.

I have error when trying to excute update.php

PHP Fatal error:  Uncaught Exception: Unable to open file /var/www/html/w/extensions/LocalisationUpdate/extension.json: filemtime(): stat failed for /var/www/html/w/extensions/LocalisationUpdate/extension.json in /var/www/html/w/includes/registration/ExtensionRegistry.php:199

This suggests that you have code in your LocalSettings.php file trying to load the old and no-longer-supported LocalisationUpdate extension. If you comment that out, it should work.

The config i have written is just a modified default 1.38 configuration file

the update script does not mess with the database as just simply excuting the --help command will have the error

here is the full one to better understand the error

PHP Fatal error:  Uncaught Exception: Unable to open file /var/www/html/m/extensions/LocalisationUpdate/extension.json: filemtime(): stat failed for /var/www/html/m/extensions/LocalisationUpdate/extension.json in /var/www/html/m/includes/registration/ExtensionRegistry.php:199

Stack trace:

#0 /var/www/html/m/includes/GlobalFunctions.php(53): ExtensionRegistry->queue()

#1 /var/www/html/m/LocalSettings.php(153): wfLoadExtension()

#2 /var/www/html/m/includes/Setup.php(218): require_once('/var/www/html/m...')

#3 /var/www/html/m/maintenance/doMaintenance.php(83): require_once('/var/www/html/m...')

#4 /var/www/html/m/maintenance/update.php(312): require_once('/var/www/html/m...')

#5 {main}

  thrown in /var/www/html/m/includes/registration/ExtensionRegistry.php on line 199 I have tested the 1.38 update.php and the php script executes the following command --help flawless Theoldvectortheme (talk) 12:10, 5 January 2023 (UTC)

@Theoldvectortheme:

The config i have written is just a modified default 1.38 configuration file

...Modified how?

According to the traceback you posted, there's a wfLoadExtension() call on line 153 of /var/www/html/m/LocalSettings.php that's triggering the problem, presumably by trying to load LocalisationUpdate (either directly or indirectly).

What's on line 153 of your LocalSettings.php?

Here is my config []

Yes, you need to delete line 147 in your file (wfLoadExtension( 'LocalisationUpdate' );).

Thanks

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

Hi,

I did a upgrade to version 1.37.2. There was no error, but there is no pic on my site. What I do not understan dis "chgrp -R apache images" what is web user "apache"? All pic are on my server and when I try to upload a new version of existibg pics I get the message that the file is empty. I found some older advices but nothing works for me. when I run maintenance/rebuildImages.php I get that 0 of 14 rows are effected.

Can anyone help me?

Thanks

Masen

Please do not post support questions here.

Instead, use one of these channels:

• Project:Support desk
• the mailing list

Further options for contacting appropriate people can be found at Communication.