[changing status to stalled and priority lowest since this will happen eventually, just not now]
Yes the functionality is overlapping. However, Special:LintErrors shows more information like the tag name, and has more metadata like position and stuff. Linter is still a bit new, so I think its OK to have duplicate functionality. In the long term I think we should look into phasing out some of the tracking categories and using Linter instead.
Tue, Jun 20
Same with MoveToCommonsClient apparently.
I -2'd the patch as the current implementation of fetching global user edit count is too slow. I think the options we have to move forward are:
Uhhh, getUrl() takes a page name, not article ID.
Most repos generally shouldn't need to use $IP. Those that do can manually whitelist it.
This is caught by the MediaWiki.WhiteSpace.SpaceBeforeControlStructureBrace.SpaceBeforeControl sniff now.
Marking as resolved for now, @brion could you file a new ticket if you're still running into issues?
Mon, Jun 19
If you need to query based on data in log_params, you should put it in the log_search table, which is indexed and easily queryable.
The bug is still in UserMerge, I mean.
Was it your IP address? Probably a bug with user_id = 0 and $wgUser defaulting to the current viewing IP address.
Regarding #8, I think if you are going to make wikitext use the same CSS class as a MediaWiki extension, weird stuff is going to happen (imagine an edge case where some gadget loaded the babel CSS or whatnot), and I don't think it's really an issue.
Sat, Jun 17
rMWc7e00974c7eb: Move loading of mediawiki.toc from Parser to Skin could be another thing to look at?
That page is just wrong.
Fri, Jun 16
The search function on graphite is private (requires NDA) but if there's a specific metric you want, all the data is publicly accessible if you construct the URL properly.
Why did you close this as invalid?
Thu, Jun 15
Wed, Jun 14
In the NimbusTemplate? $this->skin->getOutput()->addModuleStyles(...);
Tue, Jun 13
Yeah, a custom content model sounds like a good idea. We probably want to refactor the sidebar parsing logic out of skin and make it re-usable by the content class to display (duplicate IDs might be an intersting problem). Since the sidebar is also built with localize messages, a language selector that lets you view it in different languages would be neat too.
Until it's merged, the bug shouldn't be closed.
Probably more like something phan does, but it should also be doable in phpcs as well.
@Marostegui Is it alright if I start it now?
I totally missed this request until now - I've sent a notification to wikitech-l per the norm, and will aim to close it by the end of the week.
Mon, Jun 12
Could we add a "beta-only" section in make-wmf-branch's config.json?
This is intentional - it's not supposed to be published on packagist, nor installable via composer.
Sun, Jun 11
Please provide a screenshot. Note that you must be logged in to send thanks, and those edits must be from a different user who is not a bot.
Sat, Jun 10
Fri, Jun 9
I don't think the mass silently pushing CoC.md files into Gerrit was that great of an idea in retrospect, it should have been announced on wikitech-l at least.
Probably a dupe of T90382: Special:PendingChanges missing on Hindi Wikipedia though FlaggedRevs is installed though I haven't verified.
Ooh, that's interesting. +cc @Krinkle . This is probably caused by rMWff8a0c788bc8: parser: Avoid deprecated wfMemcKey() then. wfMemcKey() calls $wgMemc->makeKey so it would use the MemcachedBagOStuff implementation, but switching to the actual MultiWriteBagOStuff->makeKey() leaves it without the special memcache handling.
I think this proposal is framed as way more work than it actually is. The current setup of having most of MediaWiki in a "core" folder is already possible, and I run that as my main development setup every day:
Thu, Jun 8
Wed, Jun 7
This is being caused by the same thing as T132454: Some OAuth special pages are not recognized ('no such special page') - FlaggedRevs is registering special pages using $wgExtensionFunctions which is too late. See T132454#2213091