Tgr created this task.
Tgr added projects: WikibaseMediaInfo, SDC General, Commons.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
Currently, the HTML title (ie. the `` tag, ie. the text seen at the
very top
Tgr added a comment.
The title of the task made me think it's about refreshing the edited page
(ie. the page itself containing outdated/inconsistent data after the edit), but
I guess it's actually about refreshing the category page (ie. recursive links
update)? Those are different things. I
Tgr added a comment.
Can you confirm whether this has been fixed?
TASK DETAIL
https://phabricator.wikimedia.org/T237991
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Tgr, Addshore, Jarekt, Aklapper, CBogen, Akuckartz, darthmon_wmde
Tgr added a comment.
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/632685
16:31:51 [Chrome 73.0.3683.75 linux #0-3] 1) Wikitext Editor (Makes actual
saves) Redirects
16:31:51 [Chrome 73.0.3683.75 linux #0-3] element (".overlay
.wikitext-editor") still not exis
Tgr added a comment.
In T248457#6435718 <https://phabricator.wikimedia.org/T248457#6435718>,
@TheDJ wrote:
> I find the lack of action on this ticket stunning.
FWIW, there is some discussion on this on
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(WM
Tgr added a comment.
@Iniquity this is not a good place to have this argument. If you want to
convince the English Wikipedia community that Wikidata descriptions do not
conflict with their policies, or that they should be used regardless of whether
they conflict with their policies, you
Tgr added a comment.
I have a hard time making sense of this bug report. What is the page where
you should have been logged in but weren't, and how is that related to the
OAuth server?
TASK DETAIL
https://phabricator.wikimedia.org/T254202
EMAIL PREFERENCES
https
Tgr updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T254202
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Aklapper, Epidosis, Akuckartz, darthmon_wmde, Nandana, lucamauri, Lahi,
Gq86, GoranSMilovanovic
Tgr added a comment.
Ideally, `wbgetentities` should be a prop module. That would be useful for
both SDC/MediaInfo and for Wikidata, and in general fits with API conventions
better.
TASK DETAIL
https://phabricator.wikimedia.org/T206645
EMAIL PREFERENCES
https
Tgr edited projects, added Discovery-Search, Wikidata-Query-Service,
RESTBase-API; removed Operations, Traffic.
Tgr added a comment.
Restricted Application added a project: Wikidata.
Yeah, this is probably due to the lack of `Access-Control-Allow-Headers:
X-Wikimedia-Debug` in RESTBase
Tgr added a project: User-Tgr.
TASK DETAIL
https://phabricator.wikimedia.org/T166094
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Michael, Abbe98, Pigsonthewing, Bugreporter, Tgr, Dvorapa, thiemowmde,
Lydia_Pintscher, Izno, Whatamidoing
Tgr added a project: User-Tgr.
TASK DETAIL
https://phabricator.wikimedia.org/T213585
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Tgr, Dvorapa, RexxS, Pigsonthewing, ChristianFerrer, Abbe98, Aklapper,
CBogen, darthmon_wmde, Nandana
Tgr added a comment.
The page title is set in `DifferenceEngine::showDiffPage`, you'd have to
factor out that part into something that can be sanely overridden. Or, I guess,
change the title from the DifferenceEngineOldHeaderNoOldRev and
DifferenceEngineOldHeader hooks, although that's
Tgr added a project: good first task.
Tgr added a comment.
Short description handling currently lives in Wikibase, so mw.wikibase makes
sense nevertheless.
This should be reasonably easy, there's a service to return the description,
it just needs some scaffolding to make it available
Tgr added a comment.
This is unlikely to happen for the same reasons T243931: Allow a module to
load (require) another module from a global module repository wiki
<https://phabricator.wikimedia.org/T243931> didn't.
TASK DETAIL
https://phabricator.wikimedia.org/T191531
EMAIL PREFE
Tgr added a comment.
MediaWiki automatically wraps the entire request in a transaction if it
encounters a write which does not do its own transaction handling. So something
unrelated to saving could have started the transaction, like AbuseFilter taking
an action, or a session refresh
Tgr added a comment.
This has not been resolved. Declined, maybe?
TASK DETAIL
https://phabricator.wikimedia.org/T585
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Cparle, Abbe98, Ramesh2744, MarkTraceur, Abit, Ramsey-WMF, atgo, Matanya
Tgr added a comment.
I would suggest the opposite: keep `sql.php`, drop `patchSql.php`. I don't
think many people are familiar with the latter (compare patchSql
<https://www.mediawiki.org/w/index.php?title=Special:Search=500=0=1=1=1=1=1=1=%22patchSql.php%22={}>
vs sql
Tgr added a comment.
I guess the impact is a 20-min outage for requests not served from Varnish +
missing sitelinks / descriptions / infoboxes / other info from wikidata for
pages which have been edited since the end of the outage? Plus potentially some
automated editing tools getting wrong
Tgr added a comment.
I'd guess someone triggered T157651: sql.php runs LoadExtensionSchemaUpdates
<https://phabricator.wikimedia.org/T157651>. I actually made the same mistake
while trying to figure out what's broken:
tgr@mwmaint1002:~$ mwscript sql.php huwiki
>
Tgr added a project: MediaWiki-extensions-WikibaseRepository.
TASK DETAIL
https://phabricator.wikimedia.org/T249565
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Ahmad252, Dreamy_Jazz, Tgr, Liuxinyu970226, Koavf, DannyS712, Aklapper
Tgr added a comment.
> api.php?action=query=userinfo=json via OAuth to retrive the
username of the user
That works but it's not necessarily safe. You should use the OAuth identify
endpoint
<https://www.mediawiki.org/wiki/OAuth/For_Developers#Identifying_the_user>
Tgr added a comment.
Did you have both the wikidata and machinevision roles enabled? I'm not sure
that's supported.
TASK DETAIL
https://phabricator.wikimedia.org/T245845
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Tgr, Aklapper
Tgr added a comment.
In T231084#5839574 <https://phabricator.wikimedia.org/T231084#5839574>,
@Addshore wrote:
> With canDiffRevisions being implemented in DifferenceEngine which would see
if the 2 contents say they can be diffed with each other?
How would DifferenceEn
Tgr created this task.
Tgr added projects: MediaViewer, SDC General.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
MediaViewer has a caption and description area (above and below the fold,
respectively
Tgr updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T213585
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Tgr, Dvorapa, RexxS, Pigsonthewing, ChristianFerrer, Abbe98, Aklapper,
darthmon_wmde, Nandana, JKSTNK
Tgr updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T213585
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Tgr, Dvorapa, RexxS, Pigsonthewing, ChristianFerrer, Abbe98, Aklapper,
darthmon_wmde, Nandana, JKSTNK
Tgr added a comment.
Seems pretty clear there is no support for using the caption that way
(correctly, in my opinion), so rewrote the task to be agnostic of specifically
how the alt text is stored. (But it will probably be a dedicated Wikidata
property, see T166094: Allow editors to provide
Tgr renamed this task from "Images (on articles, on file/category pages, and in
the media viewer) should default to use their structured data caption as alt
text when available" to "Images (on articles, on file/category pages, and in
the media viewer) should default to use their
Tgr added a parent task: T166094: Allow editors to provide default alt text on
Wikimedia Commons file description pages.
TASK DETAIL
https://phabricator.wikimedia.org/T86517
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: DannyS712, Yurik
Tgr added a subtask: T86517: [Story] Add a new datatype for multilingual text.
TASK DETAIL
https://phabricator.wikimedia.org/T166094
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Tgr, Dvorapa, thiemowmde, Lydia_Pintscher, Izno, Whatamidoing
Tgr added a comment.
Repurposed this to be SDC-specific. The next step would be to write a
property proposal (and do it better than the rejected past attempts, which were
not very well written).
TASK DETAIL
https://phabricator.wikimedia.org/T166094
EMAIL PREFERENCES
https
Tgr renamed this task from "Please include suggested alt text for images" to
"Allow editors to provide default alt text on Wikimedia Commons file
description pages".
Tgr added a project: Commons.
Tgr updated the task description.
TASK DETAIL
https://phabricator.wikimedi
Tgr added a comment.
(See also T202763: Update extensions which customize content diff rendering
<https://phabricator.wikimedia.org/T202763>.)
DifferenceEngine calls the renderer of the right-hand item (so if you compare
wikibase item to wikitext, it will call TextSlotDiffRe
Tgr added a comment.
In T231084#5554961 <https://phabricator.wikimedia.org/T231084#5554961>, @Tgr
wrote:
> From a distance, the simple solution would be to create a UserPageError
subclass describing the situation and throw that instead of the assertion error.
One thin
Tgr added a comment.
The diff logic leaves it to the SlotDiffRenderer implementation to handle
incompatible types. Sorry about that, it's a bit shoddy. I don't remember if
there was some specific reason for not turning it into a user error, or it was
merely rushed.
From a distance
Tgr added a comment.
That's a duplicate of T231084: Assert.php: Bad value for parameter
$oldContent: must be a TextContent|null
<https://phabricator.wikimedia.org/T231084> (minus the pentesting aspect, which
I would not be worried about).
TASK DETAIL
https://phabricator.wikimed
Tgr added a comment.
In T230862#5503781 <https://phabricator.wikimedia.org/T230862#5503781>,
@Cparle wrote:
> So say we add a 'structured-data-mediainfo' tag to every revision that has
a `mediainfo` slot - would that be adequate? @EBernhardson ?
Given that this is a func
Tgr added a comment.
Thanks for lookig into it! These should be folded into the Vagrant role
settings. I can do that in a few weeks; if you want to do it before that, the
`mediainfo` role has an example of how to create Wikibase properties/entities
(that should probably be moved
Tgr added a comment.
IIRC this happens when Wikibase server code is loaded for a client wiki. I
tried to sort that apart in gerrit 524617
<https://gerrit.wikimedia.org/r/c/mediawiki/vagrant/+/524617> but maybe didn't
fully succeed.
(Note that enabling roles before the very
Tgr added a comment.
In T230862#5443414 <https://phabricator.wikimedia.org/T230862#5443414>,
@Anomie wrote:
> That has been proposed and opposed by various people for a long time.
I think it's worth revisiting, and there was unanimous agreement on that at
last TechConf's
Tgr added a comment.
In T230862#5442416 <https://phabricator.wikimedia.org/T230862#5442416>,
@Anomie wrote:
> OTOH, that would break it for any MediaWiki wikis not using Elastic...
IMO we'll have to bite that bullet at some point and change MediaWiki from a
PHP-based ap
Tgr added a comment.
In theory it would be something like `recentchanges JOIN revision ON
rc_this_oldid = rev_id JOIN slots ON slot_revision_id = rev_id AND slot_role_id
= whatever AND slot_origin = rev_id`. Except slot_origin is not used
consistently that way; this would miss rollbacks
Tgr added a project: Multi-Content-Revisions.
Tgr added a comment.
This is a special case of being able to filter by MCR slot type, which we'll
surely need in the long term.
TASK DETAIL
https://phabricator.wikimedia.org/T230862
EMAIL PREFERENCES
https://phabricator.wikimedia.org
Tgr added a comment.
rMWVA695fe0c8803c: Make wikidata and wikibase_repo roles work together
<https://phabricator.wikimedia.org/rMWVA695fe0c8803c2a5f10428b295249a4f63e97905c>
did this for Wikibase (in a very hacky way but I can't see any better one),
you should be able to generaliz
Tgr closed this task as "Resolved".
Tgr claimed this task.
Tgr added a comment.
Fixed, see T228428#5399031
<https://phabricator.wikimedia.org/T228428#5399031>. (Although as mentioned
there, the mediainfo role doesn't actually work. That was already the case
before th
Tgr closed this task as "Resolved".
Tgr claimed this task.
TASK DETAIL
https://phabricator.wikimedia.org/T228593
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Mholloway, Agabi10, WMDE-leszek, Aklapper, Tgr, Hook696,
Tgr added a comment.
Actually it does get installed when I run Composer manually. So this is
probably just an ordering issue, with composer update running before the
merge-plugin fragment is added.
TASK DETAIL
https://phabricator.wikimedia.org/T228593
EMAIL PREFERENCES
https
Tgr added a comment.
Core's `composer.json` has an extra/merge-plugin entry for
`composer.local.json` which has one for `../settings.d/composer/*.json` which
includes a file created by the wikidata role which has a merge-plugin entry for
`extensions/Wikibase/composer.json`. Maybe recursive
Tgr created this task.
Tgr added projects: MediaWiki-Vagrant, Wikidata, Composer.
Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTION
Wikibase does not use extension registration (T88258
<https://phabricator.wikimedia.org/T88258>) and it does not load the Composer
auto
Tgr closed this task as "Resolved".
Tgr added a comment.
This seems to be a composer-merge-plugin failure. Probably better to open a
separate task: T228593: Wikibase on Vagrant: composer-merge-plugin does not
install wikibase/data-model anymore <https://phabricator.wikimedi
Tgr updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T201615
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Smalyshev, Tgr
Cc: Mvolz, Jdforrester-WMF, gerritbot, ArielGlenn, Agabi10, Jdlrobson, bd808,
Smalyshev, WMDE
Tgr added a comment.
This is a problem on Vagrant, but that has its own task already: T201615:
Wikibase on Vagrant: Class 'Wikibase\DataModel\Entity\ItemId' not found
<https://phabricator.wikimedia.org/T201615>. Shouldn't be a problem in a manual
Wikibase install in theory.
TASK
Tgr closed this task as a duplicate of T201615: Wikibase on Vagrant: Class
Wikibase\DataModel\Entity\ItemId not found.
TASK DETAIL
https://phabricator.wikimedia.org/T228589
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Aklapper, Tgr
Tgr reopened this task as "Open".
Tgr added a comment.
Seems to have regressed at some point.
TASK DETAIL
https://phabricator.wikimedia.org/T201615
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Smalyshev, Tgr
Cc: Mvolz, Jdfor
Tgr merged a task: T228589: Wikidata vagrant role is broken.
TASK DETAIL
https://phabricator.wikimedia.org/T201615
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Smalyshev, Tgr
Cc: Mvolz, Jdforrester-WMF, gerritbot, ArielGlenn, Agabi10, Jdlrobson
Tgr created this task.
Tgr added projects: MediaWiki-Vagrant, MediaWiki-extensions-WikibaseClient.
Restricted Application added a subscriber: Aklapper.
Restricted Application added a project: Wikidata.
TASK DESCRIPTION
Result of running `vagrant up; vagrant roles enable wikidata; vagrant
Tgr added a comment.
In T226084#5270335 <https://phabricator.wikimedia.org/T226084#5270335>, @Tgr
wrote:
> There have been complaints on huwiki as well (and partial / failed page
loads, presumably due to some kind of timeout; I have seen a few myself). Don't
know if it'
Tgr added a comment.
There have been complaints on huwiki as well (and partial / failed page
loads, presumably due to some kind of timeout; I have seen a few myself). Don't
know if it's related. It has definitely started sooner than the group1
deployment, though.
TASK DETAIL
https
Tgr added a comment.
Unless something is seriously broken the `error` log channel should contain
the full stack trace for the WebResponse call (something is tyring to set a
cookie after the JWT has been output, but without a stack trace it will be hard
to figure out what - although you
Tgr added a comment.
That sounds like a secondary error, there should be another error in the logs
that caused it.
TASK DETAIL
https://phabricator.wikimedia.org/T225506
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Tgr, Lydia_Pintscher
Tgr added a comment.
You need to install dependencies of the extension via Composer. (We have some
documentation <https://www.mediawiki.org/wiki/Composer> on it but it's not
great.)
TASK DETAIL
https://phabricator.wikimedia.org/T225506
EMAIL PREFERENCES
Tgr added a comment.
Set something like
$wgDebugLogGroups['exception'] = '/var/log/mediawiki/exception.log';
$wgDebugLogGroups['error'] = '/var/log/mediawiki/error.log';
$wgDebugLogGroups['fatal'] = '/var/log/mediawiki/fatal.log';
$wgDebugLogGroups['OAuth'] = '/var/log
Tgr added a comment.
Check your exception logs.
TASK DETAIL
https://phabricator.wikimedia.org/T225506
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Tgr, Lydia_Pintscher, Addshore, Tarrow, Aklapper, Moraorviz, darthmon_wmde,
Nandana
Tgr closed this task as "Resolved".
Tgr assigned this task to Abit.
Tgr added a comment.
Yay!
(For those not familiar with SDC, see mw:Help:File captions
<https://www.mediawiki.org/wiki/Help:File_captions> and Commons:File captions
<https://commons
Tgr added a comment.
This is now fixed in master (thanks @Anomie!) and will be deployed Wednesday
next week. I think the error is not so bad that it would require an emergency
deploy?
TASK DETAIL
https://phabricator.wikimedia.org/T221380
EMAIL PREFERENCES
https
Tgr added subscribers: JoeWalsh, Dbrant, Tgr.
Tgr added a comment.
In T187960#4997875 <https://phabricator.wikimedia.org/T187960#4997875>,
@Marostegui wrote:
> #reading-infrastructure-team-backlog
<https://phabricator.wikimedia.org/tag/reading-infrastructure-team-backlog/&g
Tgr added a project: User-Tgr.
TASK DETAIL
https://phabricator.wikimedia.org/T201765
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Tgr
Cc: Alensha, MaxBioHazard, stjn, Bencemac, Aklapper, Tgr, Nandana, Lahi, Gq86,
GoranSMilovanovic, QZanden
Tgr closed this task as a duplicate of T214217: Improve handling of diffs between different content types.
TASK DETAILhttps://phabricator.wikimedia.org/T52202EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: thiemowmde, hoo, aude, Addshore, Bugreporter
Tgr added a comment.
I see both in the dropdown.TASK DETAILhttps://phabricator.wikimedia.org/T193360EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: NHarateh_WMF, Jdforrester-WMF, JMinor, JoeWalsh, Aklapper, ABorbaWMF, cooltey, Dbrant, Hello903hello
Tgr added a comment.
uselang is the user interface language - the conceptual equivalent of going into your preferences and changing the language (the actual equivalent too, overriding that setting is exactly what it does). That setting is accessible to MediaWiki methods called by the API, and used
Tgr added a comment.
Vagrant has a role to do that (role::oauth::consumer) although it uses raw SQL queries which a maintenance script probably shouldn't.TASK DETAILhttps://phabricator.wikimedia.org/T211568EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc
Tgr added a comment.
The view action expects rendered contentm, and the fallback handler has no knowledge of how to render its content, so it should use the raw action instead.
Though that does not provide a way to access all slots of old revisions, we still need a solution for that.
Introduce
Tgr updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...Links to these per-slot views could be given from a list of all slots present, from action="" Though that does not provide a way to access all slots of old revisions, we still need a solution for that. TASK D
Tgr added a comment.
I also noticed that the Action API uses a lot of enums for values... should the server maintain a list of these values?
You could also fetch them from the paraminfo API module if you don't mind the latency.TASK DETAILhttps://phabricator.wikimedia.org/T173214EMAIL
Tgr added a comment.
And all the URLs are crazy like that. Is that some kind of SQL injection scanning?TASK DETAILhttps://phabricator.wikimedia.org/T194164EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, TgrCc: Tgr, Nikerabbit, Marostegui, Legoktm
Tgr added a comment.
Seems to have started an hour ago, though, not when the patch was deployed: https://logstash.wikimedia.org/goto/ed4d3af593dd6d272ee6b5ef0bed5d67TASK DETAILhttps://phabricator.wikimedia.org/T194164EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
Tgr added a comment.
@Halfak the questions is: given that XML readers are somewhat flexible, so a script that was written some time ago and has no knowledge of MCR will still be able to read MCR dumps and see all the fields it expects, and it will quietly ignore non-main slots as unknown fields
Tgr added a comment.
Just add a tag?TASK DETAILhttps://phabricator.wikimedia.org/T199121EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ArielGlenn, TgrCc: FaFlo, Halfak, vrandezo, Denny, kchapman, tstarling, awight, JAllemandou, hoo, pmiazga, Nemo_bis, brion
Tgr closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T174035EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: daniel, TgrCc: Tgr, gerritbot, Aklapper, daniel, CucyNoiD, Nandana, NebulousIris, JKSTNK, Gaboe420
Tgr closed subtask T174035: Allow the view action to show multiple slots [MCR] as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T174036EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: daniel, TgrCc: CCicalese_WMF, gerritbot, Tgr, Anom
Tgr added a comment.
Some issues that we did not have time to fully discuss during the meeting:
sha1 B/C. There are two candidates for the old sha1 field: the sha1 of the main slot and the sha1 of the full revision (which is computed as taking the base36 sha1 of slot 1, concatenating the raw
Tgr added a comment.
We should probably undeprecate WikiPage::doEditContent and co. for 1.32. They refer the user to PageUpdater but that's still not stable and there is no officially supported way to acquire an instance.TASK DETAILhttps://phabricator.wikimedia.org/T196087EMAIL PREFERENCEShttps
Tgr added a comment.
FWIW it's not too hard to create your own high-level API on Toolforge (once Commons supports enough structured data) and it would probably provide useful feedback for the developers (much like WDQ did for WDQS).TASK DETAILhttps://phabricator.wikimedia.org/T585EMAIL
Tgr added a comment.
In T204136#4594581, @Whatamidoing-WMF wrote:
@JJMC89, these templates seem to have been imported to several wikis.
People using Special:Export to import enwiki templates with all dependencies, I guess?
We could make {{SHORTDESC}} be a noop instead of not recognized at all
Tgr closed subtask T194048: Introduce RevisionRenderer (baseline) as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T174035EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: daniel, TgrCc: Tgr, gerritbot, Aklapper, daniel, Gaboe420
Tgr closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T194048EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: daniel, TgrCc: Jdforrester-WMF, Tgr, gerritbot, Aklapper, daniel, Gaboe420, Versusxo, Majesticalreaper22, G
Tgr added a comment.
Test plan:
do multi-slot edit (from shell), muti-slot page creation (from shell), null edit, null revision (page move)
test REVISION* magic words
verify slot headers
test metadata merge - for now just with a single-slot edit since we won't have nontrivial metadata in non
Tgr added a comment.
It's not clear to me what this task is about. It mostly seems to describe T200216: Make undo work with SDC by showing a UI to confirm undo without allowing an edit (which got merged). Is it about doing the same thing from within EditPage (or whatever it gets refactored
Tgr closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T200216EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, TgrCc: daniel, Liuxinyu970226, TomT0m, Smalyshev, Lokal_Profil, -jem-, Aklapper, Anomie, CCicales
Tgr closed subtask T200216: Make undo work with SDC by showing a UI to confirm undo without allowing an edit as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T189808EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: gerr
Tgr closed subtask T200216: Make undo work with SDC by showing a UI to confirm undo without allowing an edit as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T194750EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: Cparle, Akla
Tgr closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T200569EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, TgrCc: gerritbot, daniel, Fjalapeno, Tgr, CCicalese_WMF, Aklapper, stebsco, Gaboe420, Versusxo, Majestic
Tgr closed subtask T200569: Make ApiComparePages API module aware of MCR as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T174032EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Anomie, TgrCc: Tgr, Fjalapeno, gerritbot, Aklapper, danie
Tgr closed subtask T200569: Make ApiComparePages API module aware of MCR as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T194750EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: Cparle, Aklapper, Abit, Ramsey-WMF, daniel, ste
Tgr added a comment.
Handling this in Vagrant is not hard, but Vagrant is not the only one using separate composer install commands per extension; some wikifarms do that due to composer being unwieldy with lots of dependencies. So it would be better if Wikibase supported that pattern
Tgr added a comment.
Moving back to review as all dependencies (452470, 452413) are also up for review.TASK DETAILhttps://phabricator.wikimedia.org/T194731EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: TgrCc: Jdlrobson, pmiazga, Aklapper, gerritbot, daniel
Tgr added a comment.
Thanks!
In T194731#4499846, @pmiazga wrote:
MobileFrontend uses different DiffEngine (it's hardcoded), this is something you have to talk to Reading Web
Yeah, that's tracked in T201842.
I also remember there is a work on a different engine that nicely shows when stuff
Tgr added a comment.
Vagrant throws this every time it tries to do something with MediaWiki (that is, run some maintenance script) so the full log is not super useful.
As I said, this is caused by extensions/Wikibase/vendor/autoload.php not being loaded. The way Vagrant is set up (and many third
Tgr added a comment.
In T194731#4498690, @daniel wrote:
We'll need a ticket for that, and we need to figure out who can do this, and when.
T201842: Use ContentHandler to obtain DifferenceEngine in MobileFrontend
How urgent is this? Do I understand correctly that this causes fatal errors when
1 - 100 of 274 matches
Mail list logo
