nice, all of the spam is gone.
e-mail works so you should be able to recover your account here
1 Like
Hi, I may be a bit late to the party here. I wanted to contribute to some of the pages, specifically several of the official map’s pages that are barren. Noticed I needed administrative access to edit. I’m rather new to the whole wiki thing but I hate fandom wiki. I’m wondering if there is any update to getting the site operational, or at least, a way for me to edit some of the pages!
hello! you’re free to contribute; any help updating the content is very much welcome. the wiki is operational.
you should be able to create an account and start working on it right away. perhaps you found a protected page? most pages are unprotected and open to any user.
could you link me so i can check? otherwise it might be this lingering config:
we needed a heavy-handed approach because the wiki was getting a lot of bot spam, but i thought that was already solved. could you check the php code @Spirit ? EDIT: the config was indeed blocking users. fixed it.
i still have ssh access, so i went ahead and fixed the config
users can edit now! 
2 Likes
And I just realised why older accounts cannot login. I dropped the private infos before giving you access as an over sensitive precaution and forgot to restore them. D'oh!
On it right now 
Hm, I managed to reset my password now that I have a mail address set again for my user. But when I log in, any subsequent request to the wiki gives an error:
[08ef57209a3cac2510ac9ada] /wiki/Main_Page TypeError: hash_equals(): Argument #1 ($known_string) must be of type string, null given
Backtrace:
from /srv/quakewiki/w/includes/session/CookieSessionProvider.php(144)
#0 /srv/quakewiki/w/includes/session/CookieSessionProvider.php(144): hash_equals()
#1 /srv/quakewiki/w/includes/session/SessionManager.php(542): MediaWiki\Session\CookieSessionProvider->provideSessionInfo()
#2 /srv/quakewiki/w/includes/session/SessionManager.php(248): MediaWiki\Session\SessionManager->getSessionInfoForRequest()
#3 /srv/quakewiki/w/includes/Request/WebRequest.php(867): MediaWiki\Session\SessionManager->getSessionForRequest()
#4 /srv/quakewiki/w/includes/session/SessionManager.php(167): MediaWiki\Request\WebRequest->getSession()
#5 /srv/quakewiki/w/includes/Setup.php(494): MediaWiki\Session\SessionManager::getGlobalSession()
#6 /srv/quakewiki/w/includes/WebStart.php(85): require_once(string)
#7 /srv/quakewiki/w/index.php(50): require(string)
#8 {main}
Google found me https://phabricator.wikimedia.org/T397423 but I am not sure if that applies (and what it means).
Maybe I need to restore more than just the user.user_email column?
I've just updated MediaWiki to 1.43.6 (dec/2025) and checked that I can still log in, log out, edit and watch pages.
you might've restored user_token by accident which is a cookie that should have expired long ago. drop the contents of that column and clear your browser cookies.
you can either do it directly on the database or do it though the maintenance scripts. something roughly along the lines of:
php maintenance/run.php invalidateUserSessions --user '*'
// OR
UPDATE user SET user_token = '' WHERE user_token IS NULL;
// OR maybe
UPDATE user SET user_token = NULL;
i'm not sure so make backups!!
it might also be related to the weird cache settings this wiki runs (CACHE_MEMCACHED for one skin?) so try dropping the memcached cache immediately after you make any database changes and before logging in:
$ telnet localhost 11211
> flush_all
# php maintenance/run.php invalidateUserSessions --user 'Spirit'
Failed to invalidate sessions for user Spirit | CAS update failed on user_touched. The version of the user to be saved is older than the current version.
Wikimedia\Rdbms\DBTransactionError from line 1470 of /srv/quakewiki/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php: Commit failed on server(s) localhost: Cannot execute query from MediaWiki\Maintenance\MaintenanceRunner while transaction status is ERROR
#0 /srv/quakewiki/w/includes/libs/rdbms/lbfactory/LBFactory.php(333): Wikimedia\Rdbms\LoadBalancer->commitPrimaryChanges()
#1 /srv/quakewiki/w/maintenance/includes/MaintenanceRunner.php(811): Wikimedia\Rdbms\LBFactory->commitPrimaryChanges()
#2 /srv/quakewiki/w/maintenance/includes/MaintenanceRunner.php(710): MediaWiki\Maintenance\MaintenanceRunner->shutdown()
#3 /srv/quakewiki/w/maintenance/run.php(51): MediaWiki\Maintenance\MaintenanceRunner->run()
#4 {main}
PHP Notice: Uncommitted DB writes (transaction from MediaWiki\User\User::saveSettings) in /srv/quakewiki/w/includes/libs/rdbms/database/TransactionManager.php on line 564
PHP Notice: DB transaction writes or callbacks still pending (MediaWiki\User\User::saveSettings) in /srv/quakewiki/w/includes/libs/rdbms/database/Database.php on line 3207
Directly editing the DB and flushing memcached did nothing, same result after logging in.
user_touched is 20180829171140 for "Spirit". I tried to set it to the future just to see what would happen. Same error with the invalidateUserSessions script.
looks to me like you're trying to restore the user data of an older backup or something that has a different schema than the mw 1.43.6 i installed last week. that'll definitely break things.
i don't really have the time or mental bandwidth to check it out right now, sorry.
1 Like
Totally understandable! Sorry for the mess on the system.
I really only restored the user_email column, with plain SQL UPDATEs. I guess it is some breakage from old times that is resurfacing. 
The site was DDOSed by the AI bot horde. The CPU was pegged at 100%. 2 million requests from 850000 unique IPs in the past week. This crap makes hosting anything on the open web no fun anymore. 
I added a mandatory cookie which seems to work well enough for now.
D'oh, this will block good agents like Google too.
I don't have the energy to find a better solution. If someone is willing to take over quakewiki.org, please shout!
spirit!!! oh no i hate these fucking ai crawler bots that hog servers. i've had my own share of issues on my own mediawiki instance and i've had success with anubis and go-away but, as you say, the false positive rate is too large for comfort, so they do block some known good bots.
nginx's rate limiting is pretty good, too, but not for ~850000 unique ips.
while i can take care of quakewiki, i don't have a vps or a box to keep it running. is the current vps insufficient for the amount of traffic going through it? should we think moving out of mediawiki? it is quite the large php project after all, and perhaps static pages would fit quakewiki since its read heavy but there's rarely any writes.
tldr: i'm available to look after quakewiki but i don't have hosting
i checked and there's been 420358 requests today and 331220 requests yesterday. the site is seriously under heavy load.