Topic on Project:Support desk

Summary last edited by Tgr (WMF) 06:12, 25 January 2023 1 year ago

This is a critical bug in MediaWiki 1.39, triggered when upgrading directly from 1.32 or older. Upgrade to LTS version 1.35 first.

BaffledBuffalo (talkcontribs)

I updated our MediaWiki from 1.32 to 1.39. After the login, the following error message appears on all (previously existing) pages: This page does not contain any text at the moment. You can create it, search its title on other pages or view the related logs. Interestingly, Special:AllPages lists all articles. Is this behavior due to a faulty migration of the database? Unfortunately, I don't get any error messages showing me a possible cause of the problem (even after using the debugging toolbar). I would be very happy to receive any suggestions that would help me to solve the problem. Thanks in advance!

Bawolff (talkcontribs)
BaffledBuffalo (talkcontribs)

Thanks! Are there typically any indicators for this? Can I check this manually in the database? Regarding the cleanupUsersWithNoId.php script, I'm not sure how to choose the prefix parameter. What would --prefix '*' do exactly? A look into the script couldn't reveal that (at least for me).

Bawolff (talkcontribs)

The best way you can tell, is through looking at the database, looking at the page table, find the entry for the missing page, look at the page_latest field, find the revision table entry where the rev_id matches the page_latest, and check the rev_actor field. If rev_actor is 0 then this is the problem you have. If it isn't than the problem is something else. If you are using sql, do a query [i havent tested this query] like: SELECT * FROM page WHERE page_title = "Main_Page" and page_namespace=0 left join revision on page_latest = rev_id left join actor on rev_actor=actor_id;


The prefix option just renames users who arent real users to have that prefix.

Some people report best results using cleanupUsersWithNoId is you use it before upgrading, so if you have a backup it might be better to try it before doing the upgrade.

BaffledBuffalo (talkcontribs)

Thanks, that helped! Actually, I could see that all entries of the rev_actor column are 0. Would you still suggest to use the migrateActors.php script as a solution?

The script cleanupUsersWithNoId.php mentioned by you is also mentioned in the manual of migrateActors.php. Unfortunately, it is still not clear to me which value I should choose for the --prefix parameter. Could you please help me again with this?

Regarding migrateActors.php, the manual says that the $wgActorTableSchemaMigrationStage variable has been removed in version 1.39. According to this, I should be able to call the migrateActors.php script without any further action (after the cleanupUsersWithNoId.php has been executed successfully)?

Bawolff (talkcontribs)

Prefix parameter can be anything you want. It is used to distinguish real users from fake users.

These scripts are generally safe to run whenever, if they cant do anything they do nothing, but sometimes they are only effective in older versions.

BaffledBuffalo (talkcontribs)

Thanks! You seem to be right. The two scripts have unfortunately had no effect, as some columns seem to be missing. The output of the cleanupUsersWithNoId.php script is essentially the same as the one mentioned here.

So I suppose it probably makes the most sense to use the backup to restore to version 1.32 and update to LTS version 1.35 first. Do you think I can update directly to version 1.39 afterwards or should I update to more intermediate versions first?

Bawolff (talkcontribs)

I would do the backup, run cleanupUsersWithNoId.php on 1.32, then run migrateActors.php, and then do the upgrade. If the scripts work you can then upgrade directly, i dont think you have to go version by version.

BaffledBuffalo (talkcontribs)

Ok, I have now performed the steps as described. In the table revision, for example, the field rev_actor is now also set. However, I still get the error message "This page does not contain any text at the moment. You can create it, search its title on other pages or view the related logs" on every page. Do I possibly have to update to an older version first? Do you have any other suggestions on what else I could try?

Bawolff (talkcontribs)

Could you run the sql query:

SELECT * from page left join revision on page_latest=rev_id left join actor on rev_actor=actor_id left join comment on rev_comment_id = comment_id limit 10;

And tell me the results?

BaffledBuffalo (talkcontribs)

I've now found time to address this issue again. I've updated directly to version 1.39.1.

Since I initially forgot to run cleanupUsersWithNoId.php as well as migrateActors.php, I did so afterwards and got the following result:

> php cleanupUsersWithNoId.php --prefix iw

Skipping revision, fields rev_user and/or rev_user_text do not exist
Skipping archive, fields ar_user and/or ar_user_text do not exist
Skipping logging, fields log_user and/or log_user_text do not exist
Skipping image, fields img_user and/or img_user_text do not exist
Skipping oldimage, fields oi_user and/or oi_user_text do not exist
Skipping filearchive, fields fa_user and/or fa_user_text do not exist
Beginning cleanup of ipblocks
Completed cleanup, assigned 0 and prefixed 0 row(s)
Skipping recentchanges, fields rc_user and/or rc_user_text do not exist

Obviously I didn't notice until now that these columns seem to be missing in the tables. Presumably the problem can be traced back to this? Do you still need the output of your SQL query for a better estimation of the problem?

140.180.240.87 (talkcontribs)

Did you guys fix this? Any solution would be much appreciated!!

BaffledBuffalo (talkcontribs)

Not yet, unfortunately.

213.118.97.139 (talkcontribs)

We fixed this by updating the records from table `mw_revision` where `rev_actor` was 0. We've set the `rev_actor` to an existing `actor_id` from the `mw_actor` table

BaffledBuffalo (talkcontribs)

That's great! But how did you know which actor_id to put in the respective rev_actor?

Lsflegal (talkcontribs)

I did what user 213.118.97.139 did; worked for me as well!

To find out which actor_id you need to put into rev_actor, go to mw_actor_temp and find the row(s) with revactor_rev that matches the rev_id of your missing page(s). Then, check that row's revactor_actor value: that is the actor_id value you need to put into rev_actor.

Hope this helps!

BaffledBuffalo (talkcontribs)

I was finally able to solve the problem by first upgrading to LTS version 1.35 and then to the current version.

Thanks for all the suggestions from you guys!