Thanks for reporting a bug.
Seems done now? Not sure yet which CPT-CD workboard column is right, so guessing one.
I'm not sure about the Schema-change part. That tag claims to be about actual schema changes. Glancing through the tasks currently in the schema change column of MediaWiki-Database, it seems a combination of actual schema changes, requests for maintenance scripts related to schema changes, and bugs in the updater when applying schema changes.
Wed, Jul 17
Err, this task is the real use case for that. But as mentioned the use case here could be satisfied by more explicit requests for "rights for the user in this session" versus "rights for this user generically".
Tue, Jul 16
Mon, Jul 15
It's possible that the reproduction case may have gone away if the page views data has changed so there's no longer an invalid title in the ruwiki results. The bug does still seem to exist in the code.
Is "wrap some part of the message in HTML" be a generic enough summary? That is, would ->someMethodName( 'n', $html ) with the $html string containing only $1 as the replacement be the right level of functionality?
I agree that building that distinction into the new PermissionManager's interface would be beneficial.
I'll admit I don't deal much with the fancier bits of the UI, but in my limited experience a link is generally done with wikitext and a button or other widget doesn't seem very likely to need to take data from the "outer" message. But I can see how there are cases where the added complication might be required for complicated links or the like, though.
It's not clear to me what exactly your example is supposed to be showing. You seem to have a parameter that itself contains parameter-replacements, but without a clear indication as to what pattern that would replace.
We've been discussing the intricacies of message input and output formats in more detail at T227447: Librarize i18n-related PHP classes in MediaWiki, we should probably have most of the discussion there instead.
Fri, Jul 12
There are two parts here:
No problem, it doesn't hurt to check. At one point we were considering the possibility of having the scripts update existing ES entries in place, but in the end we decided not to do that (instead the scripts would insert new ES entries so old ones can remain read-only). If we get back to either the recompression or reserialization projects, we'll consult you on the details then.
Thu, Jul 11
I'd say so.
Using comment_revision would help with #2 by reducing the number of subqueries needed.
This seems to be similar to T208691, this time affecting the code path where ApiQueryMostViewed is being used as a generator. The fix would be similar, the return value from Title::newFromText() at line 50 needs to be checked for null before being added to the array.
meta=siteinfo&siprop=namespaces would not be the right place for this, as that's intended for returning namespace names that actually function on the wiki.
Not just OAuth, it also doesn't work with BotPasswords.
Thanks for the ping, but I don't think we (meaning Core Platform Team) are working on the things that would touch on that maintenance at this time.
I can't manage to reproduce this (by hacking a throw of a similar exception with invalid UTF8 into an arbitrary API module), so I'm going to call this "resolved". Feel free to reopen with instructions on reproducing if you can reproduce it.
The parameters in prop=imageinfo themselves aren't very good. See T89971: ApiQueryImageInfo is crufty, needs rewrite. Ideally T66214: Define an official thumb API would be done, then the API could just point to that.
I'm going to go ahead and just close this. Stuff happened 3 years ago, we didn't think of everything to test at the time, and now we have no way to reproduce it to see if MariaDB is now smarter about things than it was back in 2016.
Styles from TemplateStyles are very similar to inline styles, as @Tgr noted, since they're both part of the wikitext content of the page. Safemode disables user and site level customizations, not content.
While it would be interesting to figure out the User::getActorId lock wait timeout, I see only 5 in the linked timeframe (and only 6 in the past 24 hours). They seem related to the same Special:Import as the rc_this_oldid error mentioned, but it's not obvious to me how or why. Most seem to be from job runners trying to process CategoryMembershipChangeJobs after the fact, just one is directly from the import.
Overall I like the idea, but I'd want to see more details as to how all the "in addition support" stuff is actually going to work at an interface level that doesn't wind up turning it into just another generic key-value store.
Wed, Jul 10
Tue, Jul 9
I found that the fifth possibility in T85000#936374 seems to do the right thing on 10.1.39.
email@example.com(enwiki)> explain SELECT /*! STRAIGHT_JOIN */ page_namespace,page_title,page_id FROM `page`,`langlinks` WHERE page_namespace = '0' AND (page_id=ll_from) GROUP BY page_title ORDER BY page_title LIMIT 11; +------+-------------+-----------+------+--------------------+------------+---------+---------------------+----------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-----------+------+--------------------+------------+---------+---------------------+----------+--------------------------+ | 1 | SIMPLE | page | ref | PRIMARY,name_title | name_title | 4 | const | 23486175 | Using where; Using index | | 1 | SIMPLE | langlinks | ref | PRIMARY | PRIMARY | 4 | enwiki.page.page_id | 3 | Using index | +------+-------------+-----------+------+--------------------+------------+---------+---------------------+----------+--------------------------+
So if we need to do something about the query at some point and 10.3 is the same as 10.1 here, I guess that's the thing to do.
This seems very overcomplicated. The proposal in this task seems to be https://xkcd.com/927/ for the concept of "identifiers", and would likely turn out much like the last panel there.
Mon, Jul 8
I don't want to lick this cookie just yet, but I do hope to try to work on this sometime soon. Or at least parts of it, I doubt I'll bother with the "less-minimal implementation" bit.
The action API has the errorlang parameter, which may be [...] "uselang" (apparently a misspelling of userlang)
- (?) allows use of the Promise-Non-Write-API-Action header (WebStart.php)
which may kill performance for a lot of API queries. We should figure out if that's true
Fri, Jun 21
Thu, Jun 20
Jun 13 2019
Jun 12 2019
This reminds me of T192855: Remex enabled on all wikis in MW 1.30-wmf.30 exposing corruption (signatures coloring unrelated follow-up sections, etc.) on unfixed content, related IRC discussion in https://wm-bot.wmflabs.org/logs/%23mediawiki-core/20180424.txt, and the workaround in rOMWCe674799cb346: Fix wgTidyConfig expansion to not ignore `null` as value.
I'll close this for now. No objection to reopening if the situation changes so aliases is no longer suitable.
Jun 11 2019
but API doesn’t tell which one is being used as a ‘canonical’ special page name on a wiki
That's a slightly different issue, having to do with recently added validation in Title rather than this task which has to do with usernames stored in the database. The specific example affects user pages only because it's WikiLove trying to find the user talk page for a user subpage.
If I were saving generic requests to a database, I'd be more likely to have a table with fields "param_name" and "param_value" rather than trying to make every possible parameter name a separate field. Or serialize all the parameters to a single text field. If I were designing storage for a specific handler, I'd be more likely to be using a getWikiUserTextNameOrIP() method so the code doing the DB insertion didn't have to know or care how exactly that value was determined.
Jun 10 2019
What do you do now, without BotPasswords? Have your test account have the same password everywhere?
I found this after seeing https://www.mediawiki.org/w/index.php?diff=3261645&oldid=3261642 and searching, as the relevant project tags don't seem to have been added to this task. If this is about MediaWiki-extensions-OAuth as that edit indicates, the summary seems incorrect. If it's not about that extension, then the confusion should be cleared up.
It'd be nice to figure out why XMLReader::open() seems unable to open files that seem like they do in fact exist. Is there some sort of multiprocess work going on and the process doing the open() is racing with the process writing the file? Or is it possible multiple dump processes are trying to use the same temporary file names somehow and stomping on each other? But I don't know whether it's worth the time/effort if we have a workaround.
Jun 7 2019
I just saw an edit on wikitech with a similar dirty diff: https://wikitech.wikimedia.org/w/index.php?title=Logstash&diff=1828764&oldid=1827679