[15:55:41] Reedy: 21:36 Why specifically 1.33.4? <- because it's the next to 1.32 [15:56:36] moonmoon: 22:44 Bombo: I'd suggest going from 1.32 directly to 1.35 <- ok update.php works with 1.35.8 but there are several wiki pages missing [15:57:01] Yeah, I was going to say 1.35 too [15:57:18] In most cases, you don't need to update through every version where XX in 1.XX [15:57:19] i tried 1.38 too, pages missing too [15:57:39] Chances are if something has gone wrong, just upgrading further won't help [15:58:03] Revert to backup is probably better [15:59:46] Note that latest 1.35 version is 1.35.10 and not 1.35.8. I'm not sure why you are using an outdated 1.35 version [16:00:57] i dl'ed it when .8 was uptodate [16:01:10] 6 months ago? [16:01:16] could be [16:01:27] or i misclicked [16:01:54] i don't want to stay on 1.35 anyway ;) [16:05:27] What do you mean by pages missing anyway? [16:05:37] Hopefully you took a backup... Revert to it, then upgrade to 1.35.10 fresh is probably the best route forward [16:05:56] Upgrading to 1.35 requires running update.php, and it does several data moving between tables (comments and actors come to my mind). If the update script fails, the database may end in an inconsistent state [16:07:13] This has been problematic on several installations, when users were deleted from the database [16:07:58] so i'm now on 1.35.8, maintenance/view.php 'foo' shows "Page has no content" but: mysql> select * from text where old_id=15780; shows content (i found the id in page table) [16:08:11] i reverted like 20 times already [16:08:16] back and forth [16:08:46] i can try 1.35.10 if you think it would make a difference [16:09:02] i was on 1.38.x too but it was the same [16:10:46] when i edited that page in 1.32 it stays [16:12:13] it's the first revision of that page, i once added it with maintenance/edit.php [16:12:55] the contents of the page comes from joins to several tables. Since 1.35 they include actors and comments that are moved to other tables by the upgrade script. If the script did not run or failed to complete successfully, the data may not be there and you get "there's no text for this page" or similar error [16:18:17] Completed migration, updated 0 row(s) with 0 new actor(s), 29332 error(s) [16:18:37] thats maintenance/migrateActors.php hmm [16:19:57] before running update.php, you should try to run https://www.mediawiki.org/wiki/Manual:CleanupUsersWithNoId.php [16:20:06] 29332 is a lot of errors [16:21:14] If it doesn't clean the errors when running update.php, then you may try my modified script, that handles several corner cases: https://gist.github.com/ciencia/7cbe63b8520d4816ec36733454a2cb9a [16:22:31] ok reverting to 1.32 again [16:26:53] files are 1.35.10 now, running cleanupUsersWithNoId.php --prefix '*' [16:28:12] no errors so far, now update.php [16:29:12] Completed migration, updated 29190 row(s) with 3 new actor(s), 142 error(s) [16:29:26] Completed migration, updated 449 row(s) with 0 new actor(s), 22 error(s) [16:29:42] well less errors ;=) [16:30:09] still got some User name "Painwalker64" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation. [16:31:07] and guess what. cleanupUsersWithNoId.php won't fix the situation :) [16:31:13] oh the page isd there \o/ [16:31:18] is [16:31:55] Vulpix: your script would? [16:32:25] yes, it's more robust and creates actors as needed [16:33:57] it handled uncyclopedia, which migrated off wikia years ago with scripts that did crazy things [16:34:48] php cleanupUsersWithNoId-Vulpix.php --prefix '*' --force [16:35:18] did not clean up much just ipblocks [16:35:38] i guess i shoould use it instead of the original [16:35:44] so revert again? ;) [16:35:48] I'd use something like "bogus" prefix, but whatever fits you [16:36:26] Yes, after update.php, you can no longer run that script IIRC because update.php deletes the tables/fields holding the original data [16:37:54] I'd avoid any character outside of plain a-z characters for the prefix, just in case MediaWiki tries to do something else with them in new versions... it's supposed to be an interwiki prefix [16:42:13] Completed migration, updated 29332 row(s) with 8 new actor(s), 0 error(s) [16:42:21] situation fixed ;) [16:42:41] *checking* [16:43:26] that looks promising [16:44:00] abstractSchemaChanges> [16:44:25] thats an interwiki? i thought it would be for different languages [16:44:41] whats the use of interwiki prefixes as actors? [16:45:04] looks like everything is there \o/ thx 10^10 times Vulpix :-) [16:46:22] interwiki is a link to other wiki. Not only for multi-language wikis but also allow links to other useful wikis like a link to Wikipedia (like [[wikipedia:Some page]]) [16:47:54] mkay but what does it do with actors now? [16:47:54] In recent versions of MediaWiki, when you import pages using Special:Import, you should fill in the interwiki prefix too (where you're importing the contents from). If the source wiki is in the interwiki table, imported revisions will have their authors link to the external wiki instead of linking to inexistent users on the local wiki [16:48:49] i see lots of 'abstractSchemaChanges>Bi' in actor table now [16:49:07] prob spammers i tried to remove once [16:49:32] not listed in Special:ListUsers [16:49:43] Yeah, that's what I mean when I said it may fail if you removed users from the database :) [16:49:45] that's prob the main thing it's for [16:51:00] This may happen for imported edits too, but they were stored a bit different on the database: they had username but not user id. That is handled correctly by cleanupUsersWithNoId.php, but not when they have a user id that doesn't exist on the user table [16:53:53] ok now, can i clean them up? ;) [16:54:17] they are now in bogus [16:54:40] bogus>Hj bogus>Cn [16:54:56] NULL actor_user [16:55:12] how to get rid of them, properly [16:56:15] when there is an entry in actor table for e.g. 'bogus>Hj' does that mean that user created a page somewhere? [16:56:59] Yes, there's a revision or log entry or whatever referencing that user somewhere [16:58:00] is there a script for listing/purge these? [16:58:34] None that I'm aware of [17:46:42] https://www.mediawiki.org/wiki/Manual:Ipblocks_table [17:46:57] how does a user get into that table? [17:47:06] and out of [17:48:40] (just trying to understand the tables ... a bit) [17:49:46] By being blocked [17:52:28] ah got it Special:BlockList [17:55:12] there are the bogus actors now hehe [17:55:47] but there are spammers in watchlist too [17:56:39] 10453 | 55 | 0 | RuthanneHarrel768 | 20120525043622 | [17:56:53] wl_user=55 doesn't exist [17:57:04] long time ago lol [19:20:01] (as a general note, this is why trying to delete accounts directly from the database is strongly discouraged) [19:45:27] (i do not recall using mysql cli to del accounts ;) [19:47:05] but one of the 'accounts' in question was maintenance/edit.ph --user notarealuser [19:47:46] in revisions it's shown as bogus/notarealuser now [19:48:04] creator of many pages [19:48:23] Merging users and stuff is known to cause problems [19:49:43] well ok but what to do when 100+ spammers are registered before one could set the createaccount to false [19:49:50] just keep all of them? [19:49:52] Reedy: why does merge actually exist [19:49:54] Bombo: yes [19:50:09] Generally the best you can do is nothing [19:50:10] 1000+ ? ;) [19:50:13] Yes [19:50:19] You can mass block [19:50:28] But no need to delete the account [19:50:45] Wikipedia has millions of blocked/bad accounts [19:52:59] just because it would be too tough to clean up? i like to clean up [19:53:54] No [19:54:21] Because problems like this happen when it was never designed as core functionality [19:55:31] when it is that tough to clean up spammers, isn't there a problem with the design then? ;) [19:55:57] block the account, delete any spam, and move on shrug [19:56:14] if someone else comes along who wants a username that's taken by a blocked spammer, rename that account [19:57:57] that's what we did iirc, i don't recall messing around with the db, but its 10+ years ago i see [19:59:53] just saying, it should be easy by design to rm, i get it if i rm that user too soon, he will maybe just create it again [20:01:15] it goes against the design philosophy of MediaWiki [20:01:38] note that "deleting" pages, for example, doesn't actually delete them, it just makes them only visible to admins [20:02:19] philosophy is: keep spam and illegal content forever? [20:03:26] no, philosophy is: don't hard-delete anything [20:04:05] and with over 20 years of development following that philosophy, changing it would not by any means be easy [20:05:13] i guess it makes sense for e.g. wikipedia, to keep evidence of everything, and they probably have lots of space too ;) [20:05:42] text revisions don't take up much space [20:06:18] unless all your spammers have been posting entire novels, and you've had 10 spammers for every legitimate editor, you aren't going to save any money on space by hard-deleting spam [20:06:43] if you have file uploads enabled, those take way more space than your text database does [20:10:25] Bombo: If the volume of spam is significant compared to your entire wiki history then something is wrong, and it's not Mediawiki