D'oh, I sometimes miss posts here too.
A migration would be great! I think it would not even be much of a loss if people would have to re-register. Anything that makes it functional and maintainable again.
I give up. This has taken too many precious hours already and it is absolutely zero fun to me. MediaWiki has been nothing but unpleasant and a PITA with broken upgrade processes, bad documentation and unhelpful error messages, leaving me ******* frustrated.
Anyone who has got time and motivation to invest some time into this this year and go alone on it? Otherwise I will turn the site into a static archive at the end of the year.
Recent attempts:
Attempt with mariadb
@nitoducci thankfully sent me a SQL dump of the data for MariaDB but even with that and a current version of MediaWiki I got errors. It looks like the database is corrupted?
There was no content but just Error There is currently no text in this page. on some pages. Their histories were working though, both the first and latest revisions loaded fine if loaded directly. Editing did not work because it always said that a blank edit happened during my editing session so that was no way to restore everything.
I tried php maintenance/run.php AttachLatest --regenerate-all --fix and it said Done! Processed 1009 pages. but also spammed countless lines of Warning: Invalid JSON object in comment: [Called from MediaWiki\CommentStore\CommentStore::getCommentInternal .... The sites still did not load.
Googling around was not really helpful. I tried to run php maintenance/run.php migrateActors but just got Error: Undefined constant "DB_MASTER". Running https://www.mediawiki.org/wiki/Manual:FindAnomalies.php gave Error: Undefined constant "DB_SLAVE".
Attempt with XML dump into a new MediaWiki installation
So I made a data dump, installed a fresh MediaWiki 1.44, gave it a mariadb, and tried to import the dump. No chance: Error: Call to a member function getId() on null from from /srv/quakewiki/w/includes/Revision/RevisionStore.php(1850).
So I guess there is something broken with the database integrity and which requires manual fixing. I am sorry but I am not going to go into this.
Is there a dump of the data somewhere that we can use to try the fix locally?
Good idea! Here is a dump of php maintenance/run.php dumpBackup.php --full --include-files --uploads: https://quakewiki.org/static/quakewiki.org_20251101_page-and-filedump.xml.xz
hi! i understand your frustration 
i get it if you’re going to run a static archive, seems like the easier choice.
since i was able to successfully run a fresh mediawiki with the dump i created, i’m willing to run a mediawiki instance if you want me to continue with quakewiki. alternatively, i’m available to connect to quakewiki’s machine and try to get it running on your server.
edit: i’ll try bringing up a quakewiki instance on my server as a proof of concept
1 Like
Yay, @nitoducci will give it a try 
Thank you!
1 Like
i had a quick look around and the database is 29 mb… honestly sqlite is fine. there’s no need for mariadb or postgres.
both search and editing already seem to work:
- search: https://quakewiki.org/w/index.php?search=mlook&title=Special%3ASearch&profile=default&fulltext=1 the custom search widget on the sidebar is broken, but search itself is working fine.
- editing: https://quakewiki.org/wiki/Test_test
other people have already been using the page, seemingly with no issues: https://quakewiki.org/wiki/Special:Log
there’s some openssl errors (lighttpd issue?) but there isn’t anything wrong with php or sqlite according to the error log.
i’m not sure what needs fixing in the database 
any schema issues would pop up on the error log (or the page itself) when doing, well, anything.
i’m confused, @Spirit , everything looks good?
Oops, well it's been a year of looking at it every once in a while so my memory is foggy. 
IIRC the issue with SQLite was not the size or performance, but that some upgrade did not work and the answer was "well, SQLite isn't really a fully supported target for mediawiki". So it would just be a matter of time until it would break again.
Maybe @efess remembers more?
Currently it is not possible to login (I dropped the passwords on purpose at some point) as one does not get any mail. Different issue but if you have more mediawiki knowledge, maybe you can find out where mails get stuck? I looked at debug.log earlier and found nothing. Mail is sent via external SMTP, see LocalSettings.php.
And that search thing definitely worked at some point in the past
That's exactly it, the upgrade process for sqlite is an afterthought by mediawiki and has to be maintained separately from their mariadb upgrade scripts, which causes a bunch of issues that are never addressed since the adoption of sqlite is low.
I do agree sqlite is a fine engine to use, if only the upgrade scripts were reliable.
1 Like
i’ve done some things:
- upgraded to mediawiki 1.43.5 LTS (released about 28 days ago, supported until december 2027)
- updated the Cite and ParserFunctions extensions, compatible with the new 1.25+ extension loading registry
- i had to remove CookieWarning temporarily
- ran all pending jobs and changed job run rate to 0.5 (so, run 1 job every 2 requests)
- hastily fixed search
i’ve currently disabled (not deleted) additional skins (CologneBlue, Modern, MonoBook) because they have issues with the site’s custom style.
things left to do, low priority imo:
- figure out what’s wrong with Extension:CookieWarning
- fix the hardcoded css, it was made for Monaco and breaks the other skins
- check why lighttpd throws ssl errors randomly. maybe switch to nginx?
basic stuff works (edit, diffs, move, redirects, watchlist, search, protections). account creation works, including email confirmation and password recovery. the server is properly sending emails.
we’re good!
4 Likes
i gave myself administrator to delete spam and discovered that deletion is not possible on a few very specific articles.
the database has inconsistencies in the “archive”, “page” and “revision” tables after 2025-03-29 (botched upgrade?), so there are pages that cannot be edited, moved, protected or deleted:
rev_id|page_id|timestamp|Namespace:Title
4983|4|20250329191233|0:Singleplayer_maps
4989|5|20250912153447|0:Quake
4988|16|20250728083149|0:Gameplay_tips
4986|17|20250702054937|0:Mapping_tools
4985|69|20250607121300|0:Engine_getting_started
4982|137|20250321133512|0:Rotfish
4979|140|20250318214207|0:Ogre
4981|140|20250319103747|0:Ogre
4978|142|20250318131731|0:Fiend
4980|428|20250319103624|0:Spawn_(monster)
5010|475|20251110180549|0:Getting_Started
4997|686|20251023151650|0:e2m2
4984|1154|20250512172533|0:Quake_Soundtrack
4990|1178|20251007182801|0:CSQC_guide_for_idiots
4991|1209|20251010141313|0:FTEQW_File_Formats
4992|1209|20251010143707|0:FTEQW_File_Formats
4993|1209|20251010145228|0:FTEQW_File_Formats
4994|1209|20251010145338|0:FTEQW_File_Formats
4995|1209|20251010145810|0:FTEQW_File_Formats
4996|1209|20251012231244|0:FTEQW_File_Formats
4987|1375|20250725202823|0:Creating_A_Monster
4998|1435|20251101213451|0:Test_test_2
4999|1435|20251105200918|0:Test_test_2
5000|1435|20251105201535|0:Test_test_2
5001|1436|20251105201535|0:Test_test
5002|1437|20251106063525|0:A_Local_Guide_To_HVAC_Solutions_In_Coral_Springs
5003|1438|20251107194557|0:AnyDesk的核心技术优势
5004|1439|20251107200752|2:MarcelY6144
5005|1440|20251107220206|2:AZQNickolas
5006|1441|20251107220220|0:AnyDesk加密技术：保障远程桌面安全端到端加密解析
5007|1442|20251110022129|0:如何轻松掌握AnyDesk新手教程？
5008|1443|20251110034122|0:AnyDesk中文版下载电脑版教程：高效远程协作指南
i’m going to try manually fixing the database, but i can’t guarantee it’ll work.
this might just be the best choice, but i’m not sure if page history is preserved. the current wiki goes back to september 2009 and i wouldn’t want to lose 16 years of edits.
edit: i couldn’t fix the db, idk whats happening https://quakewiki.org/wiki/Test_test_2 look at this mess
Awesome, thanks so much!
That list of articles has quite a bit of new spam in it. Iirc we had a few Quake specific questions that managed to filter spam very effectively.
I don't remember right now if March was an attempt in fixing the site, might be. In the worst case, it should be ok to drop any new edits from this year and hope that people recreate them. Maybe saving the currently visible revisions in the recent changes list?
edit: i couldn’t fix the db, idk whats happening https://quakewiki.org/wiki/Test_test_2 look at this mess
The old revisions look ok to me, the new one is full of spam. What do you see and what should we see instead?
actually, i've successfully moved the database to mysql on one of my servers but it took literal hours to import. the script dropped and re-created all of the relations in the db, so all of the internal IDs are different, but all of the revisions, edit messages, revisions, page history, file descriptions and timestamps are preserved.
unfortunately i'm too busy to keep working on that, but i'll have a look at it maybe next month. i'm a bit stressed rn.
the nine inch nails question is still around afaik. i think the site would benefit from only allowing edits from registered users, since that requires a working email and answering those quake-specific questions.
the proper text that “Test test 2” should have is “test 2”, since that’s what i wrote in id 4999 https://quakewiki.org/w/index.php?title=Test_test_2&oldid=4999 but the database is mistakenly mixing around revisions of different pages. thus, the edit to one of those chinese spam pages ended up in “Test test 2”.
this suggests that there’s something wrong with the database, probably with the table’s internal id counter.
quakewiki is indeed updated and working, but there’s going to be weird behavior on the subset of pages i mentioned.
Ugh, that sounds like a horrific mess. Thanks for the courage of stepping into that! If there is any manual sleuthing possible that could make people look up correct IDs using their text editor or excel or similar simple tools, I have had great success with crowdsourcing help in the past.
+1 on making editing harder for now. Is it maybe possible to require administrator oversight for activation of new accounts? That should weed out spammers nicely. Otherwise I would suggest making it read-only.
If you can, please close off registration and editing ASAP. The site is hammered by spam now.
It does not look like the Quake related question is used, I am seeing only simply math tasks.
I might be able to look into it tomorrow, but not today.
Edit: oh and dont bother cleaning up, i can revert to a daily snapshot of yesterday or so and then do the necessary steps again.
added the following changes:
$wgCaptchaClass = 'QuestyCaptcha';
$wgCaptchaTriggers['edit'] = true;
$wgCaptchaTriggers['create'] = true;
$wgCaptchaTriggers['sendemail'] = true;
$wgCaptchaTriggers['addurl'] = true;
$wgCaptchaTriggers['createaccount'] = true;
$wgCaptchaTriggers['badlogin'] = true;
$wgCaptchaTriggers['badloginperuser'] = true;
# remove editing permissions for everyone except admins
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['sysop']['edit'] = true;
i’m not sure if this was the reason, but i think the captcha’s extension now needs to have $wgCaptchaClass explicitly set. might have overlooked that when updating, sorry
i don’t know how to make accounts be queued until an admin manually approves them in some kind of dashboard.
first spam account appears to be 9 days ago:
HyeDbg81702072 (Created on 15 November 2025 at 21:37)
SungQ61836 (Created on 13 November 2025 at 04:31)
a quick grep -P '[A-Za-z\-]\d{4}"$' allusers.csv suggests there’s 1013 spam accounts, oof
there’s a crawler absolutely hammering the server up to the point where pages and ssh don’t load properly:
root@quakewiki:/srv/quakewiki/w# cut -d' ' -f1 /var/log/lighttpd/access.log | sort | uniq -c | sort -nr | head -n 10
153064 144.76.19.72
9540 216.73.216.185
6472 216.244.66.202
5880 37.139.53.220
3977 54.37.252.32
3526 216.73.216.178
2724 178.128.100.29
2113 5.3.176.82
1778 216.73.216.42
1663 5.16.79.246
i have manually checked every single ip here and theyre all reported as abusive by multiple users. i strongly recommend ip blocking the entire ASN range (or just 144.76.0.0/16), hopefully from the server’s control pane if they support that. otherwise let me know and i can add ip blocks at the http server level.
spam comes mainly from tiktok (automated crawler, not tiktok user’s traffic), blexbox, babbar(dot)tech, and seranking(dot)com.
blocked the main spammer from lighttpd /etc/lighttpd/lighttpd.conf:
$HTTP["useragent"] =~ ".*(BLEXBot|Barkrowler|meta-webindexer|Thinkbot).*" {
url.access-deny = ("")
}
access.check = (
"deny" => ("43.173.0.0/16", "45.133.170.0/24"),
"allow" => ("all")
)
also lol this user agent "Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.)"
1 Like
I got some internet access right now so could look into it.
Thanks! That 144. address is actually a server also hosted at my beloved host, I sent them an abuse notification so hopefully it can be nuked... Those ******* bots, it's crazy. Quaddicted is also under lots of abuse from them.
I'll right now make a snapshot of the current state and revert to the oldest "quick" backup, which is 2025-11-16. Then I will add your edits from above to it. Should be done in an hour or so. 
1 Like
Done! I can't login with my admin account at the moment but that is most probably PEBKAC 