Last modified: 2014-11-17 10:35:45 UTC
Rather than posting a new thread - or perhaps allowing you to post a reply to an existing thread - WikiLove posts above the LT installation on the talk page. Example: http://www.mediawiki.org/wiki/User:Kghbln Not exactly a priority, but if development of LT continues one day - something WikiLove or LT (not sure if this would be better under that extension) will want to address. Would be handy to address for MW.org and the other sites currently running both LT and WikiLove.
WikiLove just uses the MediaWiki API to post the message (via the appendtext parameter using action=edit). So this is actually an API bug.
Hm.. it would be an API bug if it the canonical goal behind appending text to a page is to create a new thread, or even to participate in discussion at all. However, for one, the header of an LQT-enabled page should be editable as well. And secondly, how can we distinguish from appending something to the last section and appending a new section ? Instead of appendtext, it should probably use text=...§ion=new, like the front-end. That would be closer to something that canonically means wanting to open a new discussion when used on a talk page. Theoratically a bot could be using text=..§ion=new to create a new section in the header of an LQT-enabled page, so we'd have to find a way to do that still. Perhaps MediaWiki should get an additional parameter (or different action/module alltogether) for participating in discussions and letting extensions override this ? By default it would implement a 'raw wikitext' discussion thread, which is just sections on a talk page.
We can't use section=new since that method doesn't allow us to specify the edit summary. If someone fixes that, I'll gladly re-implement it.
Actually that's only half true. You can specify an edit summary, but it doesn't respect what you specify. Instead it forces it into a "new section" message. We just need a way to override this.
I'm going to file a new bug explaining that magically morphing the summary from an edit summary into a section title and then auto-generating an edit summary that is different than the summary makes no sense. I bet you a dollar it will be closed within 24 hours as WONTFIX since it is written into the 10 Commandments "Thou shalt not change the MediaWiki API" :P
Looks like Krinkle beat me to it and filed the bug last year: https://bugzilla.wikimedia.org/show_bug.cgi?id=26312 I'll mark it as a dependency. It looks like the essential problem is that action=edit relies on EditPage.php, which for some reason reuses the wpSummary input for both the edit summary and the section title, even though these should be separate inputs.
I've tried to implement a workaround in r106754. I'll leave this open until the rev is approved.
(In reply to comment #2) > Instead of appendtext, it should probably use text=...§ion=new, like the > front-end. That would be closer to something that canonically means wanting to > open a new discussion when used on a talk page. > I think that LQT actually hijacks section=new for adding a new thread, but I'm not sure.
I believe Werdna was rather adamant about &action=edit§ion=new not being equivalent to posting a LiquidThreads thread. He sees the actions as distinct (cf. bug 21256 comment 3). I thought WikiLove was using the MediaWiki API internally, so I was going to suggest simply checking the target talk page for LiquidThreads and then using the LiquidThreads action instead of &action=edit§ion=new, however it looks like WikiLove isn't using the MediaWiki API (for whatever reason). I glanced at r106754 and it feels very hackish and bad. Particularly these two lines: $this->sectiontitle = $wgLang->truncate( $request->getText( 'wpSectionTitle' ), 250 ); $this->sectiontitle = preg_replace( '/^\s*=+\s*(.*?)\s*=+\s*$/', '$1', $this->sectiontitle );
Just as a side note, MZMcBride directed me toward this bug, because I found that a side-affect of this bug is that users who receive WikiLove when their user talk page has LQT enabled do not receive a new message notification.
Change 83409 had a related patch set uploaded by Legoktm: Create new LQT thread if possible https://gerrit.wikimedia.org/r/83409
(In reply to comment #6) > Looks like Krinkle beat me to it and filed the bug last year: > https://bugzilla.wikimedia.org/show_bug.cgi?id=26312 > > I'll mark it as a dependency. > What does this have to do with LiquidThreads at all? I've removed it as a dependency.
Change 83409 merged by jenkins-bot: Create new LQT thread if possible https://gerrit.wikimedia.org/r/83409
