Last modified: 2013-06-18 16:57:20 UTC
For backwards-compatibility, the API should be able to use &action=edit§ion=new regardless of whether the talk page uses LiquidThreads. If it uses LiquidThreads, it should just add a thread. If not, it should add a section (as it has historically). The idea here is that script writers should not have their scripts broken by the introduction of LiquidThreads to a wiki. In addition, some wikis use LiquidThreads on a per-page basis arbitrarily (using {{UseLiquidThreads:1}}. There must be a way to post a new section to the page regardless of whether the page currently uses LiquidThreads. Again, requiring script writers to write new and more complex code doesn't seem like the nicest or most reasonable solution here. Something built in to the extension seems best.
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§ion=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§ion=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§ion=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§ion=new on frontend it is creating a new thread on that page. The api should act the same way.
Created attachment 7509 [details] 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.
(In reply to comment #4) > Exactly how and how badly would things break for old clients blindly doing > action=edit§ion=new anyway? Anyone?
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.
