daniel added a comment.
In T213318#4938904, @Anomie wrote:
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
daniel added a project: Release-Engineering-Team (Kanban).
TASK DETAILhttps://phabricator.wikimedia.org/T198342EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Aklapper, aude, Addshore, Anomie, Jdforrester-WMF, Tgr, gerritbot, daniel, EvanProdromou
daniel added a subscriber: BPirkle.daniel added a comment.
@BPirkle want to look into this? No need to drop other stuff if you are busy. This is just something that's coming up, and seems like something you could take on.TASK DETAILhttps://phabricator.wikimedia.org/T198557EMAIL PREFERENCEShttps
daniel edited projects, added Core Platform Team Kanban; removed Core Platform Team Backlog (Later).
TASK DETAILhttps://phabricator.wikimedia.org/T198341EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: gerritbot, Tgr, Jdforrester-WMF, Anomie
daniel closed this task as "Resolved".daniel claimed this task.daniel added a comment.
This is done. We still have the old fields in the database, and we still write to them. Changing that is tracked in T184615: Once MCR is deployed, drop the rev_text_id, rev_content_model, and rev_cont
daniel closed subtask T174044: Deploy MCR storage layer as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T174043EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Jdforrester-WMF, Aklapper, daniel, EvanProdromou, Nandana, JK
daniel added a parent task: T184615: Once MCR is deployed, drop the rev_text_id, rev_content_model, and rev_content_format fields to be dropped from revision.
TASK DETAILhttps://phabricator.wikimedia.org/T198341EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
daniel added a comment.
This is the same kind of storage need that is currently causing problems here: T210548: gzip-encoded page properties can't be exported from the APITASK DETAILhttps://phabricator.wikimedia.org/T214362EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
daniel added a comment.
See also T205444: Provide a way of having a meaningful slot headerTASK DETAILhttps://phabricator.wikimedia.org/T214267EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: BPirkle, danielCc: daniel, Aklapper, Bugreporter, EvanProdromou
daniel removed daniel as the assignee of this task.
TASK DETAILhttps://phabricator.wikimedia.org/T198342EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Aklapper, aude, Addshore, Anomie, Jdforrester-WMF, Tgr, gerritbot, daniel, EvanProdromou
daniel added a subtask: T198341: Remove all references to the rev_text_id and ar_text_id fields.
TASK DETAILhttps://phabricator.wikimedia.org/T198557EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Fjalapeno, CCicalese_WMF, Aklapper, daniel
daniel added a parent task: T198557: Remove support for legacy pre-MCR schema.
TASK DETAILhttps://phabricator.wikimedia.org/T198341EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: gerritbot, Tgr, Jdforrester-WMF, Anomie, Addshore, aude, Aklapper
daniel added a subtask: T198706: Make BackupDumper, WikiExporter and XmlDumpWriter compliant with the MCR revision retrival mechanism (main slot only).
TASK DETAILhttps://phabricator.wikimedia.org/T214308EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
daniel added a parent task: T214308: Force usage of MCR aware database schema.
TASK DETAILhttps://phabricator.wikimedia.org/T198706EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: ArielGlenn, gerritbot, CCicalese_WMF, Aklapper, Fjalapeno, daniel
daniel updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...This becomes possible when there are no morerequires the removal of all references to rev_text_id and ar_rev_idd, and any other direct access to the legacy schema, in the code base //(including extensions)//.TASK
daniel created this task.daniel triaged this task as "Normal" priority.daniel added projects: Wikidata, MW-1.33-release, Core Platform Team (MCR), Core Platform Team Backlog (Later), Multi-Content-Revisions (Tech Debt).
TASK DESCRIPTIONBy the next release (1.33), MediaWiki should no long
daniel added a comment.
The non-nodejs fallback (even with limitations) addresses my concerns. I still wouldn't want this to become one of a kind, but rather have this architecture to be an example solution that also others can and will use.
I agree that we shouldn't end up with a zoo
daniel added a comment.
@Nikerabbit so, if you don't have the node service, you have no support for clients that can't do the client side rendering, and no optimization for anon visitors. But it would still work.TASK DETAILhttps://phabricator.wikimedia.org/T213318EMAIL PREFERENCEShttps
daniel added a comment.
So, in conclusion, Wikidata has a lot of edits, but several magnitudes fewer views than a Wikipedia of comparable size. So, while MediaWiki generally optimizes for heavy read loads, the Wikidata UI should be optimized for frequent edits, but doesn't have to worry about
daniel added a comment.
24% of all wikimedia pageviews are for Wikidata? I find that extremely surprising. Is that on the app servers, or does it include CDN cache hits?
It's even more surprising since most edits on Wikidata are done by bots (which don't trigger page views), and since you can
daniel added a comment.
The reason this is a dedicated service is the language it is written in (typescript), which was chosen because it allows us to create an implementation which can be compiled/transpiled to work on both server and client - something not possible with PHP.
For the concrete
daniel added a comment.
A quick note on how Wikidata is different, particularly from Wikipedia:
The Wikidata website is primarily an editing tool. It doesn't really have readers, the information is mainly displayed elsewhere, e.g. in Wikipedia articles.
This means the performance trade-offs
daniel added a comment.
Did the chat with @Joe happen? What was the outcome?TASK DETAILhttps://phabricator.wikimedia.org/T212189EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: fselles, CDanis, akosiaris, Krinkle, Milimetric, daniel, mobrovac, Joe
daniel closed subtask T107595: [RFC] Multi-Content Revisions as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T146637EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_Pintscher, danielCc: Esc3300, Aklapper, Lydia_Pintscher, Nickle
daniel closed this task as "Resolved".daniel added a comment.
This RFC is done. The storage layer of MCR is implemented and deployed. Further refactoring and new features building on top of that will be discussed in separate RFCs if needed.TASK DETAILhttps://phabricator.wikimedia.org/T1
daniel removed a subtask: T198492: Drop rev_text_id and ar_text_id when running update.php.
TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, danielCc: Bianjiang, Nirmos, CCicalese_WMF, PokestarFan
daniel edited parent tasks, added: T174043: Deploy Multi-Content Revisions, T174022: Implement multi-content revisions; removed: T107595: [RFC] Multi-Content Revisions.
TASK DETAILhttps://phabricator.wikimedia.org/T198492EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
daniel added a subtask: T198492: Drop rev_text_id and ar_text_id when running update.php.
TASK DETAILhttps://phabricator.wikimedia.org/T174043EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Jdforrester-WMF, Aklapper, daniel, EvanProdromou, Nandana
daniel added a subtask: T198492: Drop rev_text_id and ar_text_id when running update.php.
TASK DETAILhttps://phabricator.wikimedia.org/T174022EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Magol, Lokal_Profil, AfroThundr3007730, Agabi10
daniel added a comment.
@Krinkle said:
Rather, it starts out on the assumption that we're going to have UI code in production (based on Vue.js) written in a way that contains too much business logic in its templating code.
That is correct: the Wikidata team made the determination that they want
daniel added a comment.
As far as I can see, the situation is this: Option 1 is ruled out already, since data access from wikitext doesn't work with that approach. Options 2 would need community consensus. Option 3 (default repo per entity type, with prefixes used internally) is still on the table
daniel added a comment.
@Joe said:
the SSR service should not need to call the mediawiki api. It should accept all the information needed to render the termbox in the call from mediawiki.
After talking to the Wikidta folks, I realized that this is not easy at all. It requires the callingg code
daniel added a comment.
For the record, the revert should be temporary, on the deployment branch, not on master. This is exposing a problem in the calling code, which needs to be addressed. The revert is not a proper fix, just a stop-gap.TASK DETAILhttps://phabricator.wikimedia.org/T212427EMAIL
daniel added subscribers: Pablo-WMDE, Lucas_Werkmeister_WMDE, Jakob_WMDE.daniel added a comment.
Pinging @Jakob_WMDE and @Pablo-WMDE, since the rest of the Wikidata team is already out for the holidays. Pinging @Lucas_Werkmeister_WMDE, since he probably knows most about wbcheckconstraints.
Quick
daniel added a comment.
You first need to render the page on the server before you know whether the client supports JS/SW or not, so it will need to be rendered on the server irrespective of the client's capabilities in case where MW calls the service directly before handing out the page.
Yes
daniel added a comment.
When rendering the page, index.php knows the exact data that needs to be rendered already, correct?
I just had a brief chat with @Jakob_WMDE and @Pablo-WMDE about this. For the current use case ("term box"), this would be easy, but for the anticipated generalize
daniel added a comment.
In T212189#4837780, @mobrovac wrote:
When rendering the page, index.php knows the exact data that needs to be rendered already, correct? If so, it can send that to the client, and then based on whether JS/SW is available or not, the client either renders it or sends
daniel added a comment.
@Milimetric wrote:
In the simplest case, this code would be almost identical client and server-side. No matter where it's running, nodejs or the browser, it would request data, receive it, and render it as html.
I think you are right, that does make sense
daniel added a subscriber: Lydia_Pintscher.daniel added a comment.
ping LydiaTASK DETAILhttps://phabricator.wikimedia.org/T211800EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Lydia_Pintscher, Addshore, MarkTraceur, WMDE-leszek, Cparle, Jdforrester
daniel added a comment.
Well, I consider calling the MW api from a service called by MediaWiki an antipattern that we should absolutely avoid.
Oh, I got that wrong - I thought the service would be public facing and called directly from the client! But apparently, itt's not, it would be hidden
daniel added a comment.
In T211800#4831696, @WMDE-leszek wrote:
As I am gone for two more weeks, it would probably the best that I shortly answer here: to me it seems both kinds of federation are completely separate and possibly even mutually exclusive. So I would rather not mix these, neither
daniel added a comment.
I agree with Joe that it would be better to have the service be internal, and be called from MW. It doesn't have to be that way, but it's preferable because:
we would not expose a new endpoint
we should in general avoid (more) services calling MediaWiki, because:
PHP has
daniel added a comment.
Using accept-language is not an option, at least not the accept-language from the browser. The relevant list of languages comes from user preferences and the Babel extension. This also means that it typically contains more than one language, and there are many, many
daniel moved this task from Ready to Waiting for Review on the Core Platform Team Kanban board.daniel edited projects, added Core Platform Team Kanban (Waiting for Review); removed Core Platform Team Kanban.
TASK DETAILhttps://phabricator.wikimedia.org/T174031WORKBOARDhttps
daniel added a comment.
@mobrovac Please note that the term box is shown based on user preferences (languages spoken), the initially served DOM however needs to be the same for all users, so it can be cached. Also note that the language specific data that goes into the term box has to be loaded
daniel added a comment.
A detail to consider when going for "federation without prefixes": does this mean no prefixes just for user input, or also in the JSON serialization? Using no prefixes there either may seem intuitive, but it make the data more brittle, and harder to exchan
daniel added a comment.
In T211800#4830605, @WMDE-leszek wrote:
Having two not-necessarily same config flying around and parts of code arbitrarily picking one config, and other parts picking up the other seems like a bug/unfinished implementation to me. I am surprised it only surfaces now
daniel added a comment.
One source of confusion is the fact that the CachingPropertyInfoLookup used by client code and repo code are hitting the same cache entry. That cache entry ends up containing both prefixed (wikidata:P1) and unprefixed (just P1) property IDs, side by side. This in turn
daniel added a comment.
I have confirmed locally that the current situations prevents access to MediaInfo entities using the {{#statements}} (nor presumably from Lua, which uses the same underlying mechanism). This means that MediaInfo cannot be used on file description pages as intended, until
daniel closed subtask T73781: Add support for a "Multi-Part" content model for use with MediaInfo / structured meta-data as "Invalid".
TASK DETAILhttps://phabricator.wikimedia.org/T68108EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/T
daniel closed this task as "Invalid".daniel added a comment.
Superseded by MCR.TASK DETAILhttps://phabricator.wikimedia.org/T73781EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Wikidata-bugs, GPHemsley, Bene, Legoktm, Gilles, jayvdb,
daniel closed subtask T73781: Add support for a "Multi-Part" content model for use with MediaInfo / structured meta-data as "Invalid".
TASK DETAILhttps://phabricator.wikimedia.org/T66288EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/T
daniel added a comment.
I just realized that this probably blocks access to MediaInfo from wikitext on commons. I have not confirmed this, but if my mental model is right, this needs to be fixed before we'll be able to access MediaInfo from wikitext.TASK DETAILhttps://phabricator.wikimedia.org
daniel added a comment.
For option three, we'd have to decide whether the per-entity-type-defaults should be defined separately from the prefix mapping, or whether it should use some kind of special syntax., I'd suggest the hybrid approach we have also been using for including the target slot
daniel added a comment.
This needs a (minor) release of wikibase/data-model-serialization.TASK DETAILhttps://phabricator.wikimedia.org/T211927EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Jdforrester-WMF, Addshore, WMDE-leszek, Aklapper, daniel
daniel added a comment.
Pull request: https://github.com/wmde/WikibaseDataModelSerialization/pull/250TASK DETAILhttps://phabricator.wikimedia.org/T211927EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Jdforrester-WMF, Addshore, WMDE-leszek, Aklapper
daniel closed this task as "Resolved".daniel added a comment.
Thanks for testing, James!TASK DETAILhttps://phabricator.wikimedia.org/T204748EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, danielCc: daniel, Abbe98, Stashbot, Abit,
daniel created this task.daniel added projects: Wikidata, SDC Engineering, Wikibase-DataModel-Serialization.Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTIONTo provide consistent mapping of entity ID prefixes for entity data loaded from foreign repos, SnakDeserializer must
daniel closed subtask T211801: Find out how to deploy MediaInfo without breaking Commons as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T204748EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, danielCc: daniel, Abbe98, Stas
daniel added a comment.
In T204748#4820156, @Cparle wrote:
So should MediaInfo items have the page namespace, or their own namespace?
There is no page namespace (or rather, all namespaces are page namespaces). MediaInfo lives in the File names (ID 6), in the mediainfo slot.TASK DETAILhttps
daniel added a comment.
In T204748#4820069, @Cparle wrote:
If MediaInfo items only exist as slots, then I don't really understand why they need a namespace
Because slots are on pages, and pages are in namespaces. Every entity type has a namespace and a slot.TASK DETAILhttps
daniel added a comment.
In T204748#4819946, @daniel wrote:
I don't think this is the reason that MediaInfo doesn't work on beta, though. That still needs more investigation.
After some investigation, I now believe that they have a common cause: EntityNamespaceMapping is initialized
daniel added a comment.
In T204748#4784693, @gerritbot wrote:
Change 476403 merged by Ladsgroup:
[mediawiki/extensions/WikibaseMediaInfo@master] Don't check for integer namespace in MediaInfoIdLookup
https://gerrit.wikimedia.org/r/476403
That fix is wrong, and hiding an error. It should
daniel added a subtask: T211801: Find out how to deploy MediaInfo without breaking Commons.
TASK DETAILhttps://phabricator.wikimedia.org/T204748EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, danielCc: daniel, Abbe98, Stashbot, Abit, ArielGlenn
daniel updated the task description. (Show Details)
CHANGES TO TASK DESCRIPTION...However, as Commons is becoming a WikibaseRepo in its own right to support SDC by running the WikibaseMediaInfo extension, the empty ID prefix will now conceptually refer to the local repo, that is, commons itself
daniel created this task.daniel added projects: Commons, SDC General, Wikidata, MediaWiki-extensions-WikibaseRepository.Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTIONWikimedia Commons has been a WikibaseClient for several years now, accessing data from Wikidata, using entity
daniel added a parent task: T211799: Make RDF prefixes configurable.
TASK DETAILhttps://phabricator.wikimedia.org/T194180EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: daniel, Smalyshev, Aklapper, Lucas_Werkmeister_WMDE, Nandana, Lahi, Gq86
daniel added subtasks: T196042: Configurable RDF prefixes for WDQS, T194180: Make WDQS UI’s RDF namespaces and standard prefixes configurable.
TASK DETAILhttps://phabricator.wikimedia.org/T211799EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc
daniel added subscribers: LucasWerkmeister, Lydia_Pintscher.daniel added a comment.
ping @LucasWerkmeister @Lydia_PintscherTASK DETAILhttps://phabricator.wikimedia.org/T211799EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Lydia_Pintscher
daniel added a parent task: T211799: Make RDF prefixes configurable.
TASK DETAILhttps://phabricator.wikimedia.org/T196042EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Seb35, tk, Aklapper, Smalyshev, Addshore, Tarrow, Nandana, Lahi, Gq86
daniel created this task.daniel added projects: Wikidata, MediaWiki-extensions-WikibaseRepository.Restricted Application added a subscriber: Aklapper.
TASK DESCRIPTIONThe prefixes Wikibase uses for Turtle and RDF/XML output are hardcoded in the RdfVocabulary class. It would be nice if they were
daniel renamed this task from "Configurable RDF prefixes" to "Configurable RDF prefixes for WDQS".
TASK DETAILhttps://phabricator.wikimedia.org/T196042EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Seb35, tk, Aklapper, Smalysh
daniel added a comment.
Is this the same as T196042: Configurable RDF prefixes?TASK DETAILhttps://phabricator.wikimedia.org/T194180EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: daniel, Smalyshev, Aklapper, Lucas_Werkmeister_WMDE, Nandana, Lahi
daniel added a comment.
I have a suspicion about this, but I want to dog some more. But if I am correct, this never work on beta, at least not with MediaInfo in slots, with the config that is there now.
@Jdforrester-WMF is it possible that you remember this working on the dedicated labs test
daniel claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T211237EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: TerraCodes, Liuxinyu970226, daniel, gerritbot, Addshore, Ladsgroup, Jdforrester-WMF, Aklapper, CucyNoiD, Nandana
daniel moved this task from Ready to Doing on the Core Platform Team Kanban board.daniel edited projects, added Core Platform Team Kanban (Doing); removed Core Platform Team Kanban.
TASK DETAILhttps://phabricator.wikimedia.org/T211237WORKBOARDhttps://phabricator.wikimedia.org/project/board/3696
daniel added a project: Core Platform Team Kanban.
TASK DETAILhttps://phabricator.wikimedia.org/T211237EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: TerraCodes, Liuxinyu970226, daniel, gerritbot, Addshore, Ladsgroup, Jdforrester-WMF, Aklapper
daniel added a comment.
I know next to nothing about how the beta instances work, I'll probably need to hack around in them directly... I'll probably need some help with that.TASK DETAILhttps://phabricator.wikimedia.org/T211237EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
daniel added a comment.
This is UBN. WBMI on Beta Commons is useless (no edits possible at all).
So the prio is set to "needs triage", it's in the wikidata inbox, the MediaInfo backlog well, I'll just take your word for it :)
Has anyone been able to reproduce this locally?TASK D
daniel added a comment.
If this becomes urgent, I could probably dig in. I'd need good justification to spend time on this, though. In theory, this should be handled by the Wikidata team. On the other hand, there's a non-zero chance that this is something I screwed up :)TASK DETAILhttps
daniel closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T194046EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: CCicalese_WMF, gerritbot, Aklapper, daniel, CucyNoiD, Nandana, NebulousIris, Gaboe420
daniel added a comment.
In T211237#4803774, @Jdforrester-WMF wrote:
The only place this is configured (I thought) is https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings-labs.php where 'entityNamespaces' => [ 'mediainfo' => '6/mediainfo' ], is set for Commons;
That lo
daniel added a comment.
In the light of T211052, maybe the problem is that Wikibase is trying to read from the Main slot, instead of the mediainfo slot.TASK DETAILhttps://phabricator.wikimedia.org/T211237EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
daniel moved this task from Doing to Waiting for Review on the Core Platform Team Kanban board.daniel edited projects, added Core Platform Team Kanban (Waiting for Review); removed Core Platform Team Kanban (Doing).
TASK DETAILhttps://phabricator.wikimedia.org/T194046WORKBOARDhttps
daniel lowered the priority of this task from "Normal" to "Low".daniel removed daniel as the assignee of this task.daniel edited projects, added Core Platform Team Backlog (Later); removed Core Platform Team Kanban (Doing), SDC Engineering.daniel added a comment.
Low prio
daniel added a comment.
In T209927#4763519, @Anomie wrote:
This makes no sense to me. What does "offered for editing" actually mean in a practical sense? Why would some code somewhere call getDesiredSlots() instead of getAllowedSlots()?
My thinking was that getAllowedSlots() m
daniel added a parent task: T174033: Refactor EditPage to allow multiple slots to be edited atomically [MCR].
TASK DETAILhttps://phabricator.wikimedia.org/T209927EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Anomie, Aklapper, gerritbot, daniel
daniel added a comment.
As stated in the task description, my idea was to somehow communicate which slots should be offered for editing. It's however unclear how that should be done for slots that do not support direct (text based) editing, unless we also provide a mechanism for EditPage plug-ins
daniel added a parent task: T209878: Allow control of page layout of multiple slots during rendering.
TASK DETAILhttps://phabricator.wikimedia.org/T205459EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Cparle, Aklapper, gerritbot, daniel, CucyNoiD
daniel added a subscriber: Anomie.daniel added a comment.
Copied from https://gerrit.wikimedia.org/r/c/mediawiki/core/+/434544/32/includes/Revision/SlotRoleRegistry.php#183, for further discussion here:
@Anomie:
I'm not so sure of this. A TemplateStyles stylesheet slot on a template should
daniel removed a project: Core Platform Team Kanban (Doing).
TASK DETAILhttps://phabricator.wikimedia.org/T209927EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: Aklapper, gerritbot, daniel, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden
daniel created this task.daniel triaged this task as "Normal" priority.daniel added projects: Wikidata, Patch-For-Review, SDC Engineering, Multi-Content-Revisions (New Features), Core Platform Team (MCR), Core Platform Team Kanban (Doing).Restricted Application removed a project: Patch-
daniel closed subtask T195212: ServiceContainer: Allow extensions to manipulate services upon creation as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T205891EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: daniel, Agabi
daniel closed this task as "Resolved".daniel added a comment.
Patch was merged long agoTASK DETAILhttps://phabricator.wikimedia.org/T195212EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: gerritbot, Aklapper, Tgr, daniel, Nandana,
daniel added a subtask: T209878: Allow control of page layout of multiple slots during rendering.
TASK DETAILhttps://phabricator.wikimedia.org/T205891EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: daniel, Agabi10, Cparle, Aklapper, Jdforrester-WMF
daniel added a parent task: T209924: Introduce PageTypeHandler.
TASK DETAILhttps://phabricator.wikimedia.org/T194046EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: gerritbot, Aklapper, daniel, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo
daniel removed a subtask: T195212: ServiceContainer: Allow extensions to manipulate services upon creation.
TASK DETAILhttps://phabricator.wikimedia.org/T194046EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: gerritbot, Aklapper, daniel, CucyNoiD
daniel added a subtask: T195212: ServiceContainer: Allow extensions to manipulate services upon creation.
TASK DETAILhttps://phabricator.wikimedia.org/T205891EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: daniel, Agabi10, Cparle, Aklapper
daniel edited parent tasks, added: T205891: Display WikibaseMediaInfo captions block on the File page immediately after the file links, before the content of the wikitext block; removed: T194046: Introduce SlotRoleHandler and SlotRoleRegistry for declaring slot roles..
TASK DETAILhttps
daniel added a parent task: T205459: Decide how SlotRoleHandlers can provide placeholders for missing slots.
TASK DETAILhttps://phabricator.wikimedia.org/T194046EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: gerritbot, Aklapper, daniel, CucyNoiD
301 - 400 of 5223 matches
Mail list logo
