Apparently there is an autoblockipblock event which is a subset of what's asked here. Not sure if it actually gets logged.
This is being followed up in T314952: Misleading message shows in skins where VE is compatible but the page because of its state isn't (thanks for filing @Jdlrobson).
I wonder if there should be a separate warning and error channel. Errors typically should be treated no differently than exceptions - they are used e.g. when an exception was caught manually to provide graceful error handling, for logic errors (when some theoretically impossible condition occurs), for backend errors etc. I don't think they should be filtered out in general. The "Your skin is incompatible with VisualEditor" error should not be filtered out in theory either, as it is not supposed to happen in Wikimedia production (we have no such skins), that would have just been a temporary measure about a known bug with minimal impact.
Presence of the edit tab in SkinTemplate is conditional on Title::canExist() + Authority::probablyCan('read') + Authority::probablyCan('edit'). I think the read check is superfluous and only done as a performance optimization. The edit check is available on the JS side as mw.config.get('wgIsProbablyEditable'). The canExist check at a glance is not done by the permission system, and I don't think it is exposed via JS. But it's probably a pretty rare case - it only happens for some invalid titles, and I don't see the error there. Presumably the pageCanLoadEditor check already covers that.
Seems like a good proposal to me (but it would be nice to get wider feedback at some point).
MediaWiki doesn't really have a mechanism for delaying stuff, and we are not doing any new feature work on NewUserMessage (IMO it never made sense to put that functionality in a MediaWiki extension in the first place). You might be better served by a welcome but (e.g. Pywikibot has this functionality).
Maybe there should be a config variable for mapping the IDs to human-readable names.
I think Flow has switched from rc_type to rc_source for most internal purposes (T74157: [Story] Use rc_source and drop RC_TYPE) so could as well use one of the core types. But I'm not sure anyone has the bandwidth to experiment with that. Updated the docs (1, 2) for now.
Per https://www.mediawiki.org/wiki/Compatibility#Database we require 10.3 for MediaWiki 1.39, which is when this commit was added. But yeah MySQL not supporting it (even in 8.0) is a problem.
This looks the same as T311092: Sticky header conflicts with Structured Discussions sticky header on board pages, except that is marked as fixed.
Flow recentchanges entries use rc_source value flow (or Flow\Data\Listener\RecentChangesListener::SRC_FLOW if you want to be nice about it). Contributions / revisions aren't stored in the database in the normal way; check out the ContributionsQuery and DeletedContributionsQuery hooks. Although if you handle things close to the display side of MediaWiki, it shouldn't make much difference.
The log spike corresponds to the logging code (rEVED591796df12d4: Log incompatible skin warnings) reaching enwiki. The actual bug (if it is indeed a bug) was probably around for a long time, we just did not log it before. The train deployment issues were apparently unrelated.
This is ready for desktop.
This is a side effect of rMW8b810330c288: Fail update if bot_passwords doesn't exist (and later rMWd66fe8b7c79e: Bump minimum required version for upgrade to 1.31). In theory pretty easy to fix, we just need to find a table that has always existed.
I don't think that is a thing.
session1> insert into user_properties VALUES (42, 'C', 'x'), (43, 'B', 'x'); Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0
Tue, Aug 9
This doesn't make any sense to me. These are insert intention locks on a non-autoincrement table. They should only be exclusive for the specific index record they are inserting; they are not supposed to prevent other transations from writing in the same gap. The primary key is (up_user, up_property) so unless there is something weird we don't see because of the query text being truncated, it should not be possible for these two queries to deadlock.
I guess for searches you'd similarly split the query string, and then do a join with the relevant part of the query string applied to each table? Seems like that would work, and it would even allow domain-level statistics which could be useful but wouldn't be straightforward with the current DB structure.
Why do we even have a separate expanddblist and $multiversion/bin/expanddblist with basically identical content? It will in the end execute code in the multiversion repo anyway, so the security footprint is the same. Why isn't expanddblist just an alias/redirect to the other?
Fri, Aug 5
No mention of enwikiquote in https://ores-support-checklist.toolforge.org/ though. So the first step would be for the wiki editors to label edits.
I didn't find any deployment docs, so created https://wikitech.wikimedia.org/wiki/Add_Image#Enabling_image_recommendations_on_a_new_wiki
I can still reproduce this:
(It seems Chrome doesn't allow decreasing the width below some limit.)
Thanks for the explanation.
Thu, Aug 4
I think this happened / is happening in T281132: Moving Image Suggestions Service to k8s?
On all talk pages, it seems.
I can't reproduce the exception in debug mode (although the link is still broken), probably some sort of race condition?
Thanks for the quick fix!
Hm, right, jqueryMsg can't expand interwiki prefixes for the same reason it can't detect external links. You could just add the extiw class via JS when the popup loads, I guess. Or use an external link as @Iniquity says.
Wed, Aug 3
Please file a separate bug if something is causing duplicate notifications, we are generally trying to avoid those.
Whoops, looks like our eventlogging error dashboard was missing the mediawiki.editgrowthconfig stream. Now fixed.
The table was added in rECAUd4289d11dc4c: Support for temporary user creation recently, as part of the IP masking / temp user work. UnitTestsAfterDatabaseSetup tries to recreate a table that wasn't removed in the teardown. I don't think this is related to the tests failing or not.
Occurrences in the last 30 days:
Image recommendation stats in the last 90 days:
so this doesn't seem to have a visible impact on KPIs (but probably does result in some extra errors shown to users).
Not just a visual bug, they become unclickable too (the click always goes to the first element).
Tue, Aug 2
Declining this was the right choice IMO. No user impact, doesn't happen a lot, Flow is abandonware so no point in doing unimportant work on it.
The (non-final, I think) mock for T313310: Impact module: Implement table list component includes a "past year" and "all time" option. The pageviews API can send data in daily or monthly increments, going back to about 2016 (it has data from 2015 July, not sure if it's reliable early on), with a different API serving 2008-2016 data. So "all time" will be since 2008 at best, since 2016 if we don't use the legacy API.
The mock uses a chartline which goes back five days (or five somethings, could be weekly I guess), is that the intention? I suspect the sparkline will be much less visually compelling if we try to make it use a much higher data resolution (e.g. daily views in the last 30 days), as page view data is relatively noisy.
This is not straightforward - either we'd have to do a separate search with a page ID filter for each task type (somewhat ugly and slow), or we need to fetch task type data from Cirrus directly (T243478: Newcomer tasks: fetch ElasticSearch data for search results).
The fix looks good for the unstructured version, but Special:MentorDashboard with structured mentorship enabled also always shows Average, because there is no structured version of the weight manager. Is that tracked somewhere?
composer.json has "league/oauth2-server": "dev-v9.0.0-alpha#61d770dc284898ea2905d66e12f8f7e5f6664092 as 9.0.0" so I guess one thing to check is whether your vendor repo actually has that revision. The other is whether the Composer autoloader is getting loaded. I think it's the second issue because...
14.5549 282019464 21. AutoLoader::autoload($className = 'MediaWiki\\Extension\\OAuth\\Entity\\ClaimEntity') /var/www/wiki/mediawiki/extensions/OAuth/tests/phpunit/Repository/ClaimStoreTest.php:33 14.5558 282021736 22. require('/var/www/wiki/mediawiki/extensions/OAuth/src/Entity/ClaimEntity.php') /var/www/wiki/mediawiki/core/includes/AutoLoader.php:244
otherwise there should be another autoloader call on the top of the stack (with a file not found error raised from within the ClaimEntityTrait autoloader, as opposed to the autoloader returning false and and an error being raised at the call site), no?
What we could easily do on the PHP side is to make the score threshold or the link count somewhat dependent on how underlinked the article is. But that would require more effort from the Add Link service (more link candidates to check) so it might or might not turn out to be feasible, or might require performance improvements to the service (which would be nice to do anyway, but a bit outside our comfort zone).
Someone would have to take stock of the current IRC / Slack / Discord bots (some IRC bots are documented at wikitech:Category:Bots) and see which of those would make sense for Matrix. I think the most common tasks are responding to !help and such, and handling wikilinks / phab IDs / QIDs.
This is marked resolved but was it actually resolved? If there is guidance on whether / how we can use AGPL licensed software (I think that's what resolved would mean here), where do I find it?
Mon, Aug 1
Changing mediawiki.jqueryMsg is not hard (the relevant logic is in the wikilink method in resources/src/mediawiki.jqueryMsg/mediawiki.jqueryMsg.js; in general, the parser is pretty easy to read once you wrap your head around the layout and the funky way it gets set up), but I don't think the list of interwiki prefixes is accessible from frontend code, and without that you can't tell whether it's an interwiki or a namespace or part of a mainspace title.