cbm.wikipedia wrote:

This is particularly important for bots that post to talk pages. Even if section=new doesn't work, there needs to be an automated way to detect via the API whether liquidthreads is in use, and a way to post a new thread via the API if it is.

I'm not sure the best approach is to simply expose whether LQT is used or not. I think the best approach is to either redirect the request appropriately or change the software to support &action=edit&section=new with LQT. Breaking all of the scripts that currently post to talk pages with the API (and requiring them to add an additional check and write further code) seems unnecessary here.

Maybe it won't break anything in use right now, but editing a new section is thoroughly distinct from posting a new thread — it just happens that one of the uses of editing a new section is adding a new thread on a talk-page that does not use LiquidThreads.

It seems like the sort of thing that would unexpectedly break scripts — it's fine to try to read a user's mind, but not a programmer's mind.

Throwing up some extra CCs for other opinions.

I recommend adding a useslqt="" attribute (or something along those lines) to prop=info so clients can tell the page they wish to edit uses LQT and know they should use LQT's thread creation API module instead (if this doesn't exist, write one).

Exactly how and how badly would things break for old clients blindly doing action=edit&section=new anyway?

(In reply to comment #2)

I'm not sure the best approach is to simply expose whether LQT is used or not.
I think the best approach is to either redirect the request appropriately or
change the software to support &action=edit&section=new with LQT. Breaking all
of the scripts that currently post to talk pages with the API (and requiring
them to add an additional check and write further code) seems unnecessary here.

That is the best way. It is see same way, as the normal EditPage do. When call action=edit&section=new on frontend it is creating a new thread on that page. The api should act the same way.

john wrote:

Patch to add a ' useslqt="" ' tag on prop=info

Patch adds a hook to LiquidThreads that on prop=info if the page uses LiquidThreads a ' useslqt="" ' tag is added.

Attached:

(In reply to comment #4)

Exactly how and how badly would things break for old clients blindly doing
action=edit&section=new anyway?

Anyone?

soxred93 wrote:

Fixed with r70638 and r70729. As LiquidThreads usage is stored in the page_props table, if LiquidThreads registers its names with $wgPageProps, it should show up in the prop=pageprops module.

LiquidThreads usage *overrides* are stored in page_props, but a naïve client which just checked pageprops would not take into account the default.

(In reply to comment #9)

LiquidThreads usage *overrides* are stored in page_props, but a naïve client
which just checked pageprops would not take into account the default.

Yeah, that should be fixed. Either LiquidThreads status should be explicit for each page (i.e., have a row for every page in page_properties) or have the API check the page status and the API can take into the namespace defaults set by global variables and return an appropriate result based on the input title(s).

Thanks for giving me that patch, John. I've (finally) applied it in r111185.

Marking RESOLVED FIXED.