FYI, I fear I'm not alone (a quick search on ggl) :

• https://nooplinux.org/wiki/index.php?title=Installing
• http://bavonbeach.com/index.php?title=Main_Page
• http://pdx.wiki.org/api.php?action=query&list=allimages&aiprop=user%7Ctimestamp%7Curl&aisort=timestamp&aidir=older

...

Does includes/json/FormatJson.php actually exist for you?

Yes :

ls /var/www/wiki/w/includes/json/

returns

FormatJson.php     JsonSerializer.php           JsonUnserializer.php
JsonCodec.php      JsonUnserializable.php
JsonConstants.php  JsonUnserializableTrait.php

Are the file permissions correct?

Does its contents look sensible?

All seems good :

ls -Flask /var/www/wiki/w/includes/json

gives

 4 drwxr-xr-x  2 www-data www-data  4096 mai    6 21:54 ./
 4 drwxr-xr-x 84 www-data www-data  4096 mai    6 21:54 ../
12 -rw-r--r--  1 www-data www-data 10327 mai    6 21:54 FormatJson.php
 8 -rw-r--r--  1 www-data www-data  6117 mai    6 21:54 JsonCodec.php
 4 -rw-r--r--  1 www-data www-data  1056 mai    6 21:54 JsonConstants.php
 4 -rw-r--r--  1 www-data www-data  1439 mai    6 21:54 JsonSerializer.php
 4 -rw-r--r--  1 www-data www-data  1712 mai    6 21:54 JsonUnserializable.php
 4 -rw-r--r--  1 www-data www-data  1461 mai    6 21:54 JsonUnserializableTrait.php
 4 -rw-r--r--  1 www-data www-data  1941 mai    6 21:54 JsonUnserializer.php

I had done a chown on the whole mediawiki folder : sudo chown -R www-data:www-data *

It seems that adding an empty new line at the end of the FormatJson.php file solves the issue.

Tested by two people.

See https://www.mediawiki.org/w/index.php?title=Topic:Wv1fxboasw8fedda&topic_showPostId=wv1trny0obmjhusc&fromnotif=1#flow-post-wv1trny0obmjhusc

Maybe a closing php tag ?> would avoid the deletion a the last empty line.

I had this issue just now after pulling latest core (MediaWiki aa2ed79aa08a84867ebbf5881bf82ce1e7405221, PHP 8.1.2, no extensions enabled, and Vector the only skin), and it was also resolved by changing a file (AutoLoader.php in this case, but I'm not sure it mattered which class it was, it was just a matter of refreshing the cache).

The trace was:

[ca943ea164afd573062e393c] index.php?title=special:version Error: Class "FormatJson" not found

Backtrace: from includes/exception/MWExceptionHandler.php(777)
#0 includes/exception/MWExceptionHandler.php(316): MWExceptionHandler::logError()
#1 includes/AutoLoader.php(244): MWExceptionHandler::handleError()
#2 includes/AutoLoader.php(244): require(string)
#3 includes/cache/localisation/LocalisationCache.php(595): AutoLoader::autoload()
#4 includes/cache/localisation/LocalisationCache.php(930): LocalisationCache->readJSONFile()
#5 includes/cache/localisation/LocalisationCache.php(497): LocalisationCache->recache()
#6 includes/cache/localisation/LocalisationCache.php(371): LocalisationCache->initLanguage()
#7 includes/cache/localisation/LocalisationCache.php(312): LocalisationCache->loadItem()
#8 includes/language/Language.php(518): LocalisationCache->getItem()
#9 includes/language/Language.php(737): Language->getNamespaces()
#10 includes/language/Language.php(760): Language->getNamespaceIds()
#11 includes/title/MediaWikiTitleCodec.php(409): Language->getNsIndex()
#12 includes/Title.php(3008): MediaWikiTitleCodec->splitTitleString()
#13 includes/Title.php(432): Title->secureAndSplit()
#14 includes/Title.php(380): Title::newFromTextThrow()
#15 includes/language/LanguageConverter.php(1036): Title::newFromText()
#16 includes/MediaWiki.php(104): LanguageConverter->findVariantLink()
#17 includes/MediaWiki.php(163): MediaWiki->parseTitle()
#18 includes/MediaWiki.php(877): MediaWiki->getTitle()
#19 includes/MediaWiki.php(570): MediaWiki->main()
#20 index.php(50): MediaWiki->run()
#21 index.php(46): wfIndexMain()
#22 {main}

opcache will only read a file if its timestamp has changed, so it is possible to engineer a situation where opcache permanently has the wrong file contents, due to the file being updated without its timestamp being updated. But it's unclear to me how that could happen during a MediaWiki update. Note that FormatJson.php existed in MW 1.35 and it had the relevant class in it.

I ran tar and unzip under strace -- both will truncate the file, but they update the timestamp after the file has been written to. tar updates the timestamp before the file is closed, and doesn't call fsync(), so maybe theoretically there is a window where another process can read the empty file but with the new timestamp.

openat(AT_FDCWD, "mediawiki-1.37.2/includes/json/FormatJson.php", O_WRONLY|O_CREAT|O_EXCL|O_NOCTTY|O_NONBLOCK|O_CLOEXEC, 0664) = 4
write(4, "<?php\n/**\n * Wrapper for json_en"..., 1024) = 1024
write(4, "mpressed) for each such characte"..., 9303) = 9303
utimensat(4, NULL, [UTIME_OMIT, {tv_sec=1648761296, tv_nsec=193556800} /* 2022-04-01T08:14:56.193556800+1100 */], 0) = 0
close(4)                                = 0

But it seems like it should be a short window, and by default opcache only revalidates once every 2 seconds, so this does not explain how multiple people could see this error with the same file.

This error happened to me today, after upgrading my wiki server from Ubuntu 18.04 LTS to 22.04 LTS yesterday. This upgrade includes a change from PHP 7.4 to PHP 8.1.2-1ubuntu2.9.

The error didn't happen immediately, however. It happened a day later (with no changes made during that time). Touching includes/json/FormatJSON.php cleared it up. Bouncing memcached did not.

In T307816#8441673, @maiden_taiwan wrote:

Bouncing memcached did not.

FWIW, we wouldn't expect it to.

The problem returned on my website within 24 hours, and I hadn't made any changes on my site.

I ran sudo touch <PATH>/includes/json/FormatJson.php and the symptom disappeared.

The problem returned again just now. Any advice on how I can track down the event that's triggering the problem?

I tried clearing the opcache by (taking a guess) calling opcache_reset() in LocalSettings.php once (and then removing it). Is there a proper way to clear it in case there's bad data in it?

Otherwise I'm just going to have cron call touch <PATH>/includes/json/FormatJson.php every 60 seconds...

I upgraded from MW 1.37 to 1.39 yesterday, and I haven't seen the issue recur. Fingers crossed.

No issues since the 1.39.0 upgrade. I recommend that @FrViPofm upgrade as well.

This issue happened to me not when installing freshly but when updating, not upgrading, my instance with git. After the update, I am now on:

• MediaWiki 1.39.5 (40fed5d) 08:34, 12. Dez. 2023
• PHP 8.1.2-1ubuntu2.14 (apache2handler)
• MariaDB 10.6.12-MariaDB-0ubuntu0.22.04.1

I was on 1.39.x before and after. I find this a bit worrying, and I hope it does not return by itself, as others have observed.

EDIT: Since I also updated the server, I rebooted the system. Hmm, could this perhaps be the cause for some reason?

Regrettably, the issue is persistent. After about 2 hours, the respective wiki was down again. I will go with the cron solution for now. The problem is far more significant than expected.

Permissions and ownership of the file are fluffy:

user@server:/var/www/html/w/includes/json$ ls -l
total 40
-rw-r--r-- 1 user user 10327 Dec 13 08:24 FormatJson.php

Maybe something in this file triggers an opcache bug.

It sounds like it, but this is way out of my range of expertise to figure out and fix/harden.

Has your PHP version changed or stayed the same?

I cannot tell exactly if the bug fix version changed, but the general PHP version is and was 8.1.x. The server was set up mid November 2023 and updated when I reported the issue. The issue did not happen in the four weeks before also on PHP 8.1.x. It could be that the minor version Ubuntu 22.02. ships changed during this time.

[edit -- remove wrong comment]

I tried to reproduce this bug by following the procedure in the task description. I made a source tree with MW 1.35.14 and copied 1.37.2 over the top of it, producing a mix of 1.35 and 1.37 files. I compiled PHP 8.1.2 from source and tried to reproduce or model the error in a few different ways. But I didn't get anything particularly close to what is described.

One of the mysteries in this bug is the identity of the error raised by require(). The traces above only show the exception thrown while handling the mystery first error. Is it a file not found error or something else? If you can reproduce this, please attach to PHP with strace and capture a full strace log.