Page MenuHomePhabricator

Solution for disabling Flow on a page
Open, MediumPublic


This is broken out from T72073: U4. Special page to enable Flow on existing wikitext talk pages, auto-archiving the wikitext page (v2). However, I suggest we have a meeting, as there are some issues with the "convert to wikitext" approach:

Similar to enabling, we will create a special page to *disable* Flow on a page/set of pages. This will create a revision that changes the contentmodel of the page back to "wikitext".

  • The user right for this special page determines who can do this
    • initially restricted to Flow team, eventually wiki admins get the right.

The new wikitext revision of the Flow page would contain the Flow board converted back to text. There are two forms it could take:

  • The script Flow/maintenance/convertToText.php that converts Flow board to wiki text. Sample conversion
  • A variant of this script that outputs the Flow board header followed by a list of links to the Topic: *UUID* pages, maybe with summary information. ---


  • How does disable relate to $wgFlowOccupyNamespaces? E.g. if Flow is enable on User_talk: can it still be disabled for a particular page? For a subpage like User_talk:Brandon/My_experiment ? (it would already be off for the subpage (I don't think the struck-through part is true anymore, since we changed how namespace occupation works))
  • When enabling, what happens if Flow is disabled: we have [a script](https://tr​ (which needs to be updated f​or API changes) to convert a Flow board to wikitext, and/or the Flow version cou​ld be moved to a Talk:_SomePage_/FlowArchive

Related Objects

Event Timeline

Mattflaschen-WMF raised the priority of this task from to Needs Triage.
Mattflaschen-WMF updated the task description. (Show Details)

I'm not sure we need to implement converting to wikitext.

You can just move the Flow board and protect it (this could be done automatically by a special page if we think it's a common issue). Converting to wikitext would be needed is if you wanted to uninstall Flow completely, but that's not happening currently.

It's very hard to adequately preserve the attribution information from Flow in a wikitext page, and currently this code is not doing so. It doesn't attribute anyone for header and the same issue would occur for summary (for header especially, that could be a fair amount of work on a real talk pages). It doesn't attribute people who edit posts (which now any auto-confirmed user can do).

It also doesn't preserve the summary at all, but that could easily be fixed.

We should check with legal about whether it's okay to discard edit history like this (it's definitely very problematic).

Mattflaschen-WMF set Security to None.
Mattflaschen-WMF updated the task description. (Show Details)
Mattflaschen-WMF updated the task description. (Show Details)
DannyH triaged this task as Medium priority.Apr 17 2015, 5:33 PM
DannyH added a subscriber: DannyH.

It's very hard to adequately preserve the attribution information from Flow in a wikitext page, and currently this code is not doing so.

To elaborate on this, proper attribution could be done with synthetic edits under the correct username. Basically, replay the board in time order:

  1. If a topic is created, create a section under the right user.
  2. If an action occurs within a topic (including creation or edit of summary), serialize the whole topic (including summary), and make a section edit (replacing the whole section) under the user that did the action (TEST: multiple sections with same topic title),
  3. If a header is created or edited, edit the lede.

In the course of writing this, I refined my thoughts above, and it doesn't seem as hard as I previously thought.

We need to discuss, though.

Note, the above requires that the conversion script actually does the edits in a cron job/deferred, rather than just outputting text (with just one output/one edit, there is no proper attribution).

Temporarily protecting the page while these edits are made would help ensure the correct diffs.

The hardest part of the above is snapshotting a topic at a point in time (and finding all the right revisions at that time).

The link to the sample conversion in the description of this task is broken.

The link to the sample conversion in the description of this task is broken.

Added as part of the spec for T90075: Update and retest the convertToText script (if we were to use the script, we would need to update it first anyway, then produce another sample)

Just a sugestion: what about a special page (Special:DisableFlow) to do the contrary that Special:EnableFlow do?

I'm not sure we need to implement converting to wikitext.

As previously discussed e.g. around, enabling Flow is a quite disruptive change on a wiki (for example the default edit experience with basic things such as the edit button and links changes dramatically on talk pages), so it should not be irreversible. A wiki should be able to uninstall Flow without harmful consequences.

Discussion are often an important part of the history of pages, especially on public wikis, so they need a long-term digital preservation plan. Preserving the content as wikitext is the first step to ensure its preservation, although ideally we'd also preserve the history of edits and authors as well as incoming links.

The multiline list item RfC isn't strictly a necessity, but having it would make it much simpler to serialize Flow discussions into wikitext without having to worry about the many edge-cases around using wikitext lists to indent content that might contain tables, multiline templates, and other multiline tags which would be broken by just indiscriminately adding :::: to the start of every line...