Project:Support desk

Welcome to the MediaWiki Support desk. This is a place where you can ask any questions you have about installing, using or administrating the MediaWiki software.

(Read this message in a different language)

See also

• Other places to ask for help

Before you post

• Check the FAQ and Errors and symptoms .
• If your question is about a specific feature, check the relevant technical manual , end-user help or extension page and consider asking on its talk page .
• For issues about the mediawiki.org website, report to Village Pump instead.
• Ask technical questions about Wikimedia websites on meta:Tech instead.

Post a new question

1. To help us answer your questions, please indicate which version of MediaWiki you are using, as found on your wiki's Special:Version page:
2. If possible, add $wgShowExceptionDetails = true;error_reporting( -1 );ini_set( 'display_errors', 1 ); to LocalSettings.php in order to make MediaWiki show more detailed error messages.
3. Please include the web address (URL) to your wiki if possible. It's often easier for us to identify the source of the problem if we can see the error directly.
4. To start a new thread, click the box with the text "Start a new topic".

My wiki is missing a bunch of pages. I think it's specifically the pages that only had one revision. Possibly only if that revision was very old.

Here's an example page: https://www.qbwiki.com/wiki/St._Anne%27s . It says there's no text in this page, but the page, revision, and text tables all seem to have the right data.

Other observations:

• The page header has "Read", "Edit", and "View History" tabs, as opposed to a page that really doesn't exist, which only has "Create"
• Editing the page displays

The revision #0 of the page named "St. Anne's" does not exist.

This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the deletion log.

(but the deletion log doesn't show anything)

• When I try to save an edit, I am told there is an edit conflict ("Someone else has changed this page since you started editing it.")
• I can delete the page and then re-create it
• I fiddled around with the PHP code to see where the error text was coming from. It's Article.php line 436, in the fetchRevisionRecord() method:

// $this->mRevision might already be fetched by getOldIDFromRequest()
if ( !$this->mRevision ) {
	if ( !$oldid ) {
		$this->mRevision = $this->mPage->getRevision();

		if ( !$this->mRevision ) {
			wfDebug( __METHOD__ . " failed to find page data for title " .
				$this->getTitle()->getPrefixedText() . "\n" );

			// Just for sanity, output for this case is done by showMissingArticle().
			$this->fetchResult = Status::newFatal( 'noarticletext' );
			$this->applyContentOverride( $this->makeFetchErrorContent() );
			return null;
		}
	…

But I don't know enough about how MediaWiki works (or PHP in general, really) to figure out what's going wrong.

This problem likely started after an upgrade that I struggled with. Unfortunately, I didn't notice this problem until long after the upgrade, and when I finished the upgrade I had thought everything turned out okay, so I don't remember exactly what went wrong.

The upshot is that there are a bunch of pages (this was just one example) whose contents exist in the database but can't be accessed through the website. I'm not sure even how to systematically identify such pages. I suspect some rows or values are just missing from some table(s), but I have no clue which or how to find out.

Thoughts?

Do you have backups from before the upgrade?

It is most likely that either the actor or comments migration has gone wrong. MediaWiki does a LEFT JOIN on those tables so missing entries in there will cause those revisions/pages to appear as missing.

If it is about comments, see https://phabricator.wikimedia.org/T249904.

If it is about actors, I had the following trick:

1. identify the user names for those revisions
2. Create proper users for them, e.g. `User::newSystemUser( '...', [ 'steal' => true ] );`
3. Run database queries UPDATE revision SET rev_user = 0 where rev_user_name = '...'; (and similar for all affected tables, mostly logging, archive and recentchanges)
4. Run php maintenance/cleanupUsersWithNoId.php

But you need backups to do this in case the rev_user and equivalent fields are already dropped. I guess it's possible to do it afterwards by updating the rev_actor and equivalent fields too, but I have not done that myself.

I do have backups from before the upgrade, but the upgrade was about a year ago so restoring from the backup isn't viable.

Thanks for pointing me at revision_comment_temp and revision_actor_temp. It looks like the problem is the latter—this query returns 164 rows:

SELECT * FROM revision WHERE rev_id NOT IN (SELECT revactor_rev FROM revision_actor_temp)

Do you agree with that reasoning? (Some of the corresponding pages do exist, but the revisions seem to be missing when I view the history through the web interface.)

The rev_user_text column contains the username, so that should address your step 1, right? Are you able to elaborate on step 2 (how do I do that? what's the steal thing?) and 3 (which tables are affected?)? Thanks so much!

I'd suggest running `php maintenance/migrateActors.php --force` to observe if there are errors. If there is, you should get list of usernames that match the rev_user_text of those rows. You could try running cleanupUsersWithNoId.php first or maybe even findMissingActors.php (if you have it) to see if is sufficient.

But if they don't work, my step 2 basically creates and user and actor for the name. The issue may be that there is no used account for the name, so actor cannot be created. Step 3 removes broken references to user ids which do not exist, so that cleanupUsersWithNoId can process it. The relevant tables and names should be printed out by the migrateActors script.

Thanks. migrateActors produced a bunch of messages like this:

User name "X" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation.

cleanupUsersWithNoId produced a bunch of output but didn't seem to actually do anything.

I don't know how to actually do your step 2. It looks like PHP code I'm supposed to run, but I don't know how to run custom code within the MediaWiki environment.

I don't have findMissingActors.

There is shell.php and eval.php under maintenance, both allow you to run that code interactively.

Thanks. I had to fight with shell.php pretty hard to get PsySH to work, but I think everything works now, including the solution of my original problem. I appreciate your help.

I had a very similar problem and this thread was very helpful, thank you. I was able to resolve with this SQL:

INSERT INTO revision_actor_temp (revactor_rev, revactor_actor, revactor_timestamp, revactor_page) SELECT rev_id, 1 as actor, rev_timestamp, rev_page FROM revision WHERE rev_id NOT IN (SELECT revactor_rev FROM revision_actor_temp);

I was not concerned with correctly matching up the actors (and indeed think this data is lost), so replaced all of them with actor 1 (Administrator on my wiki). All of the page revisions are now accessible again. The missing actors were old now non-existent users that must have been lost in the 1.31 to 1.35 migration somewhere.

I should add I needed to run php maintenance/update.php afterwards as well.

thank you for this! the sql statement saved my wiki :-)

The SQL statement above also fixed issues on our wiki's.

The solution posted by 81.174.133.236 only works, however, on file pages the connection of the files to their pages is not reinstated. This means the files are not shown on the wiki. Reuploading with the same name is not possible either.

Note that I went from 1.25 to 1.31, to 1.32, to 1.33, 1.34 and now to 1.35. Needless to say that migrateActorswithNoId.php was useless to run. It detected the actors but did not clean them.

Going the rebuildImages.php path does not help, and neither the cleanupUsersWithNoId.php/migrateActors.php path.

I am clueless as to how to mitigate this. Looks to me like I may have run into this which I will still have to investigate. Edit: No, I do not think this is the issue.

You may try to use this version of cleanupUsersWithNoId.php for MediaWiki 1.35 that fixes other corner-cases that the original script did not fix.

Thanks for the pointer to your patched version of the script "cleanupUsersWithNoId.php." You are a hero! In the case of the current wiki I worked on, it was a lifesaver. Let me share my experience:

Going directly from MW 1.31 to MW 1.35 and applying the script on MW 1.35 after running "update.php" did not work. The wiki was in a disastrous condition after the upgrade and is no longer usable. This outcome is expected since the script had nothing to work on in the MW 1.35 database.

Going from MW 1.31 to MW 1.32, then to MW 1.33, using the patched script you linked to on 1.33 after running "update.php," did work. For some reason, the wiki was still unusable in version MW 1.33; however, upgrading to MW 1.34 with "update.php" and from there to MW 1.35 with "update.php" mitigated the issues emerging on the wiki. As a result, the wiki is working fine as it appears to me (still pending user feedback). This way, I could prevent massive issues, including this one, from occurring if I used core software. I am still determining why the wiki is broken in version 1.33, but it is probably another story.

Directly going from MW 1.31 to MW 1.35 is not recommended for wikis, with issues surfacing after the upgrade. Do it branch by branch and apply the patched script to MW 1.33. Going from MW 1.31 via MW 1.32, MW 1.33, and MW 1.34 to MW 1.35 using the script "cleanupUsersWithNoId.php" provided by core will also not work. The result will be a disaster. On the way, "update.php" will complain for MW 1.33 to MW 1.35 that you need to run "cleanupUsersWithNoId.php," however, it will ultimately do nothing.

Hi, I would like to share my experience here since I've been struggling with updating my MW from 1.31 onwards. Originally, I wanted to go from MW 1.31 to 1.32 and then 1.33 some time ago. As 1.33 broke my wiki due to the known actor nightmare (cleanupUsersWithNoId.php does not help), I decided to postpone the update.

Now, I gave everything another shot and followed the instructions posted by @Kghbln.

1) MW 1.31 to MW 1.32 using update.php

2) MW 1.32 to MW 1.33 using the enhanced version of cleanupUsersWithNoId.php by @Ciencia Al Poder first and only then executing update.php

3) MW 1.33 to MW 1.34 using update.php

4) MW 1.34 to MW 1.35 using update.php

Afterwards, my wiki was working fine on MW 1.35. As 1.39 is already out, I decided to continue the update process. To be on the safe side, I performed the update for each version separately (1.36 -> 1.37 -> 1.38 -> 1.39). Everything works fine now under PHP 7.4, my next step is going to push the PHP version to 8.1 but that's not related to this issue.

Btw, the query posted by 81.174.133.236 was not necessary as the enhanced script took care of everything.

Another issue I had facing this update was the removal of Manual:$wgDBmysql5. My database was still using latin1 collations and everything was working fine with $wgDBmysql5 = true; until this setting was removed in MW 1.33. Therefore, I had to adjust my DB accordingly to avoid encoding issues with special characters (some hints are given on the talk page of the setting, also see Topic:Wqktznc6b8nyc29g).

I really would like to thank @Ciencia Al Poder and @Kghbln and everyone involved for sharing the script and their paths for the update!

No! I recommend wait to next stable version MW, because upgrade scipt must accept upgrade from PHP 7.x to 8.2 and some distributions as Debian for example, 8.0 and 8.1 skiped. But MW 1.42 with support PHP 8.2 not released. I know that is complication, but another choice isn't for now.

Say, I appear to have this issue in my wiki. However, I'm unable to use the above solution as my wiki has already been upgraded a few times (currently on 1.41), and I don't think I have access to the older versions anymore.

migrateActors.php --force shows 0 errors currently.

I also note that if I look at the history of a problematic page, I can see, for example, three users with edits. All appear in the list of users, and have other unaffected pages.

Any suggestions on how I might dig myself out of this?

Did you try to run the above SQL statement? That worked for us.

Yes, it errors out as there is no "revision_actor_temp"

There's no fix once your wiki database has been upgraded to later versions. The information of those old users is gone. Forever. There are only actor ids now. You'll have to manually select those actor ids and replace them by whatever other actor id that may be the best replacement for them.

Hmm, well, unfortunately I'm not even sure how to find the old actor IDs. Currently despite being able to see old revisions, I can't find the page in the database, but I may be not searching correctly. I'm certainly no expert on how the database is structured.

OK, so I think I have a better idea how to fix things now.

I did some reading up on the mediawiki manual that describes the structure of the database. It now made sense that I didn't have a "revision_actor_temp", as that was only around v1.3.1 – v1.3.8, and I've already upgraded past that.

I have been able to identify a few problem pages just by coming across them browsing my wiki. I'm using phpMyAdmn tool at part of the cPanel set up for my instance. Selecting my database and searching for an exmaple page title let me find the page record, and in that, find the page ID number.

The, searching the revision field only (by selecting it and using the search tool), I was able to search for all revision entries for that page ID number. The very last/latest revision had an rev_actor ID of "0". When I had been looking at the list of revisions in the wiki, it shows them up to that point.

After backing up my database (in case I mess things up), I edited the rev_actor ID for that one revision from "0" to "1" (the ID of the main admin account). Now that revision appears with the name of the main admin account as having done the revision, and the page appears normally in the wiki.

Now I certainly can just have folks report when they run into one of these pages, and fix them as I come across them. However, my question is: Is there a legitimate use of the rev_actor ID being "0", or is that most assuredly an indication of a problem with the page? I could easily find/replace them, but I see about 2.5K entries that have a rev_actor ID of "0" currently.

I just upgraded to MediaWiki 1.42.1 and now I get a RuntimeException on any content page.

The error message is as follows:

[Zo7mSqEjpbLgQB5NVrqDPwAAAgg] /wiki/index.php?title=Main_Page RuntimeException: Could not open '/home/brassgog/tmp_a5xawf/mw-GlobalIdGenerator1087-UUID-128'.

There is also a backtrace, but the spam filter won't allow me to post it.

My wiki is at https://brassgoggles.net/wiki/ Short of nuking it from orbit, how can I fix this?

Try just deleting the file /home/brassgog/tmp_a5xawf/mw-GlobalIdGenerator1087-UUID-128 . Sometimes this file gets created with wrong permissions if you run maintenance script as wrong user,but its safe to delete and that usually fixes it.

That file already doesn't exist. There is no directory /home/brassgog/tmp_a5xawf .

Is $wgTmpDirectory pointing somewhere writable by whatever user mediawiki is running as?

Hello,

I have upgraded to MediaWiki 1.39.7 with the following components:

Product	Version
MediaWiki	1.39.7
PHP	7.4.33 (apache2handler)
MariaDB	10.5.25-MariaDB
ICU	74.2

I have been getting errors from the web browser such as "The connection was reset" when I try to edit and save pages with somewhat long titles (about 30 characters). Note that the titles are in the Greek alphabet, so I do not know if this plays a role regarding the size of character encoding. From what I read online, the maximum size for a page title is 255 bytes.

Also sometimes when saving is successful, I get lines of the form "<<<<<<< /private/var/tmp/merge-old-6jssyq" incorporated into the page's contents.

Note that I did not have problems of this sort with older versions of MediaWiki (or MySQL). I also do not have any problems with pages that have shorter page titles.

Any help on the matter is appreciated.

Thank you in advance.

> I get lines of the form "<<<<<<< /private/var/tmp/merge-old-6jssyq" incorporated into the page's contents

This sounds like you have a git merge conflict in a file of your mediawiki installation.

Thank you @TheDJ

Could you explain how git is involved in this error please? Aren't characters "<<<<<<<<" and ">>>>>>>>" used more widely and not only in git?

Btw, this type of lines appears in the source of a wiki page, when I am editing a section of the page.

merge-old is what was triggering me. That is the prefix for the filenames that git uses when encountering two conflicting versions.

Greek characters are 2 bytes each. 30 character greek title = 60 bytes. So its probably not a length issue.

It could also be something going wrong with edit conflict merging which also uses diff3 (and uses the merge-old-xxxxx convention), but i've never heard that happening before. See also manual:$wgDiff3

Can you check your php error log.

Thank you. I checked /var/log/apache2/error.log

and I get

[Thu Jul 11 08:52:19.418457 2024] [core:notice] [pid 137] AH00052: child pid 21546 exit signal Segmentation fault (11)

[Thu Jul 11 08:52:19.418818 2024] [core:notice] [pid 137] AH00052: child pid 21052 exit signal Segmentation fault (11)

Also I have the following values in LocalSettings.php

## Shared memory settings

$wgMainCacheType    = CACHE_NONE;

$wgMemCachedServers = array();

Thank you in advance.

Debugging php segfaults can be pretty difficult if you arent familiar with php internals. Normally i suggest updating your version of php to see if that helps.

Thank you. Shall I update to PHP 8.1?

What is the distribution on the server? Or do you operate in a container?

Hi. By "distribution" do you mean the current version of PHP? If yes, it is on the first message in the thread (7.4.33 (apache2handler)). I am running the wiki locally (MacOS).

Ok. If MasOS used, probably is created any container. It is possible that something is missing from it.

https://kb.opclabs.com/Special:Version is MediaWiki, which I upgraded from MW 1.35 before month

Its worth a shot.

Hello,

I wanted to analyze data about edits on Wikipedia, so I downloaded the data dump with full history. But going through the xml, I managed to find all the revisions, edits and their comments, but tags assigned to the edits are nowhere to be found. Where are they in the dump or do I have to get them somewhere separately?

There is a separate file called change_tag.sql.gz with this information that you can download from the dump site.

I have upgraded my mediwiki from 1.24 to 1.35. but now my DB connection didn#t work.

When I do the online upgarde everythink looks ok.

=> Upgrade complete.

You can now start using your wiki.

And than: #0 /usr/www/users/tjifyn/wiki_1.35.14/includes/libs/rdbms/loadbalancer/LoadBalancer.php(937): Wikimedia\Rdbms\LoadBalancer->reportConnectionError()

and so on ...

I can connect with CLI to my DB:

tjifyn@dedi4039:~$ mysql -u i**** -p i*****

Enter password:

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Welcome to the MariaDB monitor.  Commands end with ; or \g.

Your MariaDB connection id is 31790822

Server version: 10.5.23-MariaDB-0+deb11u1 Debian

my LocalSettings.php

$wgDBtype           = "mysql";

$wgDBserver         = "dedi4039.your-server.de";

$wgDBname           = "i**********";

$wgDBuser           = "i*********";

$wgDBpassword       = "a***********";

# $wgDBport           = "3306";

$wgDBprefix         = "";

thx 4 your help!

Does it help if you change $wgDBserver to "localhost" ? Possibly it is the difference between tcp connection vs unix domain socket connection.

MediaWiki can't load. Whenever I check it out, I can't even access it at all. My terminal can't load either. Please help me now. My hosting and domain provider is Namecheap.

https://dre.luagunsx.xyz

I worked so hard on this. Just for it to get destroyed. WHOEVER IS THERE, HELP ME NOW.

You haven't provided enough information for anyone to help you.

I recently updated from mediawiki 1.34.2 to 1.40 (through 1.35).

Also I updated from ubuntu 18.04 to 20.04, php and MySQL.

Since then mysql binlogs started to take a lot of disk space.

The logs from the last 7 days took 109GB.

How do I check what made it so large?

Thanks.

That sounds like a good question for a MySQL or MariaDB forum?

We have upgraded from MW 1.35 to 1.39 and now the logs are full of php deprecation warnings.

LocalSettings:

$wgDevelopmentWarnings=false

$wgShowDebug=false

php.ini:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

nonetheless we have thousands of log messages about Parser::$mShowToc was deprecated, $wgAllowImageTag to true is deprecated, InternalParseBeforeSanitize hook was deprecated

and so on. Log files are not readable anymore. How can I suppress that?

Those are not "PHP deprecation warnings" but MediaWiki deprecation warnings. You can fix them by fixing/updating whatever custom or third-party code triggers them so log files become readable again.

Those are MediaWiki deprecation warnings, great, so please, fix it. I can't, for because i am user, not developer. Example:

PHP Deprecated:  Use of Parser::$mShowToc was deprecated in MediaWiki 1.35. [Called from efMWNoTOC in /var/www/prod/mediawiki/extensions/NoTOC/NoTOC.php at line 42] in /var/www/prod/mediawiki/includes/debug/MWDebug.php on line 381
PHP Deprecated:  Use of InternalParseBeforeSanitize hook (used in VariablesHooks::onInternalParseBeforeSanitize) was deprecated in MediaWiki 1.35. [Called from MediaWiki\HookContainer\HookContainer::run in /var/www/prod/mediawiki/includes/HookContainer/HookContainer.php at line 137] in /var/www/prod/mediawiki/includes/debug/MWDebug.php on line 381
PHP Deprecated:  Setting $wgAllowImageTag to true is deprecated since MediaWiki 1.35 in /var/www/prod/mediawiki/includes/debug/MWDebug.php on line 381

This happens when importing a page. As far as i can read it, it is from MWDebug, but i don't do any debugging. Remember, $wgShowDebug=false

So again my question, if i dont want debug messages why does MW log debug messages? It worked in 1.35 without logging and now in 1.39 someone has changed it. This is insane.

Regarding the first warning: The "NoTOC" extension (which is not part of default MediaWiki so you likely installed it at some point) is unmaintained software so I'd recommend uninstall it if you don't plan to fix its code locally. Sorry, no idea about the rest. (PS: See also Inclusive language about the last word in the previous comment - thanks.)

You're right. Insane is inappropriate and rude. I apologize. Let me summarize:

• no debug/deprecation/warning messages in 1.35
• no configuration settings changed
• lots of debug/deprecation/warning messages in 1.39
• no support, instead: "go and fix it yourself"

How would anyone else call that?

I am upset. Someone decides "I'll show you warnings even if you set your parameters not to report them". If the notoc extension is unmaintained, why does anyone care about a setting that no one else uses? For me it's clear, bottom line of 8 yrs Mediawiki: like any other closed circle of developers, you guys are sitting in a spaceship drifting away to outer space. Lost contact to ground control, who cares what users want. Yes i know "we're all volunteers", but believe me though i can't create phab tasks i have read enough of them telling me "it's not a bug, it's a feature". Very disappointing. Only reason why we stick to Mediawiki is: there is no alternative. It is always a pleasure to work with you.

I found Manual:$wgDeprecationReleaseLimit. It sounds like you guy may want to enable it. No idea why this made you guy think of spaceships though (I am sitting two kilometres below surface in the secret MediaWiki HQ command center instead), and pointing out that you guy assume I'm in some "closed circle of developers" kabal motivated me to continue providing unpaid free support to you guy in my spare time in this thread, to the best of my very little knowledge (maybe I should have not replied at all if radio silence is considered better free support?). In any case, if MediaWiki does not serve your needs and lacks "what users want", you are eligible to request a refund.

Could someone please give me VideoCutTool Gitlab repo link?

https://gitlab.wikimedia.org/cloudvps-repos/videocuttool/VideoCutTool

I was trying to sign in Wikimedia's GitLab, it throwed me this error :

Your account is pending approval from your GitLab administrator and hence blocked. Please contact your GitLab administrator if you think this is an error.

@AnujAgrawal380 Can you please file a request in Phabricator using this form, You can log into Phabricator with your Wikimedia SUL account (aka your login on this wiki).

I already have a sperate LDAP account logged in phabricator. Can i fill the from with it?

@AnujAgrawal380 Yes, you can use whatever account you are already using to sign into phabricator.

See Phabricator/Help linked from the Phabricator frontpage.

I linked my LDAP account with MediaWiki account in phabricator and also filled the form still i didn't got access to gitlab.

https://phabricator.wikimedia.org/T369807

Please read the second banner on GitLab again.

I've got a wiki on my workstation (localhost) and had to upgrade PHP to 8.2 (which in turn meant I had to switch to a different Apache build) for a different application to work, which in turn meant I had to upgrade MW to 1.39 from 1.28. I used the old LocalSettings and edited it according to what the errors complained about.

The upgrade resulted in a plethora of errors while running the update scripts, namely missing fields and tables, which I manually added after looking up what they're supposed to look like. After a lot of fiddling I finally got the wiki to load, but it's not happy. I have no idea if I'm still missing any tables and/or fields since it doesn't tell me. I enabled all the extensions in PHP it demanded and was able to fix the user table so I can log in, but beyond that I can't figure out why it doesn't work.

None of the articles will load and I simply get

Error: There is currently no text in this page. You can search for this page title in other pages, [ search the related logs], or [ create this page].

This goes for ALL articles and category pages, with no exception, including image file pages. Through Special:AllPages it will list all articles in the wiki, but it gives the same error no matter which one I try to read. All categories are also still listed, and the category pages show subcategory and article listing, but again an error for the body. It also fails to show what category any page is in.

When I attempt to edit any page it goes

The revision #0 of the page named "Main Page" does not exist.

This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the [ deletion log].

It also fails to load the "toolbar" on the edit page, but then that may be an extra extension I can't recall the name of.

Another thing is that 1.39 doesn't seem to function correctly on localhost, and I can't tell if this is what causes it to not load correctly. That is, my wiki is called "P32" and it does load correctly, but when it does redirects, like after logging in, it will point to www.P32.com which doesn't exist, and thus I get more errors, and I can't figure out what causes that or how to stop it. Never had any issues with that in previous versions.

Tech part in short:

MW 1.39.1

PHP 8.2.1

Apache 2.4.55 (Win64)

MySQL 8.2.1 Community Server

all running locally on Windows 10

There's no internet access or domain for this machine (meaning the httpd is not reachable from outside my LAN)

For the first part. What you describe sounds like referential integrity issues, particularly with the actor migration.

A lot of people have luck by first upgrading to 1.32. Then running cleanupUsersWithNoId.php and migrateActors.php. Followed by updating the rest of the way

> Another thing is that 1.39 doesn't seem to function correctly on localhost, and I can't tell if this is what causes it to not load correctly. That is, my wiki is called "P32" and it does load correctly, but when it does redirects, like after logging in, it will point to www.P32.com which doesn't exist, and thus I get more errors, and I can't figure out what causes that or how to stop it. Never had any issues with that in previous versions.

What is $wgServer set to in LocalSettings.php ?

I guess I need to download 1.32 first and see if it'll fix things.

EDIT: This has turned out to be a bigger challenge than I thought. The 1.32 scripts are spitting out fatal PHP errors despite downgrading PHP to 7.4 so I've gotten no further.

As for the settings:

$wgServer           = "/localhost/P32/";

$wgServerName       = "P32";

$wgSitename         = "P32";

It's not clear in the documentation if it needs all three and it's obviously not designed to run without a domain, so this is what I came up with after some trial and error

$wgServer needs to have a protocol and host only. So it can be 'http://localhost' or '//localhost' or 'https://localhost' it cannot have a path. The path part of the url comes from $wgScriptPath and (optionally) $wgArticlePath.

$wgServerName should not be set (It is detected automatically), and that is also the wrong value for it.

Instead of 1.32, use 1.35, which may have some bugs fixed for the migration. However, if you've upgraded your database already, you may have lost data already. See phab:T326071. There's no way to downgrade the database. Preferably you should restore from backup.

Got the 1.32 update scripts to work by disabling some error checks PHP disagreed with in versionchecker.php (assume because I couldn't find the correct PHP version for that MW). Then I did the whole thing again with 1.35, and then again with 1.39. Used the --force option on update.php in the hope it'd rebuild all the references.

Unfortunately it hasn't solved the problem. I have checked that everything is still there in the page and text tables, so the primary content isn't lost per se, and all the category and file tables are intact (or at least have their content) as well. I assume that means it's a matter of lost/missing references somewhere, only I don't know enough about how MW uses the enormous amount of tables to tell what's missing or wrong.

this is similar to a few other support requests on here and more and more appears to be quite an enormous problem for many legacy wikis in the way mediwiki handled the upgrades. It's just really not understandable how these upgrade scripts seem to have not worked in certain version bumps and once you're past some version and unable to restore to some earlier point (which is quite impossible for active wikis) then these reference tables are somehow "lost" forever. What this needs is a fix that would restore certain references, maybe by re-inserting mock revion 0s so these pages are accessible and editable again...

Been reading through the manual about the structure of the primary tables and believe I've found why my wiki is broken:

Page.page_latest has matching entries in Revision.rev_id, and Revision.rev_page correctly points back to Page.page_id, but...

Revisions.rev_text_id is not present, and was likely removed by the update scripts since it was apparently discontinued with 1.32 as part of the MCR project, and the manual states it was replaced by content.content_address which references the latest revision tracked by the slots table, and that is where it breaks.

The content and slots tables only have 71 rows (which appear to match) while there are 7689 rows in the page table and over 25000 rows in the text table. Meanwhile the revision table has roughly the same amount of rows as the text table. This means the content of the revision.rev_text_id was not correctly converted into the slot and content tables before the field was removed.

Another problem is that slots.slot_revision_id is supposed to match revision.rev_id, but for every single one of the 71 rows in slots table the rev_id has no matching entry in the revision table.

As there is no back reference from the text table to any of the other tables, and the rev_text_id field is missing, there does not appear to be any way to rebuild the wiki database from this state.

Unfortunately I messed up and didn't back up the database before I started upgrading, so I don't have a recent dump with the revision table intact, and thus the only way for me to rebuild is to make a new DB for the wiki, pull the blobs from the old, and paste them into the wiki. Only without a proper reference from the revision table there's no way to tell which entries in the text table is the latest revision.

I will say that if the update script is going to completely delete parts of the database it absolutely must verify that all the data of those fields is copied correctly before deleting them. The fact the row count of the new tables don't match the one they're meant to replace is pretty damn bad when it's the only reference to the actual content. I understand that we're trying to avoid duplicating data throughout the database, but if the text table had a back reference to the revision table we'd be able to rebuild most of the database from that one table.

yeah this all appears to be a major clusterf***, luckily in my case so far I seem to have (anecdotal) incidents in the lower double digits of pages/files that are actually causing trouble, so if I knew how to approach it, I could even fix some things manually, but you must be going insane with the entire database affected like this.... in my case I noticed way too late that there was a problem in the first place - precisely because just a handful of content pages are affected so it took me a while to stumble across these and noticed there was a corruption in the database dating back to who knows which update over the last 10 years....

If every single page is broken, that's probably T326071. Sorry :( You will have to restore the old wiki from a dump, and then either wait for 1.39.2 to be released, or upgrade to 1.35 and from there to 1.39.

If only a few pages are broken, that's probably a different issue.

I didn't check the actor field, but there is part in the MW manual (forgot exactly where, but on one of the pages about the content, slots, or revision tables) where it states something like "if this reference is invalid you'll see 'Error..." and lists the exact error I got.

Either way that database is utterly hosed. As I said before, I screwed up and don't have a recent backup because I forgot to do it before running the update (note to self: figure out how to automate the dumps), so the only backup I got is 3 years old and missing a good chunk of the content because much of what is in the wiki was imported from other sources during covid lockdown. This is entirely on me, but luckily this is not an online wiki - I mostly use it for documentation, prototype articles, and keeping track of various stuff.

So, anyway, I stuck with 1.39 and let it build a new database. And then I'm stuck with the arduous task of manually recreating all the content. To do this I've thrown together a PHP script that pulls the blobs from the old text table so I can paste them into the new database. This is a slow process, but I can't see any way of automating it in a meaningful way

I would still be interested in knowing how this could be "fixed" somewhat if it really just concerns a very low number of pages. In my case I think (I can't say for sure) only about 20 or so pages may be affected (pages and files, mostly files though). I would love a step by step guide as to 1) how to sure-fire identify all the pages/tables impacted 2) locate what is missing and 3) how to fill up the actors/rev ID with something bogus in a way that even though it might be hackish, it would allow me to access this content again and possibly delete them from the wiki interface or overwrite them with a newer revision etc. One of the reasons I noticed these things in the first place was upgrades to 1.39 making half the website unusable. But just like SteelRodent, I don't have any backups that are pre-1.35 and with current content at the same time. I am somewhere stuck at 1.38 nomansland with a partially corrupt database...

It's hard to provide a guide for DB corruption because the DB can get corrupted in an infinite number of ways. You might be able to use findMissingActors.php --field rev_actor --overwrite-with 'Unknown user' to reassign missing users. I don't know if there is anything similar for revisions.

When it comes to automatically restoring the revisions, I really don't see how it can be done in a meaningful way once you lose all references to the text table and that table doesn't refer to anything else. The problem is once the reference to the text table is lost there's nothing to identify which row in that table belongs to what article and thus that entire table is effectively orphaned. The files are indexed in a different table and at least in my case that seemed to be working fine, but then revisions for files are done in a completely different way.

The revision table is apparently the only one that refers to the title of pages, so it would require a very intelligent parser to read through the text table and figure out what goes where, and I've never seen a wiki where every article contains the title in the body in a consistent format. The alternative I can see is to create all new dummy entries for every entry in the text table (and let's not forget that not everything in a wiki has a body), but then - depending on the wiki in question - you'll end up with potentially thousands of redundant articles that you'll then have to identify, move, delete, and so on, and then you're effectively back to doing the whole thing manually anyway, which makes it much faster to just manually restore it to begin with.

Since revision ids and text ids are incremental, you may be able to guess the text id from a revision id by sorting both and assigning them in order. There are several causes for text ids not matching, those are the ones that come to my mind:

• Some extensions, like AbuseFilter, insert text records for their filters and other data, which may add more text ids without creating revision ids.
• When reverting edits, I think MediaWiki reuses the same text ID of the original revision being reverted to for the new revision.

You may do an initial assignment, and then see how it generally looks. If you see revisions with text that doesn't belong to the page, try again from the revision where it starts to differ, by adding some offset, and so on.

For the abusefilter records, you may get those text ids from the abuse filter tables and discard them directly. You'll have to dig yourself on which tables are they stored, though.

SteelRodent, good point. However, if I could move, delete, and so on, that would already be a huge progress. At the moment, I can't, because that throws errors. I'd rather have some bogus content in the wiki that I can then move, delete, edit, etc, than have corrupted content that can't be used or fixed on an editorial level....

You can probably reconnect text entries with revisions by recomputing the sha1 hash, as long as the DB got corrupted in such a way that the sha1 is still present. Filed T328169 about that.

First of all happy new year. What are the chances of https://phabricator.wikimedia.org/T328169 becoming reality?

Not too much unfortunately, most developers tend to focus on tasks that are relevant for Wikipedia & co, and this one isn't. Maybe if you can produce a sample of exactly how your DB is corrupted, someone can suggest a query or snippet for fixing it. (Also do you want to recover the data? Or just get rid of the affected pages? Deleting them from the page table and deleting relevant revisions from the revision table should accomplish that.)

Thanks for the reply. The second option may also work for me, unless I discover loads more pages affected. It would be great (for clueless non-IT guys like me) to have a thorough guide as to 1) how to precisely detect all affected content in the database 2) how and where to delete without doing additional damage and 3) how to identify the files and thumbs from the file system if it's about files (in my case some are files)

Same thing happened to me and I went from 1.35.14 to 1.39.8. I was thinking I was following exactly what docs suggested, but still I ended with no articles in my wiki. Damn.