Page MenuHomePhabricator

S2. Flow API: Let code add a new topic with action=edit&section=new
Closed, DeclinedPublic2 Story Points

Description

LQT intercepts section=new from users to add a new thread (but not via the API, see bug 41276). It'd be really awesome if Flow could let you add a new topic like this, using the old API.

https://www.mediawiki.org/wiki/API:Edit#Example


See Also:

Details

Reference
bz57989

Related Objects

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:17 AM
bzimport set Reference to bz57989.
bzimport added a subscriber: Unknown Object (MLST).

See also bug 49636 which means that pointing MW's feedback tool at a Flow board won't work. Boo.

Quiddity removed a subscriber: Maryana.Dec 19 2014, 1:43 AM
Spage renamed this task from Flow: Let the user add a new topic by action=edit&section=new to Flow API: Let code add a new topic with action=edit&section=new.Jan 6 2015, 7:12 PM
Spage updated the task description. (Show Details)
Spage set Security to None.

See also bug 49636 which means that pointing MW's feedback tool at a Flow board won't work. Boo.

Now T51636: mediawiki.feedback fails badly when it can't write to the target page

Elitre added a subscriber: Elitre.Jan 8 2015, 5:11 PM

We can't convert the https://www.mediawiki.org/wiki/VisualEditor/Feedback LQT page to Flow until this is fixed. :-(

Mattflaschen-WMF raised the priority of this task from Low to Normal.Jan 8 2015, 7:33 PM

It also affects various other things, e.g. MoodBar (I know, I know, MoodBar's not widely used, but I hit it recently when testing an unrelated fix in MoodBar).

Plus, I'm sure it affects many things we're not thinking of.

DannyH renamed this task from Flow API: Let code add a new topic with action=edit&section=new to Flow API: Let code add a new topic with action=edit&section=new (LQT conversion).Jan 12 2015, 6:10 PM
Mattflaschen-WMF renamed this task from Flow API: Let code add a new topic with action=edit&section=new (LQT conversion) to Flow API: Let code add a new topic with action=edit&section=new (LQT parity).Jan 12 2015, 8:42 PM

This really doesn't have anything to do with LQT except that "It worked in LQT; it should work in Flow". We're not proposing any change to LQT, though.

Mattflaschen-WMF renamed this task from Flow API: Let code add a new topic with action=edit&section=new (LQT parity) to Flow API: Let code add a new topic with action=edit&section=new.Feb 25 2015, 7:55 PM
Mattflaschen-WMF updated the task description. (Show Details)
DannyH edited a custom field.Feb 25 2015, 7:55 PM

I still think this is a bad idea. It makes transition just a little bit easier, but it means that bots or tools that aren't Flow-aware are just going to more serious issues later on.

Tools like mw.feedback should allow Flow to override them to use its API or something.

I still think this is a bad idea. It makes transition just a little bit easier, but it means that bots or tools that aren't Flow-aware are just going to more serious issues later on.
Tools like mw.feedback should allow Flow to override them to use its API or something.

I think this will be good enough for some write-only tools (they may never need to update to explicitly be Flow-aware). Others definitely will need to, but this will hopefully ease the transition.

We definitely plan on working towards all tools handling Flow correctly; this is just one aspect of that.

We should discuss whether to try to make the output match, or just use the Flow output.

EBernhardson added a comment.EditedFeb 25 2015, 10:26 PM

I was initially thinking this was basically going to be a rewrite procedure:

  • receive api request, rewrite to flow api request
  • receive flow response, rewrite to look like normal api response.

Yeah, that sounds right. It looks like we're have to do some tricks with the revid (we also need to support at least XML and JSON, preferably all the output formats).

hmm, i guess we could be evil and give them the rev id of the page we just created in NS_TOPIC for it, but that probably wont be what they expect :) Will have to ponder this a bit.

In T59989#1067648, @Mattflaschen wrote:

I still think this is a bad idea. It makes transition just a little bit easier, but it means that bots or tools that aren't Flow-aware are just going to more serious issues later on.
Tools like mw.feedback should allow Flow to override them to use its API or something.

I think this will be good enough for some write-only tools (they may never need to update to explicitly be Flow-aware). Others definitely will need to, but this will hopefully ease the transition.

There are no 'write-only' tools, they all have some read actions. What happens if a page is protected? Or they trigger a captcha? Or (spam|title)blacklist/AF is hit? Is Flow going to re-write all of those error cases into their wikitext equivalents? Are we going to strip ~~~~ from posts because (last I checked) that doesn't work in Flow?

It will ease the transition by putting a band-aid over it, but it's going to hurt a lot more when you take that band-aid off.

We definitely plan on working towards all tools handling Flow correctly; this is just one aspect of that.

Why not just do that from the beginning? If someone tries action=edit on a Flow page, return an error so they're forced to fix the tool.

DannyH renamed this task from Flow API: Let code add a new topic with action=edit&section=new to S2. Flow API: Let code add a new topic with action=edit&section=new.Mar 11 2015, 9:41 PM
DannyH removed a project: Collaboration-Team-Triage.
Mattflaschen-WMF closed this task as Declined.Mar 11 2015, 11:20 PM
Mattflaschen-WMF claimed this task.

@Legoktm convinced us not to take this approach, at least for now.

We're instead going to target the sources (e.g. T91805: T7. Flow support for the mediawiki.feedback form), inform early adopters of user talk of this risk (T90383: give willing people an easy way to volunteer their user talk pages as a testing ground for Flow), and keep an eye out for reports of missing messages (then fix, or help authors' fix, them to support Flow).

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptJun 5 2015, 12:19 PM

Note: This has consequences (breakage) for some gadgets, such as
https://pl.wikipedia.org/wiki/Wikipedia:Narz%C4%99dzia/Odpowiedzi_z_linkami - A "replylinks" gadget at the Polish Wikipedia that adds an "[odp]" (or "[reply]") link after all userpage links, and when clicked, it creates a new user_talkpage section, using the heading of the section that the [reply] link was in.

E.g. Clicking [reply] at:


then opens that user's talkpage, and starts a new section, like so:

I believe, I should emphasize that this gadget is old (2006) and very popular among experienced Wikipedians, the core of plwiki community, who are likely to be concerned about next Flow releases, not only on personal talk pages. Just for the record, if action=edit&section=new isn't to be supported, please, create something instead.

I believe, I should emphasize that this gadget is old (2006) and very popular among experienced Wikipedians, the core of plwiki community, who are likely to be concerned about next Flow releases, not only on personal talk pages. Just for the record, if action=edit&section=new isn't to be supported, please, create something instead.

Our recommended solution is to use mw.messagePoster (which we implemented for this purpose). Usage:

	var title = new mw.Title( 'titleString' );
	var posterPromise = mw.messagePoster.factory.create( title );
	posterPromise.done( function ( poster ) {
		poster.post( 'This is the topic title', 'This is the body of a message posted with MessagePoster' );
	} );

The gadget should also depend on 'mediawiki.messagePoster' and 'mediawiki.Title' (user scripts can depend on those with mw.loader.using).

If you need further technical assistance, please ask (e.g. in #wikimedia-collaboration on IRC).

Note that will work for both wikitext and Flow, so the gadget does not need to know which the page is.

The above is for if you're trying to create the post immediately through the script.


It looks like for this example, you just want to prefill it (rather than use the API), then let the user edit before saving. Flow supports that too:

https://www.mediawiki.org/wiki/User_talk:Mattflaschen-WMF?topiclist_preloadtitle=Preloaded%20title&topiclist_preload=User:Mattflaschen-WMF/Preloaded%20body%20example

The preloadtitle is inlined. The preload is a template (in this example User:Mattflaschen-WMF/Preloaded body example.

This is basically the same as for old-style talk pages. For old-style, it's:

https://en.wikipedia.org/wiki/User_talk:Mattflaschen-WMF?preloadtitle=Preloaded title&preload=User:Mattflaschen-WMF/Preloaded body example&action=edit&section=new

In that case, you do currently need to check what kind of page it is, though, using prop=info:

https://en.wikipedia.org/w/api.php?action=query&titles=User%20talk:Mattflaschen-WMF&prop=info

vs.

https://www.mediawiki.org/w/api.php?action=query&titles=User%20talk:Mattflaschen-WMF&prop=info

There is a possibility to make this use case easier for script writers: T107637: Support single set of index.php parameters for pre-filling new topics for both old-style talk pages and Flow

He7d3r removed a subscriber: He7d3r.