Hi.
User Details
- User Since
- Oct 3 2014, 5:46 PM (516 w, 22 m)
- Availability
- Available
- IRC Nick
- Glaisher | Philon
- LDAP User
- Glaisher
- MediaWiki User
- Glaisher [ Global Accounts ]
Apr 9 2023
Apr 13 2022
Oct 21 2019
Jun 15 2018
May 23 2018
Dec 30 2017
Dec 20 2017
Nov 19 2017
Jul 14 2017
Jul 6 2017
Jul 2 2017
Sorry I'm very busy nowadays so I'm not sure when I would have time for this. :(
Jun 1 2017
May 7 2017
Apr 12 2017
Jan 13 2017
Jan 1 2017
Dec 28 2016
Dec 21 2016
Dec 19 2016
Dec 15 2016
The above now-abandoned patch actually does implement this but we do not want to do it without migrating to the current log formatter system, it cannot be done easily.
Nov 5 2016
You need to enter the page's title only, not the full URL in the form field.
ssh [email protected] cd /srv/mediawiki-vagrant vagrant ssh mysql wiki
and then run the DROP TABLE for the newsletter tables.
Oct 30 2016
Global IP block exempts doesn't exempt you from local blocks on all wikis; rather it exempts you from actual "global blocks". In this case, 8.37.225.0/24 is locally blocked on English Wikipedia so even if you have a global block exempt right, it doesn't let you bypass the local block.
Oct 9 2016
Oct 8 2016
This is also causing all IP ranges to appear as globally blocked in Special:Block too (under other blocks) due to the wrong query being run.
After updating core, I am able to reproduce locally. Something seems to have changed the behavior of IP::toHex()(?) so it now returns false instead of empty string.
SELECT * FROM `globalblocks` WHERE (gb_range_start like '%') AND (gb_range_start <= 0) AND (gb_range_end >= 0) AND (gb_expiry > '20161007152532') ORDER BY gb_timestamp DESC LIMIT 2
Oct 7 2016
Weird. This is the query which it's supposed to do on that page but it doesn't return any result on labs.
MariaDB [centralauth_p]> SELECT * FROM `globalblocks` WHERE (gb_range_start like '%') AND (gb_range_start <= '') AND (gb_range_end >= '') AND (gb_expiry > '20161007150458') ORDER BY gb_timestamp DESC LIMIT 2; Empty set (0.01 sec)
I don't remember this happening previously but this patch has been live on the projects since 2014.
Oct 1 2016
Sep 16 2016
Sep 15 2016
Sep 13 2016
We could probably remove the submit button at the top and just have a submit button at the bottom like other normal forms. That might make people do some more scrolling when there's a huge list of pages but they should be reviewing the list anyway before doing a deletion. ;-)
@Huji The point of this task is to get rid of storing log text in the CU table.. If the log text is stored (instead of type, params etc.), then we would have the issues we are currently having. See the subtasks. Or maybe you meant something else?
Sep 12 2016
I can also see the issues with having a separate formatting system but are we sure that data that is going to be inserted in CU will always have a corresponding log table entry? How should cases such as GlobalRename (T131207) be handled?
Sep 11 2016
Probably LinksDeletionUpdate is not run because of this
[exception] [c813a3f80b163cfad906f03b] /wiki/index.php?title=Special:MovePage&action=submit DBUnexpectedError from line 3050 of /var/www/html/wiki/includes/db/Database.php: MWCallableUpdate::doUpdate: Cannot COMMIT to clear snapshot because writes are pending. #0 /var/www/html/wiki/includes/db/loadbalancer/LoadBalancer.php(1184): DatabaseBase->flushSnapshot(string) #1 [internal function]: LoadBalancer->{closure}(DatabaseMysqli) #2 /var/www/html/wiki/includes/db/loadbalancer/LoadBalancer.php(1589): call_user_func_array(Closure, array) #3 /var/www/html/wiki/includes/db/loadbalancer/LoadBalancer.php(1192): LoadBalancer->forEachOpenMasterConnection(Closure) #4 [internal function]: LoadBalancer->beginMasterChanges(string) #5 /var/www/html/wiki/includes/db/loadbalancer/LBFactory.php(220): call_user_func_array(array, array) #6 [internal function]: LBFactory->{closure}(LoadBalancer, string, array) #7 /var/www/html/wiki/includes/db/loadbalancer/LBFactorySimple.php(160): call_user_func_array(Closure, array) #8 /var/www/html/wiki/includes/db/loadbalancer/LBFactory.php(223): LBFactorySimple->forEachLB(Closure, array) #9 /var/www/html/wiki/includes/db/loadbalancer/LBFactory.php(272): LBFactory->forEachLBCallMethod(string, array) #10 /var/www/html/wiki/includes/deferred/DeferredUpdates.php(232): LBFactory->beginMasterChanges(string) #11 /var/www/html/wiki/includes/deferred/DeferredUpdates.php(199): DeferredUpdates::runUpdate(MWCallableUpdate, LBFactorySimple, integer) #12 /var/www/html/wiki/includes/deferred/DeferredUpdates.php(125): DeferredUpdates::execute(array, string, integer) #13 /var/www/html/wiki/includes/MediaWiki.php(779): DeferredUpdates::doUpdates(string) #14 /var/www/html/wiki/includes/MediaWiki.php(620): MediaWiki->restInPeace(string) #15 /var/www/html/wiki/includes/MediaWiki.php(639): MediaWiki->{closure}() #16 /var/www/html/wiki/includes/MediaWiki.php(533): MediaWiki->doPostOutputShutdown(string) #17 /var/www/html/wiki/index.php(43): MediaWiki->run() #18 {main} [Bug56269] Exception thrown with an uncommited database transaction: [c813a3f80b163cfad906f03b] /wiki/index.php?title=Special:MovePage&action=submit DBExpectedError from line 1195 of /var/www/html/wiki/includes/db/loadbalancer/LoadBalancer.php: MWCallableUpdate::doUpdate: Flush failed on server(s) localhost: MWCallableUpdate::doUpdate: Cannot COMMIT to clear snapshot because writes are pending. #0 [internal function]: LoadBalancer->beginMasterChanges(string) #1 /var/www/html/wiki/includes/db/loadbalancer/LBFactory.php(220): call_user_func_array(array, array) #2 [internal function]: LBFactory->{closure}(LoadBalancer, string, array) #3 /var/www/html/wiki/includes/db/loadbalancer/LBFactorySimple.php(160): call_user_func_array(Closure, array) #4 /var/www/html/wiki/includes/db/loadbalancer/LBFactory.php(223): LBFactorySimple->forEachLB(Closure, array) #5 /var/www/html/wiki/includes/db/loadbalancer/LBFactory.php(272): LBFactory->forEachLBCallMethod(string, array) #6 /var/www/html/wiki/includes/deferred/DeferredUpdates.php(232): LBFactory->beginMasterChanges(string) #7 /var/www/html/wiki/includes/deferred/DeferredUpdates.php(199): DeferredUpdates::runUpdate(MWCallableUpdate, LBFactorySimple, integer) #8 /var/www/html/wiki/includes/deferred/DeferredUpdates.php(125): DeferredUpdates::execute(array, string, integer) #9 /var/www/html/wiki/includes/MediaWiki.php(779): DeferredUpdates::doUpdates(string) #10 /var/www/html/wiki/includes/MediaWiki.php(620): MediaWiki->restInPeace(string) #11 /var/www/html/wiki/includes/MediaWiki.php(639): MediaWiki->{closure}() #12 /var/www/html/wiki/includes/MediaWiki.php(533): MediaWiki->doPostOutputShutdown(string) #13 /var/www/html/wiki/index.php(43): MediaWiki->run() #14 {main} [queries] testwiki: ROLLBACK /* MWExceptionHandler::rollbackMasterChangesAndLog Admin */
Hmm, this is not just for translatable pages. Normal pages are also like this. Maybe I'm wrong but I don't remember this being like this previously.
Okay, please re-open if you find any issues.
I can reproduce this locally. Stacktrace:
[e8944a7c7567e062cf45253b] /wiki/index.php/Special:UserRights Wikimedia\Assert\ParameterAssertionException from line 63 of /var/www/html/wiki/vendor/wikimedia/assert/src/Assert.php: Bad value for parameter $dbkey: invalid DB key Backtrace: #0 /var/www/html/wiki/includes/title/TitleValue.php(81): Wikimedia\Assert\Assert::parameter(boolean, string, string) #1 /var/www/html/wiki/includes/specialpage/SpecialPage.php(100): TitleValue->__construct(integer, string, string) #2 /var/www/html/wiki/includes/specialpage/SpecialPage.php(84): SpecialPage::getTitleValueFor(string, string, string) #3 /var/www/html/wiki/includes/specialpage/SpecialPage.php(629): SpecialPage::getTitleFor(string, string) #4 /var/www/html/wiki/includes/specials/SpecialUserrights.php(224): SpecialPage->getPageTitle(string) #5 /var/www/html/wiki/includes/specials/SpecialUserrights.php(211): UserrightsPage->getSuccessURL() #6 /var/www/html/wiki/includes/specialpage/SpecialPage.php(522): UserrightsPage->execute(NULL) #7 /var/www/html/wiki/includes/specialpage/SpecialPageFactory.php(583): SpecialPage->run(NULL) #8 /var/www/html/wiki/includes/MediaWiki.php(283): SpecialPageFactory::executePath(Title, RequestContext) #9 /var/www/html/wiki/includes/MediaWiki.php(750): MediaWiki->performRequest() #10 /var/www/html/wiki/includes/MediaWiki.php(521): MediaWiki->main() #11 /var/www/html/wiki/index.php(43): MediaWiki->run() #12 {main}
Sep 10 2016
That might work for things which use the normal logging table but won't work for others which doesn't make use of it like AbuseFilter, GlobalRename (T131207) and possibly others. (AbuseFilter's insertion of CU entries is also kind of hackish).
Sep 9 2016
Can this be closed now?
See also T129370: Create a special page to have lists of translators, based on Extension:TranslationNotifications which requests adding a page for the list of users, not just a count.
Sep 7 2016
Sep 6 2016
- 2016-09-05T22:26:44 "Error editing the page" errors started to occur.
- 2016-09-05T22:28:37Z First notification for Template:Usurpation logged
- 2016-09-05T22:58:29Z Second notification for Support and Safety logged
- 2016-09-05T23:29:16Z Bot blocked
- 2016-09-05T23:30:34Z Global account locked
- 2016-09-06T00:29:32 Errors ended.
Sep 2 2016
Open patches that need reviewing (in dependent order):
- https://gerrit.wikimedia.org/r/#/c/307141/ Modernize CheckUser old logs import script
- https://gerrit.wikimedia.org/r/#/c/307253/ Add populateCheckUserTable script
- https://gerrit.wikimedia.org/r/#/c/307336/ Cleanup CheckUser setup and remove old files
Sep 1 2016
Aug 31 2016
This was fixed several months ago. It didn't actually insert a new block - just adds a new log entry. https://gerrit.wikimedia.org/r/#/c/247617/
Aug 30 2016
T51898 and this is now fixed on Translate side. You would need to remove the English $wgTranslateBlacklist entry on your wiki for it to work properly.
T124013: Do not allow saving translations to blacklisted language codes has also been fixed so it won't be possible to make these edits through normal edit page as well.
Aug 29 2016
Hmm, I wrongly assumed that clicking close discards all the unsaved translations. Actually, it doesn't in which case this is the right behavior.