Last modified: 2013-06-18 16:57:20 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T23256, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 21256 - Expose whether or not LiquidThreads is in use on a page with the API
Expose whether or not LiquidThreads is in use on a page with the API
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
LiquidThreads (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks: noncoreapi
  Show dependency treegraph
 
Reported: 2009-10-23 15:01 UTC by MZMcBride
Modified: 2013-06-18 16:57 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to add a ' useslqt="" ' tag on prop=info (1.32 KB, patch)
2010-06-24 14:40 UTC, John Du Hart
Details

Description MZMcBride 2009-10-23 15:01:45 UTC
For backwards-compatibility, the API should be able to use &action=edit&section=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.
Comment 1 CBM 2010-01-09 13:37:50 UTC
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. 
Comment 2 MZMcBride 2010-02-01 02:58:32 UTC
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.
Comment 3 Andrew Garrett 2010-02-01 03:02:02 UTC
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.
Comment 4 Roan Kattouw 2010-02-01 15:39:21 UTC
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?
Comment 5 Umherirrender 2010-06-03 18:39:41 UTC
(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.
Comment 6 John Du Hart 2010-06-24 14:40:31 UTC
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.
Comment 7 Sam Reed (reedy) 2010-06-24 15:41:58 UTC
(In reply to comment #4)
> Exactly how and how badly would things break for old clients blindly doing
> action=edit&section=new anyway?

Anyone?
Comment 8 X! 2010-08-09 00:30:20 UTC
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.
Comment 9 Andrew Garrett 2010-08-15 03:30:05 UTC
LiquidThreads usage *overrides* are stored in page_props, but a naïve client which just checked pageprops would not take into account the default.
Comment 10 MZMcBride 2011-04-23 22:45:29 UTC
(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).
Comment 11 Andrew Garrett 2012-02-10 19:27:10 UTC
Thanks for giving me that patch, John. I've (finally) applied it in r111185.

Marking RESOLVED FIXED.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links