Extension talk:DiscussionThreading

See also --Danbrice 04:47, 29 July 2008 (UTC)

Extension_talk:DiscussionThread_Article also has similar discussions about this extension. Should the two pages be combined?

great idea --Lleoliveirabr 16:37, 5 April 2007 (UTC)

Very good extension, i always waited for something like this, but i need something with Portuguese BR language. This can be done? The way to install the extension is not good, have to do many modification to MediaWiki core files. Thinking in another way? Hope the development with this extension not be stopped soon. I didn't install this yet, but be sure I'll install when you tell me how to add Portuguese BR language.

re: great idea -- Jpond 03:14, 9 April 2007 (UTC)

Internationalised it this afternoon. You now need to also add the following array after the [en] array into the internationalisation file. I'd also appreciate it if you'd add the modifications on-line to the internationalisation file DiscussionThreading.i18n.php for others to use.

The file you need to change is DiscussionThreading.18n.php (also loaded into your extension directory). You can use this as an example (after changing the text of course).

$wgDiscussionThreadMessages['lang1'] = array(
	'replysection' => 'lang1 - tag',
	'replysectionhint' => "lang1 - hint",
	'threadnewsection' => 'lang1 - new',
	'threadnewsectionhint' => "'lang1 - Start a new thread"
);

If you could tell me the BR words and phrases, I'd be glad to add them.

Competitive simultaneous edits - last person to save, wins

Peter Blaise asks: Is it subject to the MediaWiki anomaly of, when 2 people have a page open for editing at the same time, the "last person to save, wins"? I think the MediaWiki "last person to save, wins" single page orientation is a significant limit that must be overcome, not just for true discussion thread capability, but to respect the contribution of threshold contributors. The real challenge is for MediaWiki to grow to incorporate email-type real list-serve management for discussions, and perhaps for articles, also. I know many people who would not re-post nor revisit if their typing were "lost" due to bad timing during competitive simultaneous edits, as happened at the demo site for this beta test. However, I honor your pursuit. Perhaps the "first person to save"'s typing is immediately dropped one notch down in the page history and is not lost after all? I've yet to comprehend how history works, so I have a steep learning curve.

Note, however, that I will try this extension in a closed environment of a dozen editors of legal policy, and I hope it will survive for public release of the wiki project. Thank you very much.

Re: Competitive simultaneous edits - last person to save, wins -- Jpond 16:15, 9 April 2007 (UTC)

This is something you should take up with the implementers in the BugZilla space. In the words of the core developers, the standard answer is "don't try and turn MW into something it's not intended to do."

Remember, this functionality is intended to enhance and make usable - not necessarily to supercede exiting functions such as a listserv. Note that the MW developers use listserv's as their primary form of communication and documentation.

As devil's advocate to this line of thinking, my program managers basically went passive agressive on me and stopped using the collaborative discussion function until I added the automated tagging. Too many complaints about no one knew who was talking and who they were discussing with.

Installation Questions

1) it appears that there are 2 modifications to linker.php but they both appear to be the same???

   The edit was to two different functions, the line number in the second one should have been 1062, changed --Jpond 12:29, 21 April 2007 (UTC)

2) the require_once line followed by the $wgSectionThreadingOn line would both be in the local setting file
3) the first major section of code would be save to DiscussionThreading.php in extensions directory
4) the second major section of code would be saved to DiscussionThreading.i18n.php in the extensions directory

At this point I am not getting the thread. I must have missed something in the installation. any ideas would be of great help Thanks --Dtsig 04:29, 21 April 2007 (UTC)

   I also had to do a weird manual flush of the php caching (see new instructions) --Jpond 12:29, 21 April 2007 (UTC)

Added Installation Instructions --Jpond 12:09, 21 April 2007 (UTC)

Sorry - agree the instructions were missing, have been added at:

Extension:DiscussionThread_Article#Installation_Instructions

Installation Success and 3 ideas, --Dtsig 17:30, 25 April 2007 (UTC)

Bravo .. worked through first time (well actually I forgot the < in the php tag when defining the international php page and got a bunch of text at the top :-).

Here are 3 changes I am thinking of:

• add tab NEW next to the edit/reply tabs. This would allow the creation of a new section automatically. Now the user has to EDIT the page
  • Same can be done by pressing the + tab. Agree this is confusing, do you think the new link would resolve? --Jpond 15:59, 25 April 2007 (UTC)

Yeah. One of the things we are trying to do is remove as much of the markup as possible (not really possible but :). So in this case the New tab would create a new == Comment Title == level item. Similar to that mentioned below about creating a new discussion.--Dtsig 17:30, 25 April 2007 (UTC)

• a popup box for entering text. might make the users a bit happier not editing in all that goopy html/MW stuff
  • Interesting, but a lot of work. --Jpond 15:59, 25 April 2007 (UTC)

• If threading is on, instead of a blank page create a first header. edit/reply never show until there is a 1st level item (or so it seems).

• • The way I read this is the first time someone hits the 'discussion' tab, it would automagically pop into the create section (e.g., same as + tab).--Jpond 15:59, 25 April 2007 (UTC)

Yes, with the top level already there. Something like == Comment Name == This makes sure that the top level is there. As I mentioned, the edit/reply tabs don't show up unless there is at least header tag. Possibly something like this?

$wgHooks['EditFormPreloadText'][] = 'newPage';
function newPage(&$text)
{
	$wnew = $_GET['new']
	if ($wnew==1) {
		$temp1 ="== Comment Title Here ==";
     		$text=$temp1;
	}
	return true;
}

--Dtsig 17:58, 25 April 2007 (UTC)

Looking at this --Jpond 18:07, 25 April 2007 (UTC)

Summary: I'm going to be looking at this to see if possible:

1. First Click on Discussion to go into '+' (add section) mode
2. Modify header bar to include 'new' link
3. Will not use pop-ups (too many browser variables), but will investigate using the '+' (add section) form for replies as well as new. The downside here is that the text to which the responder is refering will not be visible. No guarantees on this one.

No schedule on this, I'm really tied up on some other things for the next couple of weeks - will not be before the release of 1.10.

The above will require additional patches - which really isn't desireable.

Cool .. i might look at putting the text into the page automatically (at least on a new page). Will pass on any results --Dtsig 18:53, 25 April 2007 (UTC)

Requested Enhancements Implemented --Jpond 03:33, 15 May 2007 (UTC)

1. First Edit of Discussion now goes into add comment mode (heading + text)
2. Header bars now have [new][edit][reply], the 'new' link goes into add comment mode
3. I'm not going to try and implement pop-ups - just too much effort
4. modifications to EditPage.php no longer required - implemented in hooks. Linker.php still needs minor patching

Conflict with another extension --Dtsig 15:39, 11 May 2007 (UTC)

We have been having problems getting Extension:SelectCategory extension to work when it finally dawned on me that there must be a conflict somewhere. So I started turning off all extensions and trying one at a time with SelectCategory. This is the only one that caused a conflict. Would it be possible for you to look into this? I have noted on the other extension the same information and would appreciate it if the two of you could play nicely. Let me know of any info, setup or testing needed. Thanks

Re:Conflict with another extension Extension:SelectCategory --Jpond 16:42, 11 May 2007 (UTC)

This pointed out two problems, there was not a 'return (true)' statement when the discussion threading was disabled (though I don't think this was causing the problem. We think the problem may actually be a conflict somewhere in the 'wfDebug' function used for debugging MediaWiki. In reality, this isn't needed in production, so both lines should have been removed anyway - and this seemed to fix the problem. On another note, this function is very commonly used and may show up somewhere completely independently of DiscussionThreading.

Re:Conflict with another extension Extension:SelectCategory --Dtsig 16:50, 11 May 2007 (UTC)

After testing as we suggested it does appear the the problem comes from the wfDebug Thanks again for the quick response to the problem. DTSig

Re:Conflict with another extension Extension:DynamicPageList --Erinmr 07:21, 8 June 2007 (UTC)

We have also found a conflict with the Discussion Threading extension and the dynamic page list. Undefined variable wgSectionThreadingOn Line 68, see wiki page. Any help on this would be greatly appreciated. Erin

Re:Re:Conflict with another extension Extension:DynamicPageList --jdpond 13:20, 8 June 2007 (UTC)

Erin, this is the second time this has happened, see Dave's comments Extension_talk:DiscussionThread_Article. I'm looking at this now to see what happened. Please contact me via email and let's work this out to either document or modify to avoid problems for other users.

Re:Re:Conflict with another extension Extension:DynamicPageList --Dtsig 13:25, 8 June 2007 (UTC)

Erin .. did you put

	$wgSectionThreadingOn = true;

in your localsettings? I see that var showing in the error message

Re:Re:Conflict with another extension Extension:DynamicPageList --jdpond 13:30, 8 June 2007 (UTC)

Erin, my bad. add this line right before line 68 in discussion threading for a temp fix, will fix release now:

	function efDiscussionLink4other ($callobj, $title, $section , $url , &$result)
	{
+		global $wgSectionThreadingOn;
		if($wgSectionThreadingOn && $title->isTalkPage() ) {
			$commenturl = '&section='.$section.'&replyto=yes';
			$curl = $callobj->makeKnownLinkObj( $title, wfMsg('replysection'), 'action=edit'.$commenturl );
			$newthreadurl = '&section=new';
			$nurl = $callobj->makeKnownLinkObj( $nt, wfMsg('threadnewsection'), 'action=edit'.$newthreadurl );
			$result =  "[".$nurl."][".$url."][".$curl."]";
		}
		return (true);
	}

Re:Re:Conflict with another extension Extension:DynamicPageList --jdpond 15:51, 11 June 2007 (UTC)

Version 1.1 fixes this and makes forward compatible with EditSectionLink enhancement which will not require patches in future release.

Re:Re:ReConflict with another extension Extension:DynamicPageList --Erinmr 14:09, 13 June 2007 (UTC)

Thanks John, this seems to work now.

No New/Reply buttons --Erinmr15:26, 13 June 2007 (UTC)

They have disappeared since the latest install. Am I doing something wrong? Thanks! Example

Re: No New/Reply buttons --Erinmr15:26, 13 June 2007 (UTC)

Jack, I first tried your new version of the Discussion threading extension and there it seemed like the new/reply buttons disappeared. I then went back to the old version and tried the fix and that works for me.

Re:Re: No New/Reply buttons --jdpond 19:49, 13 June 2007 (UTC)

Erin, I went back and checked - if you are still having problems, please notify so I can fix. The TAR had an extra directory (1_10) that should have been deleted (the zip was fine). If you were using the patched Linker.php, you need to use the 1_10_0 version. The next version (1_11_0) and trunk eliminate the need for patching. I had to slightly modify the DiscussionThreading.php file to accomodate. Remember, you have to update all three files for DiscussionThreading version 1.1:

• • includes/Linker.php
  • extensions/DiscussionThreading/DiscussionThreading.php
  • extensions/DiscussionThreading/DiscussionThreading.i18n.php

---

I had an issue too with the new and edit buttons not showing. This is with rev_1_24. The fix for me was on line 66 of DiscussionThread.php

 function efDoDiscussionLink ( $callobj , $nt , $section , $hint='' , $result , $lang = false )

Added the & in front of $result. Like so...

 function efDoDiscussionLink ( $callobj , $nt , $section , $hint='' , &$result , $lang = false )

125.237.169.38 04:30, 3 February 2015 (UTC)

order of the comments

I like your extension very much. But is it possible to change your extension that I can see the newest Article at the top of the Discussion page. You understand what I mean? I wanna chance the order of the inserts.

re: Order of the Comments --jdpond 14:41, 26 September 2007 (UTC)

Great idea. Right now the extension uses the exact same code as the "+" tab, which adds to the bottom. I'd have to investigate to see if there's a hook I could use to reorder. I'm assuming this is only for new threads. For consistency sake, would we want to consider inverted order for sub thread too? That may be too much work.

re: Order of the Comments

Just finished looking into this one. I'll look for a better way, but as a temporary measure, you can get this by patching includes/Article.php in function replaceSection():

Index: Article.php
===================================================================
--- Article.php	(revision 40244)
+++ Article.php	(working copy)
@@ -1259,7 +1259,7 @@
 				# Inserting a new section
 				$subject = $summary ? wfMsgForContent('newsectionheaderdefaultlevel',$summary) . "\n\n" : '';
 				$text = strlen( trim( $oldtext ) ) > 0
-						? "{$oldtext}\n\n{$subject}{$text}"
+						? "{$subject}{$text}\n\n{$oldtext}"
 						: "{$subject}{$text}";
 			} else {
 				# Replacing an existing section; roll out the big guns

re: re: Order of the Comments

When starting a thread, the (+) tab will always put the latest thread at the bottom. However, there is a simple way to make the replies within a given thread read from newest to oldest. This is accomplished by making all replies have a heading of the same level (I chose h4), instead of increasing in level from the . I prefer this way since the replies all have uniform headers. The number of Re:'s in the header and the indentation level keeps the replies organized properly. Also, when you reply, the edit window is not cluttered with replies above yours. See my earlier post #An improvement to consider below. Bill Johnson 03:10, 18 December 2009 (UTC)

re: re: re: Order of the Comments

The reason behind incrementing the headers is so the discussion thread appears in the table of contents indented. If you're talking about the format only (e.g., h2, h3 . . .), I've thought of changing this - but another answer would just be to make h2, h3, . . . the same format in the css - which would allow those who do want to have different heading sizes to visually distinguish via that mechanism without having to look up at the TOC. Did I understand the drift of your question Bill?

By the way, I'm hoping we can deprecate this extension in favor of LQT with the release of 1.16 and the new LQT which rumour has will be available early spring.

--jdpond 14:08, 18 December 2009 (UTC)

Problem with MW 1.11

Nice extension. But while using with MW 1.11, if the extension is activated, the section edit links are disappeared from articles. if i roll back to the original linker.php, then edit links are there, but not the "new" and "reply" links in talk pages. any solutions?

DiscussionThread Article

Why is there this extension, and DiscussionThread Article? What is the difference? Are they two different extensions? --Rovo 12:13, 1 October 2007 (UTC)

Bug : two signatures

Hi,

Thanks for this great extension !

I have a probleme there are two signatures if :

• I create a new comment
• I write Subject/headline but not text in comment textarea
• Click on Save Page
• I have an error message : Please enter a comment below but I have wiki signature inserted in the Subject/headline
• I write comment in textarea
• Click on Save Page
• There are 2 signatures in discussion page

I have added french translation in Extension:DiscussionThread_Article#Internationalisation_file_DiscussionThreading.i18n.php

CSS tip to make reply body match title? - LNick 19:04, 26 February 2008 (UTC)

I used the CSS tip at the bottom of the installation article to indent the headings of replies, and I like it very much! However the body of the reply isn't indented. Does anyone have a good CSS trick to do that as well? Or perhaps this could be an enhancement for the extension.

Re: CSS tip to make reply body match title? --Danbrice 05:02, 29 July 2008 (UTC)

I've come up with a patch that does this, not using CSS, but instead just the correct number of old colons (:) (based on the number of equal signs) to indent the body. I've also added some "replace me" text so that the user knows where to edit (which wasn't obvious to me when I first used this extension), and some javascript to select that "replace me" text in the text area too.

In the file extensions/DiscussionThreading.php, Add this:

        // Add an appropriate number of colons (:) to indent the body.
        // Include replace me text, so the user knows where to reply
        $replaceMeText = " Replace this text with your reply";
        $text .= "\n\n".str_repeat(":",strlen($matches[1])-1).$replaceMeText;
        // Insert javascript hook that will select the replace me text
        global $wgOut;
        $wgOut->addScript("<script type=\"text/javascript\">
          function efDiscussionThread(){
            var ctrl = document.editform.wpTextbox1;
            if (ctrl.setSelectionRange) {
              ctrl.focus();
              var end = ctrl.value.length;
              ctrl.setSelectionRange(end-".strlen($replaceMeText).",end-1);
              ctrl.scrollTop = ctrl.scrollHeight;                               
            } else if (ctrl.createTextRange) {
              var range = ctrl.createTextRange();
              range.collapse(false);
              range.moveStart('character', -".strlen($replaceMeText).");
              range.select();
            }
          }
          addOnloadHook(efDiscussionThread);
          </script>");

Just before the two lines:

       $efform->replyadded = true;
       $efform->textbox1 = $text;

I've tested it on IE 6.0 and Firefox 2.0, would be interested to know if the "replace me" text selection works on other browsers too. I let me know if you have a better way to write the above.

Update: I've updated the above code to also work better with Safari (3.1.2), and to scroll to the bottom of a large thread for both Safari and Firefox (IE already did that). --Danbrice 14:26, 29 July 2008 (UTC)

GREAT Modification --jdpond 06:02, 29 July 2008 (UTC)

Unless someone comes up with a problem, I'd like to incorporate into the code (would not retrofit prior to 1.10). Any way we can get someone to commit this as an extension in SVN so it could be collaboratively maintained? I took a shot at it when first developed, but it went nowhere.

CSS Tip Reproduced -- LNick 12:32, 29 July 2008 (UTC)

Thanks Danbrice! This is exactly what I was looking for! I was so dissatisfied I had removed the CSS trick to indent headers, and then had a lot of trouble finding it again! I've reproduced it here to help others. I don't know if you (or anyone else) has any ideas on how to limit the heading indents to comment pages?

Indenting Headers
If you are really serious about threading, you can indent headers by modifying the corresponding CSS file (eg. skins/monobook/main.css). To modify all headers (talk or regular article), you can add a 'padding-left: xem;' into each of the headers 3-6. Eg.:

h3 { font-size: 132%; padding-left: 1em;}
h3 .editsection { font-size: 76%; font-weight: normal; }
h4 { font-size: 116%; padding-left: 2em;}
h4 .editsection { font-size: 86%; font-weight: normal; }
h5 { font-size: 100%; padding-left: 3em;}
h5 .editsection { font-weight: normal; }
h6 { font-size: 80%; padding-left: 4em; }
h6 .editsection { font-size: 125%; font-weight: normal; }

Does not work with FCKEditor

The extention does not work with FCKEditor. There is a problem with reply. Anyone is aware of this problem ? Thanks

Me too !!! with mediawiki 1.13

Suggestion to make the identing work --Joris 15:30, 28 August 2008 (UTC)

$wgHooks['ParserAfterStrip'][] = 'efDiscussionParser';
	
function efDiscussionParser(&$parser, &$text, &$strip_state)
{
	if($parser->getTitle()->isTalkPage()) {
		$lines = explode("\n", $text);
		$level = 0;
		foreach($lines as &$line) {
			if(preg_match('/^(={3,})(.*)(={3,})$/', $line, $matches)) {
				$l = strlen($matches[1]);
				if($l > $level) {
					$line = "<div class=\"reply\">\n" . $line;
				} else if ($l < $level){
					$line = str_repeat("</div>",$level - $l) . "\n\n" . $line;
				}
				$level = $l;
			}
		}
		$text = implode("\n", $lines) . str_repeat("\n</div>",$level - $l);
	}
	return true;
}

In combination with

/* Threaded Discussion */
.reply {
    margin-left: 15px;
}

.reply h1, .reply h2, .reply h3, .reply h4, .reply h5, .reply h6 {
    font-size: 14px;
    background-color: #EEE;
}

.reply .editsection {
    font-size: 86%;
    background-color: #EEE;
}

Will make it look like this:
Image:DiscussionThreading_IdentMod.jpg

Suggestion to make the identing work -15:03, 3 June 2009 (UTC)

Which file modify with this code... ?

Small notice about code

strlen() function works well only with US ASCII chars (single byte). If i write my "replace me text" message in Russian or other language and save DiscussionThreading.php file in UTF-8. So i get wrong strlen() value and function with "select replace me text" doesnt work well. You should replace it with mb_string (multibyte string) for better result i suggest.
mbstring in PHP
But mbstring is a non-default extension in PHP.
And words "replace me" should be in i8n file. contact

Combining Discussion Threading with a Rating system

I would like to combine Discussion Threading with a Rating system. My site is effectively a review site, with the Article having product details and the Talk page used to add reviews. What would be ideal would be to have a way that only registered users could add a review AND simultaneously give a rating. The simplicity of DT makes it perfect.... but is there any way to combine in a rating? Or would anyone like to take the project on?

Serendipity? Funny you should ask --jdpond 14:46, 15 January 2009 (UTC)

I saw this functionality yesterday and wondered if there was some way of reproducing in MediaWiki. Note the site has the ability to submit suggestions, rate those suggestions, and (if implemented according to the submitted suggestion) even rate and prioritize the comments.

The questions would be:

• Is this something that is best done in MediaWiki (versus, another plugin/technology)
• Is there enough interest to put together a working team to move forward?

If I get enough interest, I will work with the above anonymous commenter to see if we should put something together.

An improvement to consider

I like this extension a lot, but I had a couple of problems with it. For one thing, it didn't always indent correctly. Also, I didn't like how bold the headings on the replies were; they distracted me too much from the original thread heading. So, I made a change (in my installation) to make all replies at the h4 heading level. I compute the indenting (the number of ":") based on the number of "Re: " found in the header at the top of the edit window. Now all replies have a smaller header font and it looks better to me. Also, this causes the order of replies at a similar indentation level to be reversed on the page (i.e. newest at the top) within each thread. Clicking the "+" tab will still put a new section at the bottom, but any reply will always go directly under the post that you are replying to. This is because all sections now have equal weight (no sections inside sections). The advantage of this is that the first reply you read can be assumed to have considered all following replies at the same level. You don't have to read all replies only to find out that the last one says "everything above is wrong -- here is the right answer!". Finally, this change keeps the edit window smaller since you only see the post you are directly replying to. Bill Johnson 20:02, 11 November 2009 (UTC)

Custom Namespace

It does not seem to work in a custom (talk) namespace, how would I go about to get this working.

Re:Custom Namespace --jdpond 23:56, 25 March 2010 (UTC)

I just tested this using the custom namespace "ITS". Is there something I missed?

What version are you running on?

DT with TalkRight

DT works great if user has "edit" rights. When using TalkRight extension, user has only "talk" right. It that situation links are not shown. Where can I find code which checks edit rights and allows to show DT links?

RE: DT with TalkRight --jdpond 23:19, 26 August 2010 (UTC)

I've looked at Extension:Talkright, and have an alternate suggestion. Instead of using TalkRight, have you considered using Extension:Lockdown and restricting access rights to the *_talk namespaces? I think this may be a better and more flexible solution and I know it does work with Extension:DiscussionThreading.

I really don't feel up to going into Talkright and figuring out how to make it compatible with standard section headers - it should be using the following hooks which are properly placed relative to usercan requirements but doesn't:

EditPage::showEditForm:initial
EditPage::attemptSave
EditPage::showEditForm:initial
EditSectionLinkForOther
EditSectionLink
AlternateEdit;

I don't know why Duesentrieb has Lockdown marked as beta because it is CERTAINLY stable and I've been using it for years on multiple wikis. I'll ping him and see.

RE: DT with TalkRight

Thank you four your help. Finally I found that code. It is in includes/parser/Parser.php in line 3508. I added new if function which checks if user has talk permission. Now it works. :-)

RE: RE: DT with TalkRight --jdpond 18:49, 27 August 2010 (UTC)

Hmm, I guess that's one way to do it. Are you sure there's no way to do it using a hook (I'm using trunk and 3508 didn't seem to make any sense)? Patching core code can lead to a lot of nightmares!

No 'reply' link in MediaWiki 1.17

Any ideas on how to fix this? --86.139.23.122 12:12, 10 October 2010 (UTC)

Re:No 'reply' link in MediaWiki 1.17 --jdpond 04:54, 13 October 2010 (UTC)

I hadn't looked at 1.17 - Thanks for pointing out a potential problem . The extension had only been tested through 1.16.

The hook that this extension uses ( EditSectionLink) has been deprecated (I was unaware, don't know how I missed this). A rewrite (version 1.4) is required to use the new hook ( DoEditSectionLink) while maintaining backwards compatibility to everything up through 1.16).

This problem arose because r70940 replaced wfMsgHtml with wfMsgExt. Whether you use the correct hook (doEditSectionLink) or the deprecated hook (EditSectionLink), it's going to do the same thing - overwrite the link modified in the hook which effectively disables this extension. Platonides fixed this in r74697. You should be able to download the current version and correct the problem.

Version 1.4 has been released, which should be backwards compatible to at least 1.14, and probably all the way back to 1.11. In addition to using the new hook ( DoEditSectionLink) instead of the deprecated hook ( EditSectionLink), this release will allow you to use MediaWiki:Editsection-brackets if you wish to change (or remove) the brackets around the link or in any other way customize the links.

You do not have to upgrade to fix the reported bug, that was done in r74697, but you may want to anyway.

Error Discussion + Cite 1.6 + Wikimedia 1.18

Thanks for the extension!

When I use Discussion + Cite 1.6 + Wikimedia 1.18, the "Comments" and the "Post Comment" buttons appears not in the footer, but where I put the "ref" command for the Cite extension. What I can do to resolve this problem?

Thanks!

Emmerson Maurilio

RE: Error Discussion + Cite 1.6 + Wikimedia 1.18 --jdpond (talk) 22:15, 23 March 2012 (UTC)

Could I take a look at this on your system? Send me an email where I can check it and I'll try and take a look at it. I'm about to move to GIT so this would be a good time.

Not working on mw 1.20.3

the extension is not working on mediawiki 1.20.3, I cant find a fix

Did you try the GIT version

In my wikis, it does run under 1.22 alpha and (unless I remember badly) it did run under 1.20 - Daniel K. Schneider (talk) 10:53, 27 August 2013 (UTC)

In Media wiki 1.21.2 - Reply link is not shown against the topics added

Environment : MediaWiki 1.21.2 PHP 5.4.13
Downloaded the extension for the MediaWiki 1.21 version
I have installed the Discussion Threads and provides "Add Topic" functionality . It also gives the edit link against all Topics (Sections) added. But there is no reply link shown. Any hints ..

MW 1.23 and Extension is not showing up

Hi, I installed the latest version from GIT, enabled it in LocalSettings.php and nothing happens using the "Discussion" tab for any page.
I must be doing something wrong and I don't know what.
e.g. what does this commend in the installation doc means:

This threading will only be seen on the talk pages, unless explicitly invoked in the command line.

---

I'm also not seeing it under a fresh 1.23.6 installation (PHP 5.4.4-14, MySQL 5.5.21-0, DiscussionThreading 1.5.0). The talk pages only show the normal talk interface with the "Add topic" option; including / excluding the extension doesn't seem to make a difference, other than seeing / not seeing it under Special:Version. --Salquint (talk) 15:47, 4 December 2014 (UTC)

Possible solution

I'm new to mediawiki, but I had a look at the php file for this extension. It's basically a bunch of hooks for various events related to talk pages. I think the problem might be related to deprecated wfMsg* functions as described here:

Manual:Messages_API

you might have to replace all these functions with new ones as described in the link.

Re:Possible solution

well I tried this and it still doesn't work. I'm not sure but perhaps there is something wrong with the code? Consider this function:

function efDiscussionThreadEdit( $efform ) {
	global $wgRequest,$wgSectionThreadingOn;
	$efform->replytosection = '';
	$efform->replyadded = false;
	$efform->replytosection = $wgRequest->getVal( 'replyto' );
	if( !$efform->mTitle->exists() ) {
		if( $wgSectionThreadingOn && $efform->mTitle->isTalkPage() ) {
			$efform->section = 'new';
		}
	}
	return ( true );
}

I had a look at the class documentation for "EditPage" and there is no member "replytosection" or "replyadded".

Another example:

function efDoDiscussionLink ( $callobj , $nt , $section , $hint='' , $result , $lang = false )
{
	global $wgSectionThreadingOn;
	if($wgSectionThreadingOn && $nt->isTalkPage() ) {
		$spanOpen="<span class=\"mw-editsection\">";
		$spanClose="</span>";
		$strippedResults = substr( substr( $result , strlen( $spanOpen )) , 0 , -strlen( $spanClose ) );
		$commenturl = '&section='.$section.'&replyto=yes';
		$hint = ( $hint=='' ) ? '' : ' title="' . wfMessage( 'discussionthreading-replysectionhint')->rawParams(htmlspecialchars( $hint ))->escaped() . '"';
		$curl = '''$callobj->makeKnownLinkObj'''( $nt, wfMessage('discussionthreading-replysection')->text(), 'action=edit'.$commenturl, '', '', '',  $hint );
		$newthreadurl = '&section=new';
		$hint = ( $hint=='' ) ? '' : ' title="' . wfMessage('discussionthreading-threadnewsectionhint')->rawParams(htmlspecialchars( $hint ))->escaped() . '"';
		$nurl = '''$callobj->makeKnownLinkObj'''( $nt, wfMessage( 'discussionthreading-threadnewsection' )->text(), 'action=edit'.$newthreadurl, '' , '' , '' ,  $hint );
		$nurl = '<span class="mw-editsection-bracket">[</span>' . $nurl . '<span class="mw-editsection-bracket">]</span>';
		$curl = '<span class="mw-editsection-bracket">[</span>' . $curl . '<span class="mw-editsection-bracket">]</span>';
		$result = $spanOpen.$nurl.$strippedResults.$curl.$spanClose;
	}
	return ( true );
}

There is no method "makeKnownLinkObject" for the "skins" class. That's why the [reply] button is not showing up. Someone should try to fix this extension as it is exactly what I'm looking for (I'm not interested in liquid threads).

--Mfort123 (talk) 05:24, 15 December 2014 (UTC)

Hack to make it work under MW 1.24 and DiscussionThreads "master" from GIT

I am too old for programming and never really learned how to. But I did upgrade and do need this extension :( So here is what I did:

1. Get the latest code.

git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/DiscussionThreading.git
git checkout master

2. Open file DiscussionThreading.php and make it look like this. The only thing I changed after inserting a debugging statement was to replace the $result paramater by &$result. (... after some thinking why $result was not returned...)

# Not needed - DKS April 2014
# $wgHooks['EditSectionLinkForOther'][] =  'efDiscussionLink4other';
$wgHooks['AlternateEdit'][] =  'efDiscussionThreadEdit';
$wgHooks['DoEditSectionLink'][] =  'efDoDiscussionLink';

.....

function efDoDiscussionLink ( $callobj , $nt , $section , $hint='' , &$result , $lang = false )
{
	global $wgSectionThreadingOn;
	if($wgSectionThreadingOn && $nt->isTalkPage() ) {
		$spanOpen="<span class=\"mw-editsection\">";
		$spanClose="</span>";
		$strippedResults = substr( substr( $result , strlen( $spanOpen )) , 0 , -strlen( $spanClose ) );
		$commenturl = '&section='.$section.'&replyto=yes';
		$hint = ( $hint=='' ) ? '' : ' title="' . wfMessage( 'discussionthreading-replysectionhint', $hint )->escaped() . '"';
		$curl = $callobj->makeKnownLinkObj( $nt, wfMessage( 'discussionthreading-replysection' )->escaped(), 'action=edit'.$commenturl, '', '', '',  $hint );
		$newthreadurl = '&section=new';
		$hint = ( $hint=='' ) ? '' : ' title="' . wfMessage( 'discussionthreading-threadnewsectionhint', $hint )->escaped() . '"';
		$nurl = $callobj->makeKnownLinkObj( $nt, wfMessage( 'discussionthreading-threadnewsection' )->escaped(), 'action=edit'.$newthreadurl, '' , '' , '' ,  $hint );
		$nurl = '<span class="mw-editsection-bracket">[</span>' . $nurl . '<span class="mw-editsection-bracket">]</span>';
		$curl = '<span class="mw-editsection-bracket">[</span>' . $curl . '<span class="mw-editsection-bracket">]</span>';
		$result = $spanOpen.$nurl.$strippedResults.$curl.$spanClose;
		// debugging - DKS April 2015
		// wfDebug ("***DEBUG***: result = ". $result . "\n");
	}
	return ( true );
}

• Warning: If you also installed VisualEditor, it is vital to "require" DiscussionThreading in LocalSettings.php after the VisualEditor config. If it's before, it won't work...
• Proof is here or or here (login required) and btw. I also wrote down how I installed a new server and a test wiki with the extensions we use
• Disclaimer: some stuff still may not work, but I got at least something going and some knowledgeable person with powers could indeed put this (or a better solution) to the repository.

- Daniel K. Schneider (talk) 15:57, 29 April 2015 (UTC)

I can confirm

The above mentioned change to file DiscussionThreading.php , make $result to &$result in line 66 does the job. I have MW 1.23.7 and Extension:DiscussionThreading V 1.5 from git. --Carchaias (talk) 11:00, 22 May 2015 (UTC)

users can reply to existing comments or create new ones using the [new][edit][reply] does not show up in mediawiki 1.25.5

This does not work in MediaWiki 1.25.5

The above function efDoDiscussionLink ( $callobj , $nt , $section , $hint='' , &$result , $lang = false ) line 66 works

Mw 1.27 fix

Reply is broken in MW 1.27. According to my very limited programming skills this is probably due to some sanitation procedure. I.e. I got:

http://..../mediawiki/index.php?title=Talk:SandBoxes&action=edit%26section%3D4%26replyto%3Dyes

instead of

http://..../mediawiki/index.php?title=Talk:SandBoxes&action=edit&section=4&replyto=yes

Anyhow, I found how one should create links (Linker::link) and then changed the code.

In File DiscussionThreading.php fix the efDoDiscussionLink function like this (comment one line and fix another one, see the comments below):

function efDoDiscussionLink ( $callobj , $nt , $section , $hint='' , &$result, $lang=false )
{
	global $wgSectionThreadingOn;
	if($wgSectionThreadingOn && $nt->isTalkPage() ) {
		$spanOpen="<span class=\"mw-editsection\">";
		$spanClose="</span>";
		$strippedResults = substr( substr( $result , strlen( $spanOpen )) , 0 , -strlen( $spanClose ) );
		// BAD	$commenturl = '&section='.$section.'&replyto=yes';
		$hint = ( $hint=='' ) ? '' : array( 'title' => wfMessage( 'discussionthreading-replysectionhint', $hint )->escaped() );
		$curl = Linker::link(
			$nt,
			wfMessage( 'discussionthreading-replysection' )->escaped(),
			$hint,
			array( 'action' => 'edit', 'section' => $section, replyto => 'yes'  ), // CHANGED to respect manual
			array( 'known' )
		);
		$newthreadurl = '&section=new';
		$hint = ( $hint=='' ) ? '' : ' title="' . wfMessage( 'discussionthreading-threadnewsectionhint', $hint )->escaped() . '"';
		$nurl = Linker::link(
			$nt,
			wfMessage( 'discussionthreading-threadnewsection' )->escaped(),
			$hint,
			array( 'action' => 'edit' . $newthreadurl ),
			array( 'known' )
		);
		$nurl = '<span class="mw-editsection-bracket">[</span>' . $nurl . '<span class="mw-editsection-bracket">]</span>';
		$curl = '<span class="mw-editsection-bracket">[</span>' . $curl . '<span class="mw-editsection-bracket">]</span>';
		$result = $spanOpen.$nurl.$strippedResults.$curl.$spanClose;
	}
	return true;
}

- cheers ! Daniel K. Schneider (talk) 11:50, 27 September 2016 (UTC)

PS: It would be cool if a friendly MW maintainer could look at this code, validate and then push into the repository.

Update Nov 2017

I just installed this extension for a new MW 1.29 and it seems to work out of the box. Thanx for fixing the code :) - Daniel K. Schneider (talk) 12:51, 8 November 2017 (UTC)

git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/DiscussionThreading.git

and in LocalSettings.php

wfLoadExtension( 'DiscussionThreading' );

Discussion Hiding

Is there a way to turn off the HIDE option? Thanks Pete.

Unable to get to talk page

MediaWiki 1.28.0

When Discussion threading is enabled I'm unable to get to the talk page

Error on discussion page

Hello I installed the extension on wiki version 1.28 but now when I go to a discussion page I see the following error. Any suggestions?

 Catchable fatal error: Argument 3 passed to MediaWiki\Linker\LinkRenderer::makeKnownLink() must be of the type array, string given, called in /var/www/includes/Linker.php on line 237 and defined in /var/www/includes/linker/LinkRenderer.php on line 283

MW 1.31 = OK

Just to let know: this extension works fine under MediaWiki 1.31 (sept. 2018)

After upgrading two wikis from MW 1.27 and the extension code. I use git to manage that kind of extension. All I did was:

cd extensions/DiscussionThreading
# remove a patched file
rm DiscussionThreading.php
git pull
git checkout REL1_31
php ../../maintenance/update.php

I also updated the main page and the installation page a bit to reflect this.

--Daniel K. Schneider (talk) 15:14, 20 September 2018 (UTC)

Is this extension current or has it been superseded by the Structured Discussions extension?

(question)

One answer: IHMO (I really do not know for sure) there is always a tension whether discussion pages should behave like forums (flat or hierarchical) or like wiki pages (allowing random edits of page contents). This extension is clearly wiki-centered and I like it quite well but since it doesn't seem to have an official maintainer it sometimes stops working. Other attempts such as Structured Discussion went for the "forum approach" and seem to have failed, i.e. are discontinued, for reasons I don't know. I do prefer the wiki approach since it allows easy cleaning up of contents. On the other hand, "normal" users do not understand that you could both have a forum-like structure and a wiki page. So if you got users who do not really understand how a wiki works, something like structured discussions may be better. I once deployed Extension:LiquidThreads, but then found it too much unwiki-like. In any case, I strongly suggest figuring out if an extension will survive the next upgrade. Daniel K. Schneider (talk) 13:30, 22 October 2018 (UTC)