Anomie assigned this task to daniel.
Anomie moved this task from Ready to Doing on the Core Platform Team Workboards
(Clinic Duty Team) board.
Anomie added a comment.
Moving to "Doing" because there's a patch with unaddressed reviews.
TASK DETAIL
https://phabricator.wikimedia.o
Anomie edited projects, added Traffic, Core Platform Team Workboards (Clinic
Duty Team); removed MediaWiki-API, Core Platform Team, Wikidata.
Anomie added a comment.
Restricted Application added a project: Operations.
There was no change to MediaWiki with respect to output of Set-Cookie
Anomie renamed this task from "Wikidata password login via MediaWiki API fails"
to "Clients failing API login due to dependence on "Set-Cookie" header name
casing".
TASK DETAIL
https://phabricator.wikimedia.org/T249680
EMAIL PREFERENCES
https://phabricato
Anomie updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T68051
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Perhelion, IKhitron, Iniquity, Dvorapa, daniel, Ricordisamoa,
Capankajsmilyo, zhuyifei1999
Anomie added a comment.
In T225814#5992589 <https://phabricator.wikimedia.org/T225814#5992589>,
@Anomie wrote:
> Digging a little deeper, it seems to assume that every URL being mangled
can use the local value for `$wgMobileUrlTemplate` rather than determining the
mangl
Anomie merged a task: T108201: CentralAuth autologin broken for non-www mobile
domains (mediawiki.org, wikidata.org).
Anomie added subscribers: Krinkle, aude, Jdlrobson.
TASK DETAIL
https://phabricator.wikimedia.org/T225814
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Anomie edited projects, added MobileFrontend, Readers-Web-Backlog; removed Core
Platform Team, MediaWiki-extensions-CentralAuth.
Anomie added a comment.
This has nothing directly to do with CentralAuth. The logic that mangles URLs
for mobile domains belongs to #MobileFrontend
<ht
Anomie removed a project: Core Platform Team.
Anomie moved this task from Inbox to Waiting for Review on the Core Platform
Team Workboards (Clinic Duty Team) board.
Anomie claimed this task.
Anomie added a comment.
In T240083#5732516 <https://phabricator.wikimedia.org/T240083#5732
Anomie moved this task from Unsorted to Needs details or plan on the
MediaWiki-API board.
Anomie edited projects, added Core Platform Team Workboards (Clinic Duty Team),
DBA; removed Core Platform Team.
Anomie added a comment.
The query in question is
SELECT
rc_id,rc_timestamp
Anomie closed this task as "Resolved".
Anomie added a comment.
The fix should be deployed with 1.35.0-wmf.20. If you empty the category
after that version is deployed, and it starts filling up again, feel free to
reopen.
TASK DETAIL
https://phabricator.wikimedia.org/T237
Anomie added a project: Core Platform Team Workboards (Clinic Duty Team).
TASK DETAIL
https://phabricator.wikimedia.org/T237746
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Jarekt, Anomie
Cc: Anomie, matej_suchanek, Aklapper, Liuxinyu970226
Anomie added a comment.
In T240083#5732516 <https://phabricator.wikimedia.org/T240083#5732516>,
@daniel wrote:
> Could that be deferred until the point where the User object would usually
be initialized from the session?
That seems like it would bring back the problems fr
Anomie added a comment.
> `User::saveSettings` is calling `Title::purgeSquid`. It is undocumented why
changing preferences requires purging the user page, unconditionally,
synchronously.
It was added in r42179
<http://mediawiki.org/wiki/Special:Code/MediaWiki/42179> with
Anomie removed projects: Core Platform Team, MediaWiki-API.
Anomie added a comment.
In T240316#5727749 <https://phabricator.wikimedia.org/T240316#5727749>,
@Bugreporter wrote:
> Actually the reason is QuickStatements use a single IP to edit on behalf of
different users
Anomie removed a project: Core Platform Team.
Anomie added a comment.
According to
https://www.mediawiki.org/wiki/Extension:WikibaseMediaInfo#MediaInfo_Entity,
the entity ID is "in the form Mxxx, where xxx is the id of the associated wiki
page". So you can look at the `pag
Anomie removed a project: Core Platform Team.
TASK DETAIL
https://phabricator.wikimedia.org/T145050
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Liuxinyu970226, Aklapper, Fomafix, darthmon_wmde, WDoranWMF, DannyS712,
Nandana
Anomie added a comment.
This seems to be much the same thing as T235265: Slow query on
SpecialMostLinked creating lag on wikidata slaves
<https://phabricator.wikimedia.org/T235265>, BTW, just with a different special
page.
TASK DETAIL
https://phabricator.wikimedia.org/T239072
Anomie added a comment.
In T238575#5675356 <https://phabricator.wikimedia.org/T238575#5675356>,
@Lucas_Werkmeister_WMDE wrote:
> but I certainly hope we have no code that actually makes use of SQLite’s
dynamic type system?
It's pretty unlikely unless as a hack, since gen
Anomie added a comment.
In T238575#5675210 <https://phabricator.wikimedia.org/T238575#5675210>,
@Lucas_Werkmeister_WMDE wrote:
> How? It’s a `VARBINARY` field! (`BLOB` in sqlite, I guess, according to
`DatabaseSqlite::replaceVars()`.)
The declared column types in sqlite ar
Anomie closed subtask T198312: Set the WMF cluster to use the new MCR-only
schema as Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T183487
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: gerritbot, Tgr, Jdforrester-WMF, Anomie
Anomie added a comment.
Is it happening only when the page is first created? It's possible that we
forgot to have Scribunto set the vary-page-id flag when the page ID is accessed
in this way so MediaWiki knows to reparse the page after the page ID gets
assigned.
TASK DETAIL
https
Anomie removed a project: Core Platform Team.
TASK DETAIL
https://phabricator.wikimedia.org/T212069
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Lucas_Werkmeister_WMDE, WMDE-leszek, alaa_wmde, Mvolz, Anomie, Aklapper,
Yurik
Anomie added a comment.
If you need to, you can submit a dummy patch against Wikibase with a
Depends-On for the core patch to get the tests to run. See
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/497443 for
example.
TASK DETAIL
https://phabricator.wikimedia.org
Anomie added a comment.
@Lucas_Werkmeister_WMDE is correct. It was unstable in 1.25, maybe even 1.26,
to give time for people to find and report places where we missed making the
needed changes. It's not unstable anymore.
It "officially" became stable in 1.33 with rMW8ec833f7
Anomie added a project: Core Platform Team Workboards (Clinic Duty Team).
TASK DETAIL
https://phabricator.wikimedia.org/T230862
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Cparle, Anomie
Cc: Marostegui, EBernhardson, Cparle, dcausse, Anomie
Anomie added a comment.
We could probably eliminate the join with `page` in this query, but other
than that I don't see much opportunity for improvement.
wikiadmin@10.64.32.113(wikidatawiki)> explain SELECT pl_namespace AS
`namespace`,pl_title AS `title`,COUNT(*) AS `value` F
Anomie edited projects, added Core Platform Team Workboards (Clinic Duty Team);
removed Core Platform Team.
TASK DETAIL
https://phabricator.wikimedia.org/T235265
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Aklapper, Ladsgroup, Anomie
Anomie moved this task from Inbox to Done on the Core Platform Team Workboards
(Clinic Duty Team) board.
Anomie closed this task as "Resolved".
Anomie claimed this task.
TASK DETAIL
https://phabricator.wikimedia.org/T234795
WORKBOARD
https://phabricator.wikimedia.org/project/
Anomie added a project: Core Platform Team Workboards (Clinic Duty Team).
TASK DETAIL
https://phabricator.wikimedia.org/T234795
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: Anomie, Krinkle, aaron, Ladsgroup, Aklapper, WMDE-leszek
Anomie added a comment.
Bah, I figured it out. I should have read
https://www.sqlite.org/lang_UPSERT.html more closely. The diagram at the top
shows part of the syntax is optional, but the text adds restrictions:
> The syntax that occurs in between the "ON CONFLICT" and
Anomie added a comment.
But that doesn't change the fact that whatever PHP is using, it reports
3.24.0 but doesn't have the upsert syntax added in 3.24.0.
TASK DETAIL
https://phabricator.wikimedia.org/T234795
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
Anomie added a comment.
If it's using 3.22 but reporting 3.24, that would be what's causing the
problem here.
Or it could just be that the PHP sqlite extension is linked with a different
version from the command line client.
TASK DETAIL
https://phabricator.wikimedia.org/T234795
Anomie added a comment.
Doesn't seem to be a problem with ActorMigration.
I wonder what version of sqlite is being used there. rMW4bd1b4b45571: rdbms:
optimize insert(), replace(), and upsert() for sqlite when possible
<https://phabricator.wikimedia.
Anomie added a comment.
Using tags has the advantage of more directly identifying the relevant
revisions, //if// the planner decides that gathering all revisions with the tag
then filtering by which are in RC (and probably filesorting) is a better plan
than taking rows from RC (in order
Anomie added a comment.
At the database level, you should be able to detect RC entries that changed a
particular slot easily enough, by including a join like
JOIN slots ON (rc_this_oldid = slot_revision_id AND slot_role_id = ? AND
slot_origin = slot_revision_id)
If you want
Anomie closed this task as "Declined".
Anomie added a comment.
Since the behavior used as justification for reopening this has been deemed a
bug, I'm going to re-decline this task.
TASK DETAIL
https://phabricator.wikimedia.org/T44886
EMAIL PREFERENCES
https://phabricator.wik
Anomie added a comment.
See T221869: Remove deprecated ApiQueryDeletedRevs
<https://phabricator.wikimedia.org/T221869> for what's needed to remove the
module from a Wikimedia usage perspective. The status seems unchanged since
that task was created.
TASK DETAIL
Anomie added a comment.
In T198492#5471360 <https://phabricator.wikimedia.org/T198492#5471360>,
@daniel wrote:
> I think what we have done in the past was simply nothing. We would just
have left these fields in, forever. Or told people to run an SQL patch by hand.
{{citati
Anomie added a comment.
In T198492#5470617 <https://phabricator.wikimedia.org/T198492#5470617>,
@daniel wrote:
> @daniel renamed this task from //**Drop rev_text_id and ar_text_id when
running update.php**// to //**Create a maintenance script to drop rev_text_id
and ar_tex
Anomie added a comment.
In T230862#5443759 <https://phabricator.wikimedia.org/T230862#5443759>, @Tgr
wrote:
> I think it's worth revisiting, and there was unanimous agreement on that at
last TechConf's relevant session
<https://www.mediawiki.org/wiki/Wikimedia_Technical_Con
Anomie added a comment.
In T230862#5443345 <https://phabricator.wikimedia.org/T230862#5443345>, @Tgr
wrote:
> IMO we'll have to bite that bullet at some point and change MediaWiki from
a PHP-based application to a container-based one, so we can package
ElasticSearch
Anomie added a comment.
In T230862#5427914 <https://phabricator.wikimedia.org/T230862#5427914>,
@daniel wrote:
> Perhaps the recentchanges system should be migrated to Elastic, that would
help with a lot of things :)
OTOH, that would break it for any MediaWiki wikis
Anomie moved this task from Inbox to Done on the Core Platform Team Workboards
(Clinic Duty Team) board.
Anomie added a project: Traffic.
Anomie added a comment.
There's nothing to do with #MediaWiki-API
<https://phabricator.wikimedia.org/tag/mediawiki-api/> here, or with MediaWiki
Anomie added a project: Core Platform Team Workboards (Clinic Duty Team).
TASK DETAIL
https://phabricator.wikimedia.org/T85499
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Ladsgroup, Anomie
Cc: Lea_Lacroix_WMDE, Addshore, Lucas_Werkmeister_WMDE
Anomie closed subtask T220415: Add API module to get language information as
Resolved.
TASK DETAIL
https://phabricator.wikimedia.org/T217239
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: gerritbot, Mvolz, Anomie, Lucas_Werkmeister_WMDE
Anomie added a comment.
In T125050#5233908 <https://phabricator.wikimedia.org/T125050#5233908>,
@hashar wrote:
> I guess we can come up with a PHPUnit group name, in mediawiki/core add a
new testsuite that would exclude the group and then switch the wmf-quibble jobs
to use
Anomie added a comment.
In T125050#5120646 <https://phabricator.wikimedia.org/T125050#5120646>,
@hashar wrote:
> Scribunto has a set of test to make sure it works fine with some LUA
interpreters. That is really nice but takes a few minutes iirc. When one send
a patch fo
Anomie renamed this task from "Central modules need the user language to
display errors and category names" to "Implement Lua alternative to
{{int:Lang}} / wgUserLanguage".
TASK DETAIL
https://phabricator.wikimedia.org/T68051
EMAIL PREFERENCES
https://phabricator.wi
Anomie merged a task: T173207: Implement Lua alternative to {{int:Lang}} /
wgUserLanguage.
Anomie added subscribers: Ricordisamoa, daniel.
TASK DETAIL
https://phabricator.wikimedia.org/T68051
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc
Anomie moved this task from Unsorted to Blocked on the MediaWiki-API board.
Anomie added a comment.
As far as #MediaWiki-API
<https://phabricator.wikimedia.org/tag/mediawiki-api/> is concerned, this is
blocked on someone moving this "global ID" concept into core and
Anomie added a comment.
From the MediaWiki perspective, this is a duplicate of T220999: Slow query
"ApiQueryLogEvents::execute" after actor rollout
<https://phabricator.wikimedia.org/T220999>, which should roll out with the
train next week unless someone backports it on
Anomie closed this task as a duplicate of T220999: Slow query
ApiQueryLogEvents::execute after actor rollout.
TASK DETAIL
https://phabricator.wikimedia.org/T221543
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: hashar, Aklapper
Anomie added a comment.
In T198341#5137816 <https://phabricator.wikimedia.org/T198341#5137816>,
@Anomie wrote:
> For that matter, I should run a query on the Analytics data to see whether
we can just remove ApiQueryDeletedrevs entirely yet.
T221869: Remove d
Anomie added a comment.
I don't think ApiQueryDeletedrevs will need larger changes, actually. Like
the other accesses to `old_id`, the JOIN with `text` there was just to prefetch
fields for a call to `Revision::getRevisionText()`. Removing the JOIN will just
make the later `getRevisionText
Anomie removed a project: MediaWiki-extensions-Scribunto.
TASK DETAIL
https://phabricator.wikimedia.org/T219716
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Anomie
Cc: matej_suchanek, Aklapper, Liuxinyu970226, Marshallsumter, alaa_wmde,
Nandana
Anomie added a comment.
The annoying bit is that the join condition for `pagecontent` will look
something like `old_id = substring( content_address from '^tt:(8[0-9]+)$'
)::int`, which hard-codes the "tt:". Thankfully PG has that regexp-based
substring and casting NULL to `int` w
Anomie added a comment.
In T198341#502 <https://phabricator.wikimedia.org/T198341#502>,
@BPirkle wrote:
> To make sure I'm heading in the right direction:
>
> - Postgres currently uses columns in specific tables
(pagecontent.textvector and page.titlevecto
Anomie added a project: SyntaxHighlight.
Anomie added a comment.
Looks like two of the failures are in Scribunto, but the other 9 are in
#syntaxhighlight <https://phabricator.wikimedia.org/tag/syntaxhighlight/>.
TASK DETAIL
https://phabricator.wikimedia.org/T218702
EMAIL PREFE
Anomie added a comment.
In T218127#5032746 <https://phabricator.wikimedia.org/T218127#5032746>,
@Lucas_Werkmeister_WMDE wrote:
> Well, `Message` doesn’t have to be the only way to do i18n. We can add some
hook that lets us completely bypass the `Message` and `comment_text`, and
Anomie added a comment.
In T198341#5022412 <https://phabricator.wikimedia.org/T198341#5022412>,
@daniel wrote:
> In T198341#5021347 <https://phabricator.wikimedia.org/T198341#5021347>,
@BPirkle wrote:
>
> > - includes/search/SearchPostgres.php
>
>
Anomie added a comment.
If we want to remove the Message handling from CommentStore and let Wikibase
do its i18n based on `->data` (in either a modified 'FormatAutocomments' that
gets the data or some higher-level hook added to `Linker::formatComment()`), I
can't think of any ma
Anomie added a comment.
> I'll also remove any references to the other two fields [text.old_id and
archive.ar_text_id]
Note that text.old_id references are probably sill valid in low-level code
like HistoryBlob.php and SqlBlobStore.
> - maintenance/populateContentTabl
Anomie added a comment.
Yes. You should just be able to delete the two references.
When the code was added in rMW27c61fb1e94d: Add `actor` table and code to
start using it
<https://phabricator.wikimedia.org/rMW27c61fb1e94da9114314468fd00bcf129ec064b6>
`rev_text_id` did no
Anomie added a comment.
In T218127#5020389 <https://phabricator.wikimedia.org/T218127#5020389>,
@Lucas_Werkmeister_WMDE wrote:
> Then why are we even using the `Message` class for comments?
Because Wikibase wants i18n.
TASK DETAIL
https://phabricator.wikimedia.or
Anomie added a comment.
In T218127#5018266 <https://phabricator.wikimedia.org/T218127#5018266>,
@Lucas_Werkmeister_WMDE wrote:
> How exactly this proper rendering looks like, though, is not yet clear.
That's really the main question here. If it weren't for that, t
Anomie added a comment.
I tried the following via shell.php to get some idea of the timing.
$t0 = microtime( true );
foreach ( Language::fetchLanguageNames() as $code => $name ) {
Language::getFallbacksFor( $code, Language::STRICT_FALLBACKS );
}
$t1 = microtime( t
Anomie moved this task from Unsorted to Needs details or plan on the
MediaWiki-API board.
Anomie added a comment.
> As a tool developer, it would be very useful to access the language
fallback graph from an API.
What exactly would you do with this information? i.e. what's the actual
Anomie moved this task from Backlog to External on the MediaWiki-extensions-Scribunto board.Anomie added a comment.
Probably via mw.ext.wikibase mw.wikibase then, rather than mw.title.TASK DETAILhttps://phabricator.wikimedia.org/T216356WORKBOARDhttps://phabricator.wikimedia.org/project/board/558
Anomie added a comment.
In T213318#4957191, @dbarratt wrote:
In T213318#4956647, @Joe wrote:
I do think that both in the short term and in the long term, having a single application written in PHP being able to do the basic job of a wiki is a must.
By what metric are you using to come
Anomie added a comment.
In T213318#4948197, @Pablo-WMDE wrote:
Doesn't a "single page application" mean that when the user clicks a link within the "page" it hits an API and updates the content without reloading a page?
We are building an application that focuses on di
Anomie added a comment.
In T213318#4944035, @WMDE-leszek wrote:
Also, re the MCR points above. I admit I am not an expert on MCR topics, but if I am not completely wrong, this proposal here does not change much when taking MCR into account. As long as there is an API which acts with the storage
Anomie added a comment.
In T213318#4939014, @Addshore wrote:
SDC being Structured data on Commons?
Yes, sorry.
The MediaInfo entity type on commons does its own thing.
[...]
I'm not sure how this RFC alters the future of possible MCR and Wikibase integrations? These changes to the frontend
Anomie added a comment.
Would this affect how SDC works? Wikibase's editing is already weird, with JS-based editing on the view page, and seems unlikely to truly fit in with a future core MCR editing model. This proposal seems like it might extend that weirdness to viewing too.
Other than
Anomie closed this task as "Resolved".Anomie claimed this task.Anomie added a comment.
Yes. I left it open back in March because of concern that it might reoccur when we started changing configuration for T188327, but that concern was addressed by 993baa349 and 59e856e3e.TASK D
Anomie added a comment.
Moving to "done" on the #MediaWiki-API workboard per rMWf54029806dad: Use SpecialPageFactory in ApiQueryQueryPage.TASK DETAILhttps://phabricator.wikimedia.org/T208924EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Michael
Anomie added a comment.
Relevant code for this specific example: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/6eea7f8d5e52a528877748391e3fae965f752018/repo/includes/Api/ResultBuilder.php#1019. Changing that "" to true should do it, although with how c
Anomie added a comment.
In T210953#4800621, @Lucas_Werkmeister_WMDE wrote:
@Tchanders FYI, in another change we noticed that we’d also failed to override requiresWrite – could that require a similar investigation?
requiresWrite does not matter for this task.TASK DETAILhttps
Anomie added a comment.
"info": "[a3dc984b44fa2b36b377efe2] Exception caught: Slot role mediainfo is not allowed.",
That makes it sound like code somewhere needs to call MediaWikiServices::getSlotRoleRegistry()->defineRole( 'mediainfo', ... ) to define the mediainfo role.
Anomie closed this task as "Resolved".Anomie assigned this task to Lucas_Werkmeister_WMDE.Anomie added a comment.
In T210634#4789618, @Lucas_Werkmeister_WMDE wrote:
The change adding the test was reverted in Id2eeeb781b (I’m not sure why @gerritbot didn’t leave a comment), and si
Anomie closed this task as "Resolved".Anomie added a comment.
This should be resolved now. If more wikis start having the error, try running the maintenance described in T210732#4785479.TASK DETAILhttps://phabricator.wikimedia.org/T210732EMAIL PREFERENCEShttps://phabricator.wikimedia.or
Anomie added a comment.
FYI: I ran it on a bunch more wiktionaries and all worked. I also tried running it on incubatorwiki and sourceswiki, but both failed (I inserted the necessary row manually on those two).TASK DETAILhttps://phabricator.wikimedia.org/T183019EMAIL PREFERENCEShttps
Anomie added a comment.
The wikis in this second batch: afwiktionary amwiktionary angwiktionary anwiktionary astwiktionary aywiktionary azwiktionary bewiktionary bgwiktionary bnwiktionary bswiktionary cawiktionary chrwiktionary cowiktionary csbwiktionary cywiktionary dawiktionary dewiktionary
Anomie added a comment.
These started at 2018-11-26T18:35:09, consistent with the deployment of e23c7c4c4 at 2018-11-26T15:24 (and not consistent with the deployment of wmf.6).
It was affecting the following sites: arwiktionary brwiktionary cswiktionary elwiktionary eowiktionary eswiktionary
Anomie added a comment.
I just ran it on several wiktionaries and it seemed to work?TASK DETAILhttps://phabricator.wikimedia.org/T183019EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, AnomieCc: hashar, Stashbot, gerritbot, WMDE-leszek, hoo
Anomie added a comment.
It looks like it's just that the need to run populateSitesTable.php when enabling Wikibase on wikis never made it into the right documentation.TASK DETAILhttps://phabricator.wikimedia.org/T183019EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
Anomie added a project: MediaWiki-extensions-WikibaseClient.Anomie added a comment.Restricted Application added a project: Wikidata.
It looks like all of these are due to Wikibase\Client\Changes\InjectRCRecordsJob. I suspect T183019: Wikibase must not insert local recentchanges entries
Anomie added a comment.
Or you could have someone else try it again.TASK DETAILhttps://phabricator.wikimedia.org/T210634EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AnomieCc: Bawolff, Anomie, Aklapper, Lucas_Werkmeister_WMDE, Nandana, A.S.Kochergin, God
Anomie added a comment.
Apparently the test added for T209232: Add a unit test to Scribunto testing it is not vulnerable to CVE-2014-5461 is sometimes running out of allowed memory (set by ulimit most likely) before it runs out of Lua stack space (a constant set in Lua's C code), so it's giving
Anomie added a comment.
In T209927#4769515, @daniel wrote:
If we implement a multi-slot EditPage, we will however need some way to decide for which slots to show input fields, especially during page creation. Showing them for all allowed text based slots would quickly become overwhelming
Anomie added a comment.
Note that this does not always mean that they can be edited atomically with the rest of the content, or that they can be edited using the standard EditPage at all. It just means that editing them should be offered to the user somehow.
This makes no sense to me. What does
Anomie added a comment.
Though does not provide a way to access all slots of old revisions, we still need a solution for that.
It should work fine to use the existing oldid parameter with the new slot parameter. Although by this I suppose you're actually meaning "there's no place in the UI
Anomie added a comment.
"editable": Slot may be editable via EditPage and ApiEditPage.
Default is "ignored": Slot is ignored by EditPage and ApiEditPage.
On second thought, maybe we should switch that. Have the default be "editable" and allow code to specify "
Anomie added a project: MediaWiki-API.Anomie added a comment.
There's a decent chance that the 2010-era code in ApiQueryQueryPage could use updating in some manner.
$qp = new $this->qpMap[$params['page']]();
It should probably use SpecialPageFactory somehow instead.TASK DETAILht
Anomie added a comment.
Q123507, specifically this revision.
What happened is that one row in the revision_comment_temp table was missing on the master (db1071, I believe) but was present on several replicas. And apparently it was only the one row.TASK DETAILhttps://phabricator.wikimedia.org
Anomie added a comment.
In T208695#4722100, @jcrespo wrote:
Could an interaction with archive create issues- eg. the undeletion of a revision so it gets moved from archive to revision and archive is know to been unreliable in the past?
The page in question has no entries in the logging table
Anomie closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T198308EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AnomieCc: jcrespo, ArielGlenn, Stashbot, gerritbot, Keegan, Fjalapeno, CCicalese_WMF, Aklapper, Tgr, An
Anomie closed subtask T198308: Enable MCR migration stage "write both, read new" on live systems as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T174044EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AnomieCc: Stashbot, Addshor
Anomie closed subtask T198308: Enable MCR migration stage "write both, read new" on live systems as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T174047EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AnomieCc: Stashbot, jcresp
Anomie added a comment.
The corresponding revision-table row is timestamped 2018-09-13T09:08:17Z. $wgCommentTableSchemaMigrationStage should have been WRITE_BOTH since February 2018, so the revision_comment_temp row should have already existed, so the migration script shouldn't have been having
Anomie moved this task from Backlog to External on the MediaWiki-extensions-Scribunto board.Anomie added a comment.
In T205646#4623491, @matmarex wrote:
I think the Android app uses the Parsoid rendering of the page, which seems to be not affected by the problem: https://eo.wikipedia.org/api
1 - 100 of 379 matches
Mail list logo
