Sun, Jul 15
Fri, Jul 13
Unrelated to MCR.
Caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/443964, I made a revert, see https://gerrit.wikimedia.org/r/c/mediawiki/core/+/445658.
I don't think this is caused by MCR, but until we are sure, I moved it to the storage layer workboard.
Thu, Jul 12
an "undo without edit" could have all fields' content as <input type="hidden"> or as data stored in the session server-side.
maybe we need undo-without-edit anyway if some slots don't support editing but support undo?
The longer I think about this, the more I want ParserOptions creation to have a Title for context.
The reason is that default parser behavior may vary with the type of page. The special case for conversion tables in WikiPage::makeParserOptions() is the point in case.
I have been working on one corner of the SiteInfo stuff at the hackathon again. I should sit down with Amir to discuss next steps. The implementation is not so hard, what is tricky is staying compatible with configuration manually added to existing installs.
Dropping this off the SDC board, since full implementation of this is not necessary for SDC. Some of the subtasks are needed, and they remain on the SDC board.
Closing RFC since consultation is done, implementation is tracked at T194037: Track dependencies for multiple Content objects per page
Title is the equivalent of the normalization of comment
Wed, Jul 11
A few thoughts:
The way languages work is quite terrible, see e.g. T114640: RFC: make Parser::getTargetLanguage aware of multilingual wikis. We'll probably not resolve this here. Passing the Title just makes the interface more future proof, it would be ignored for now.
Quiet a few things use JSON based content models to store structured data. Sadly, they tend to not have good UI. So that would need to be written. But that would also need to be written when basing this on Wikibase. Unless you want free form modeling of users.
I don't quite get the rationale behind this. There seems to be an idea that Wikibase is the preferred mechanism for storing structured data in MediaWiki. That's a bit off.
I just rebased the patch, should be ready to be merged
@jcrespo All the info you requested should already be in the task description:
- new tables are already there, will be populated when T183488 is done, which is due to start happening in August, and will probably take to the end of September to complete on all wikis. The completion of this will be marked by T198308: Enable MCR migration stage "write both, read new" on live systems. At this point, the old fields can and should soon be hidden from the replica views.
- the old fields will stop being updated with T198312: Set the WMF cluster to use the new MCR-only schema, which is expected to happen some time in Q2. The query to use instead is given in the task description. At this point, the old fields must no longer be available in the replica views (this ticket).
- the old fields will be dropped from the revision and page tables... whenever it suits you. The plan says Q3, but there is no rush.
@jcrespo, @bd808 I have updated the task description with more details, and added a section with instructions for migrating tools. Do you think this is sufficient? Do you want me to send an email out, or will you do that?
I changed this ticket to ask for the affected fields to be hidden / dropped from the view, instead of trying to provide backwards compatibility.
@jcrespo I'm fine with not having all these joins. I'd suggest to hide the fields that will become unreliable instead, and do it soon. It will probably break some things, put probably not much, since there arn't terribly many use cases on labs for these fields anyway:
Tue, Jul 10
You are right, static factory methods on ParserOptions are probably the best choice for now. Ideally, ParserOutput is a plain value object, then we don't even need a factory - but even if we do, we can add that later.
@Tgr thank you for doing the survey!
Copy of @Tgr's comment at https://gerrit.wikimedia.org/r/c/mediawiki/core/+/441924#message-edcc2029a8d911da3ec680fb373cd10f9b0323a2, for further discussion here: