In T151833#8257872, @FeRDNYC wrote:

After I updated the instructions in that FAQ entry to include a version of the code above, including the check to preserve web-updater write access, I realized: The instructions tell the user to run the web updater in their new installation directory, before making it live. Which AFAICT isn't actually possible.

How are you supposed to access the updated version's web interface, when it hasn't been published to the web server yet? It's not as if you can run <new version>/mw-config/index.php from a file:/// URL.

I brought this up on the manual page's talk page as well. I really think the web updater is just not the proper tool for doing this style of low-disruption, online upgrade. People who want to use the web updater instead of update.php will probably just have to accept the tradeoff that it comes with some unavoidable downtime.

In T151833#8257849, @FeRDNYC wrote:

@aaron : Actually, testing locally I'm getting an error in the PHP logs, with is_defined():

[24-Sep-2022 23:46:37 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function is_defined() in /var/www/wiki/LocalSettings.php:190
Stack trace:
#0 /usr/share/mediawiki/includes/Setup.php(204): require_once()
#1 /usr/share/mediawiki/includes/WebStart.php(93): require_once('...')
#2 /usr/share/mediawiki/index.php(44): require('...')
#3 {main}
  thrown in /var/www/wiki/LocalSettings.php on line 190

There's a defined(), but I'm not sure whether that has the same semantics.

EDIT: defined() seems to work as expected, so I'm going to assume that was the intended function to use in checking for MEDIAWIKI_INSTALL.

After I updated the instructions in that FAQ entry to include a version of the code above, including the check to preserve web-updater write access, I realized: The instructions tell the user to run the web updater in their new installation directory, before making it live. Which AFAICT isn't actually possible.

@aaron : Actually, testing locally I'm getting an error in the PHP logs, with is_defined():

Brilliant, thanks! Is there any issue with splitting it up into two lines (actually, two statements on three lines) like this, for readability?

You could do:

$wgReadOnly = ( PHP_SAPI === 'cli' || is_defined( 'MEDIAWIKI_INSTALL' ) ) ? false : 'This wiki is currently being upgraded to a newer software version.';

Apologies for dredging this up, I just wanted to ask one point of clarification on the code @aaron
provided above:

Today I was unable to rename a page. It was trying to insert into the logging table but that failed because log_id is NOT NULL but no default was set. I suspect it was caused by the same thing as my comment above, the wrong schema making some updates fail. (I rarely move pages, so I wouldn't notice until now.) The fix was this:

Solved: In my case, several sequences, functions, and a type where in schema "mediawiki" while the rest was in schema "public". I moved everything to "public" and the update script worked perfectly. Example commands:

Change 578056 merged by jenkins-bot:
[mediawiki/core@master] Remove check for vulnerable PHPUnit version

Change 578056 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/core@master] Remove check for vulnerable PHPUnit version

I am seeing this error upgrading from 1.27 LTS to 1.31 LTS. PHP 7.2, PostgreSQL 9.6.14.

Meh, just abandon the patches then :)

We don't do REL1_28 releases any more, do we? 1_27 for the next year, 1_29 for the next couple of months, and 1_30 'til the end of the calendar year. So maybe the jobs aren't properly configured for it?

Change 423650 merged by jenkins-bot:
[mediawiki/core@master] tests: fix PHPUnit @requires for APCU

Change 423650 had a related patch set uploaded (by Hashar; owner: Hashar):
[mediawiki/core@master] tests: fix PHPUnit @requires for APCU

Verified, gzip'd, signed and uploaded the patch, thanks for submitting it! Sorry for the confusion around having two separate patches for this.

This is not resolved yet, and is so broken that I'm increasing its priority due to the fact that it is currently stopping users from being able to upgrade their wikis according to the simple "Using Patch" documentation. Forcibly upgrading by replacing all files is still an option but not recommended according to Mediawiki.

Done.
Would be great if somebody could suggest a way how the "skin there [can] be fixed somehow to not have web-loaded resources in the vendor directory". Preferably without dumping Composer entirely.

MediaWiki currently doesn't require vendor/ to be web accessible, so I suspect that your skin wouldn't work for many people already. In the meantime you can just write whatever you want in the vendor/.htaccess file and MediaWiki won't overwrite it, it just has to exist. @Foxtrott could you file a new issue for this? I'm not really sure about how to support this case, as we don't have anything in place yet for frontend assets (T107561: MediaWiki support for Composer equivalent for JavaScript packages).

I'll let someone else make the final decision, but I'm pretty sure the answer is going to be that your skin there needs to be fixed somehow to not have web-loaded resources in the vendor directory.

The applied patch also blocks legitimate file access, e.g. to style files, fonts, etc. See https://github.com/cmln/chameleon/issues/55

Change 391453 merged by Reedy:
[mediawiki/core@master] SECURITY: update.php: Remove eval-stdin.php if necessary

Change 391453 had a related patch set uploaded (by Reedy; owner: Legoktm):
[mediawiki/core@master] SECURITY: update.php: Remove eval-stdin.php if necessary

Change 391414 merged by Ejegg:
[mediawiki/core@fundraising/REL1_27] update.php: Remove eval-stdin.php if necessary