Topic on Project:Support desk

Upgrade to 1.33/1.34/1.35 = missing pages

13
168.235.111.245 (talkcontribs)

Site: https://www.lurkmore.com/view/Main_page

A huge amount of articles just give me "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." after upgrading. Hit "Random page" and you'll likely end up on an article that's fine.

If you had an account and hit "Edit" while logged in, you'd see "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."

Of course, the page hasn't been deleted so there's nothing there. View "History" and you get it telling you that there are "x pages" of revisions but they will not display. I have since used pretty much every maintenance script and nothing works.

Inside the DB, broken articles and working articles are all seemingly formatted in the same way. The text exists in the DB for broken ones just as it does in working ones. The maintenance script to check for pages tells me the pages exist. They just won't show up on the wiki itself.

I can revert to 1.32 with a backed up DB just fine, but attempting to upgrade fails every time in the same way.

I will note that I'm pretty sure all of the articles that don't work were modified more recently than the ones that do work. I'm pretty sure I narrowed the broken articles down to a certain point, in that articles from before that point are all fine. Like I said, though, the article structure seems to be the same in the DB for ones that do and don't work.

Bawolff (talkcontribs)
168.235.111.245 (talkcontribs)

I already said I've run every maintenance script. It doesn't matter at what step I run them.

Jonathan3 (talkcontribs)

You said, "I have since used pretty much every maintenance script"...

Bawolff (talkcontribs)

well update.php, migrateComments.php, migrateActors.php and cleanupUsersWithNoId.php are the relavent ones. When you ran them did they run siccesfully, was error messages or warnings outputted?

168.235.111.245 (talkcontribs)

They ran and did the things they do. They added some prefixed users and completed. The affected articles have nothing to do with those user accounts.

168.235.111.245 (talkcontribs)

Dumping pages using the maintenance script does not dump the "missing" pages. I can view the text content of the pages in the database. Whatever the software does to display the pages is also the method the maintenance script is using to dump them. At this point, I'm going to have to go through the DB to get the text and "create" the missing pages one by one.

168.235.111.245 (talkcontribs)

Doing it again and ensuring it's running properly with the old DB, the revisions are there in the dump, and MediaWiki 1.35 even recognizes it, yet it refuses to import the revisions with a result along the lines of "content already exists or errors during import".

Jonathan3 (talkcontribs)

Would it be possible to install MediaWiki again, and write a script taking the latest revision of each page directly from the old database and create pages in the new wiki using the MediaWiki API?

In the past I had a malfunctioning extension that prevented the job queue from categorising any pages saved while the extension was present. I had to upgrade the extension to a non-buggy version and then run the relevant maintenance scripts. I wonder if something similar happened to you to cause your problem for the recent pages. Maybe an extension or customisation is using a function that’s been removed in MW1.33 or something like that.

Bawolff (talkcontribs)

can you check that referential integrity is correct for the pages in question (i.e. find the entry in page table, check that page_latest points to a valid rev_id in revision table. For that row, verify that rev_actor points to a valid actor_id row in actor table and rev_comment_id points to a valid row in comment table)

131.215.251.79 (talkcontribs)

Are there any fixes for this issue? I've just encountered the exact same problem.

2601:86:300:833:5B3:540D:9424:F93D (talkcontribs)

i am also seeing the same issue. i have run the maintenance scripts and the upgrade shows no error. i see that the revid seems to be somehow mis-assigned by the upgrade process. 1.32 works fine. 1.33 does not work - lot of pages show this behavior.

2601:86:300:833:5B3:540D:9424:F93D (talkcontribs)

Additional diagnostics -

  1. In 1.32, ran cleanupUsersWithNoId.php : fixed the errors by reassigning edits.
  2. In Localsettings.php, set $wgActorTableSchemaMigrationStage=SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW;
  3. Reran update.php . Wiki and all pages continue to work fine.
  4. Updated to 1.33, but get the error as described in Topic:Uvtlb8b13u3a6uw8
  5. Restore database and files to 1.32
  6. Rerun 2 and 3 but with $wgActorTableSchemaMigrationStage=SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_OLD;
  7. update to 1.33 . Get the issue described in this thread.
  8. Repeating the multiple times seems to move the error around to different pages. not sure why.
Reply to "Upgrade to 1.33/1.34/1.35 = missing pages"