Extension talk:ArticleComments

Include discussion page on article page
Works great, but I am looking for a way to have comments appended to the article's own page on the bottom, much like Wordpress or any blogging software does. Main article, then the box to enter a comment, then a Comments header, followed by the comments themselves. Integration with reCAPTCHA would also be nice.

This extension is working very well, Im very impressed. Good support from Jim R Wilson also! Ive implemented a CSS for this at LeerWiki.nl regards B.Vahrmeijer


 * Regarding embedding the comments for an article into the article itself - there's really no need (in my mind) to do this programmatically. MediaWiki already has a mechanism for pulling to the contents of one article into another.  The code for the suggestion above would be:   This would show the comment form, followed by any contents from the talk page, transcluded into the regular article.  Hope this helps! -- Jimbojw 11:35, 12 July 2007 (UTC)
 * Minor update... if you create a new article and want inline comments, the line above adds a link to the Talkpage under the comment form, since it doesn't exist. This simple update to your page or template takes care of that:


 * I found that this format keeps you from literally seeing "== skew said... ==" instead of the formatted (i.e. skew said... ) version. --Skew 15:19, 31 May 2011 (UTC)

Require_once position
The line position for the ArticleComments "require" statement within LocalSettings.php made a difference between working and not working. This extension worked when I placed the ArticleComments "require" statement before other "require" and "include" statements. --Infonomics 22:31, 17 August 2007 (UTC)


 * Hi Infonomics. That's probably due to the other extensions, not ArticleComments.  It's a common mistake for an extension to fail to return a value for a hook implementation.  When this happens, the hook stack is killed and no further processing is done for that hook.  ArticleComments correctly returns , giving other extensions a chance to run.  It's likely that the other extensions were killing the stack before ArticleComments could execute.  Thanks! -- Jimbojw 20:51, 20 August 2007 (UTC)
 * I still get an error message: Fatal error: Call to a member function addMessage on a non-object in /customers/f/4/a/wikiskola.se/httpd.www/extensions/ArticleComments.php on line 277. Can anyone help me here, please? I'm running Mediawiki 1.18.1.


 * I have the same exact problem on 1.19! No solution for the Fatal Error?

dan 10/17/12

Code by default on all article pages
I really like this extension and works fine but: My wiki is already set up and I have 4500 articles which I want to include this extension on. I cannot add the code manually to each article and don't want to bother users to add it when they create a new article. So can it be included on each article and maybe category page BY DEFAULT?

Extension:TalkHere is displaying on all pages you define per namespace, but besides no ability to seperate the messages, a magic word like __NOTALKHERE__ is missing so if I find a way to add the code on all pages, __NOCOMMENTS__ would need to be possible (e.g. for Main Page) --Subfader 23:23, 21 August 2007 (UTC)
 * I've used the headerfooter extension top do this Tarlachmoorhouse 22:16, 14 December 2007 (UTC)
 * See below "Leave Comment" + all comments on all article pages --Subfader
 * Hmh but I cannot disable the footer which reads using __NONSFOOTER__ or __NOFOOTER__ --Subfader 12:50, 14 June 2008 (UTC)

Return to article page after submitting a comment
I want to integrate this with the code from above. But after submitting a comment the article page should reload instead of the You have successfully... You may view... page. On the Special:ProcessComment it should be possible to add a ReturnTo with a timeout. I saw this on other extensions, which takes you to the Main Page after 5 seconds: $wgOut->returnToMain; ? --Subfader 23:47, 21 August 2007 (UTC)

Latest posts on top
I'd like to see the order changed so that new comments are on top. This would also make sense when showing the comment form by default so the new post appears directly under the form. How's that possible? --Subfader 23:23, 21 August 2007 (UTC)


 * Me too, chris 19 aug 2009.


 * Same question here :-/ --87.176.101.115 22:30, 21 January 2010 (UTC)


 * The way this extension is set up, I guess it's not possible at all --Subfader 21:50, 22 January 2010 (UTC)

User Names
I'd like to remove the Name field and have the user name included like the format but catched like ~ signature does to avoid fake posting. This could easily be done on MediaWiki:Article-comments-new-comment i guess? --Subfader 23:23, 21 August 2007 (UTC)
 * still wanted. if logged in user, link name, if visitor, plain text ;) --Subfader 15:44, 12 April 2008 (UTC)

I belive the solution is to change this line: into: Frihet 13:58, 8 April 2009 (UTC)
 * That almost works, but the Name prompt still needs to be hidden. I wanted the same thing, since I'm insisting comments can only be added by logged-in users.  To keep things clean, I added a 'shownamefield' global, similar to 'showurlfield':

+      if ( $params['shownamefield'] ) { $content .= ''. wfMsgExt(                               'article-comments-name-field',                                array( 'parseinline', 'content' )                        ). Html::element( 'br' ). ' ';               $content .= Html::input( 'commenterName', '', 'text', array( 'id' => 'commenterName' ) ); $content .= ' '; +       } +         else +               $content .= Html::input( 'commenterName', '', 'hidden', array( 'id' => 'commenterName' ) );
 * Then to hide the field, just add

$wgArticleCommentDefaults['shownamefield'] = false;
 * to LocalSettings.php under your ArticleComments require_once. The else is needed because the name field still needs to be set to the current user.  I imagine at least the shownamefield global would be folded into the svn source if this is deemed useful, but I don't know that the hidden-hack is necessarily the best way to go. --Skew 14:50, 31 May 2011 (UTC)

Has anyone else had any trouble getting this to work on 0.6? When I hide the commenterName input box I get an error message on the process special page stating that it cannot process the comment because the 'Name' field is blank. How can I get the logged-in user's name (that appears at the bottom of the comment) to be provided as the 'Name' field value so that the comment will process and it appears in the comment header? Thanks! - Adam 24 April 2012

Preview Button
A preview button next to the submit button would be cool cos the extension is made for people without a clue and since it uses wiki formatting it forces unhappy surprises after posting a comment and such visitors won't see a way to edit it correctly. It would make even more sense when the Edit Toolbar was loaded. --Subfader 23:23, 21 August 2007 (UTC)


 * 2,5 years later this would still be useful. Anyone? --Subfader 16:16, 1 May 2010 (UTC)


 * :( --Subfader 20:09, 17 December 2010 (UTC)


 * :( --Subfader 18:30, 5 June 2011 (UTC)


 * :( --Subfader (talk) 10:57, 25 August 2013 (UTC)


 * :( --79.228.92.35 13:05, 10 May 2014 (UTC)

Latest Comments
How can I display a list of pages with new comments on? Something like and maybe even make parts of the comments display on that list just like searching in the Talk namespace does? I guess it's not possible cos you'd have to change includes/SpecialNewpages.php? What about creating a Special:Newcomments.php instead? --Subfader 23:15, 21 August 2007 (UTC)
 * See below "Leave Comment" + all comments on all article pages --Subfader

Special:ProcessComment
This is a good extension (more stable than beta IMHO), but the Special:ProcessComment special page at Special:Specialpages is annoying. This should fix it:

Basically, I changed one  to   in the   function to make it an unlisted special page. -- Sayuri 13:38, 24 September 2007 (UTC)


 * Thanks Sayuri! You have a good point about not listing the special page, next time I revisit the code, I'll add that. Also, regarding "beta" status - thanks!  I take my released code very seriously, so if you find any other troubles, please let me know. -- Jimbojw 15:35, 24 September 2007 (UTC)

Captcha support
Other users here have already asked that ~ would be used instead of asking for a name. Thus one would know if a comment was written by a registered user or by an anonymous user. And speaking of anonymous users, Captcha support is reallly required for them. -79.183.105.239 15:16, 22 December 2007 (UTC)


 * I have considered integrating with the Captcha extension - just haven't gotten around to it yet. :/ --Jimbojw (talk | blog) 17:50, 18 March 2008 (UTC)


 * Captchas are the worst anti-spam solution if you want non-logged-in users to leave comments. You should use $wgSpamRegex and my SimpleAntiBot solution and check if this reduces spam after a few weeks of testing. --Subfader 23:30, 19 May 2009 (UTC)


 * I have patch that requires ReCAPTCHA answer for everyone who wants to leave a comment. Try it here and let me know if you are interested. -- Jaroslav Tulach, Jun 11, 2009

Customizable fields
Maybe somehow use a template for the fields? -79.183.105.239 15:16, 22 December 2007 (UTC)

No SPAM protection!
The spammers now shit on my site via comments. What can I do? Everything I have set up on $wgSpamRegex and Extension:SpamBlacklist is not affected by the comment process. I.e. I cannot enter bad words / domains by editing a talk page the normal way, but when I leave a comment everything is possible. Please fix asap. --Subfader 12:54, 16 March 2008 (UTC)


 * Version 0.4.2 now has support for $wgSpamRegex. I have not yet integrated with the SpamBlacklist extension.  --Jimbojw (talk | blog) 17:48, 18 March 2008 (UTC)


 * Thanks. Updated :) --Subfader 11:19, 29 March 2008 (UTC)


 * Same problems, could you please address a short note on how to make ArticleComments & $wgSpamRegex work together? --sylvain 11:19, 15 May 2008 (UTC)

Can this extension work with a captcha? i.e. we use reCaptcha on our site... --Dmb 09:31, 27 January 2009 (UTC)
 * Mind that captchas for comments are annoying if people post comments more frequently. --Subfader 02:32, 28 January 2009 (UTC)


 * Here is what I've done to get rid of spams. Add this line in defaultArticleCommentSpamCheck function --Sebastien Damaye, aldeid.com 2011-12-12 09:57:00

if(ereg('yes', file_get_contents('http&#58;//www.stopforumspam.com/api?ip='.getenv(REMOTE_ADDR)))) { return $isspam = true; }
 * 1) Addon: check IP reputation - Sebastien Damaye, aldeid.com


 * Thanks for this. --Subfader 19:59, 12 December 2011 (UTC)

Error Message
I just enabled this extension on my wiki, however when I attempt to leave a comment, I get the following error message:

Sorry, the article "Whatever" is not accepting comments at this time.

Anyone have an idea as to what the problem could be?
 * You didn't "allow" the namespace in LocalSettings.php. E.g.:

require_once('extensions/ArticleComments.php'); $wgArticleCommentsNSDisplayList = array(NS_MAIN, NS_TALK, NS_HELP, NS_HELP_TALK); --Subfader 11:13, 29 March 2008 (UTC)

"Leave Comment" + all comments on all article pages
I wrote a step by step guide to do so: User:Subfader/Article Comments. What it will do:

The following explains how to enable having the "Leave a comment" link per default at the bottom of all pages of the namespaces you define + how to display the left comments from the discussion page below the article.

All that per default without adding  or   code to each individual article.

This includes displaying the comments on your article discussion pages left before you installed this extension and displaying the "Leave a comment" link on maybe unrelated (like non exisiting) pages or pages you may better not want to have visitor comments on e.g. Main Page. Atm there is no way to diasable the form once you went through this. Disabling would require a Magic Word like __NOCOMMENTSHERE__. But it's still very useful if you already have hundreds of articles in your wiki...

Jimbojw: Use my text as you like. Thanks for this great extension and your help back then although you won't rememeber me ;) --Subfader 15:57, 30 March 2008 (UTC)


 * Update: You CAN disable it on certain pages see below but it requires setting each page name manually into core code. --Subfader 01:25, 16 March 2009 (UTC)


 * Hi the code is great on new pages that I create, but on the pages that I had already it comes up with two links "Leave a comment" and below that a comment form. How do I modify it so I only have one comment form or one link. Also how do I get rid of the line 'comments on 'name of page'(link) Thanks LucyTech


 * Remove the manually added  tags? --Subfader 19:05, 6 June 2011 (UTC)
 * I didn't maually add I've used the code User:Subfader/Article Comments and change monobook.php. It does say on the page 'It still needs some modification to remove the second "Leave a comment" link and "Comments on ..." below the headline.' but how do I do this modification!!? I'm really stuck and can't put it on my site until this is sorted. Any help would be great. Thanks LucyTech. 7 June 2011

Try the headerfooter extension

PHP Notice: Undefined index:
Leaving comments works fine, but I checked my error log: With every comment being left I get a "PHP Notice: Undefined index:" for each line in ArticleComments.php: # Retrieve submitted values $titleKey = $_POST['titleKey']; $titleNS = intval($_POST['titleNS']); $commenterName = $_POST['commenterName']; $commenterURL = $_POST['commenterURL']; $comment = $_POST['comment']; E.g.: PHP Notice: Undefined index:  titleKey in /...root.../  Any idea? --Subfader 09:08, 5 April 2008 (UTC)

Easy delete single comment button
I'd like to see a simple [x] in the upper right of each comment so it's easy to delete a certain comment without editing the discussion page and grabbing throw the div codes (which is quite annoying. [x] should only show up to users per group definition. --Subfader 11:01, 15 May 2008 (UTC)

Redirect back to original page after comment submission
Someone asked for that feature and for me it works to add at the very end of function specialProcessComment after the lines $wgOut->setPageTitle(wfMsgForContent($ac.'submission-succeeded')); $wgOut->addWikiText(wfMsgForContent($ac.'submission-success', $title->getPrefixedText)); $wgOut->addWikiText(wfMsgForContent($ac.'submission-view-all', $talkTitle->getPrefixedText)); these two lines: global $wgServer, $wgScriptPath; $wgOut->redirect($wgServer.$wgScriptPath.'/index.php/'.$title->getPrefixedText);

and than one is redirected back to the page with the comment tag. Works for me on MW 1.11.1 Optimale 11:02, 10 July 2008 (UTC)


 * Thanks, without a page reload leaving a comment now feels like ajax :) --Subfader 16:11, 10 July 2008 (UTC)

Append ?action=purge to the redirect otherwise it brings you back to the original page, but without the new comment! It's a cache thing. Make the last line: $wgOut->redirect($wgServer.$wgScriptPath.'/index.php/'.$title->getPrefixedText."?action=purge");
 * you can replace

$wgServer.$wgScriptPath.'/index.php/'.$title->getPrefixedText."?action=purge" with $title->escapeLocalURL Superxain 16:05, 4 November 2010 (UTC)

Error
Whenever I go into topics with the tag in I get the error:

Notice: Undefined index: showurlfield in /home/alexmac/public_html/tutorials/extensions/ArticleComments.php on line 176

Notice: Undefined index: showurlfield in /home/alexmac/public_html/tutorials/extensions/ArticleComments.php on line 176

I have installed it as it said.


 * I also have it (mentioned above somewhere) but don't mind it anymore. --Subfader 14:02, 9 September 2008 (UTC)

--Karl Picard 14:38 8 Oct 2010 Was there ever a solution for this as I keep getting this error as well, doesn't affect functionality but people complain about errors

Conditional Show hides ALL Comments
Hi there. I am using conditional show and maybe I am doing something wrong, but it's hiding ALL comments. I'd like for users who are not logged in to be able to see the previous comments (but not the form.)

Thanks.

Don't display on certain pages in allowed namespace
'''It only worked for me on localhost. I was not able to reproduce it on the server. If you have a solution, please post.''' To hide the form on a certain page in a namespace you allowed; change the following as for the example Main Page in ArticleComments.php # Display the form if (in_array($title->getNamespace, $nsList)) { echo(wfArticleCommentForm($title, $params)); } to   # Display the form if (in_array($title->getNamespace, $nsList) && $wgTitle != 'Main Page') { echo(wfArticleCommentForm($title, $params)); } and if you used "my hack" to display the left comments on the article page itself change MonoBook.php: global $wgTitle, $wgRequest; if(in_array($wgTitle->getNamespace, array(NS_MAIN, NS_HELP, NS_PROJECT))&&       (!$wgRequest->getVal('action') || $wgRequest->getVal('action')=='view')    ) { to global $wgTitle, $wgRequest; if(in_array($wgTitle->getNamespace, array(NS_MAIN, NS_HELP, NS_PROJECT)) && $wgTitle != 'Main Page' &&       (!$wgRequest->getVal('action') || $wgRequest->getVal('action')=='view')    ) { To add more pages it should be enough to double the string on each e.g. && $wgTitle != 'Main Page' && $wgTitle != 'Some Article' --Subfader 16:15, 4 October 2008 (UTC)
 * Update: Works fine on server :) --Subfader 01:25, 16 March 2009 (UTC)

Comments in place
I've hacked this extension into posting comments just above the  tag (on whatever page the tag is on), and signing the comment with   (i.e. not asking for the user's name, using IP address if not logged in). If anyone wants a diff, shoot me an email. &#x2014;alxndr&#x00a0; (t) 04:06, 15 September 2007 (UTC)

I've had a play with this and a couple of other extensions
I hope this is clear when I describe it if not I'll try to set up an externally accessible wiki as an example.

Our wiki is used by people with little or no IT skills so I liked the look of 'ArticleComments' Extension:ArticleComments as it would allow me to have a small web form on the article pages that allows users to post comments to the discussion page without using the wiki editing system.

However ArticleComments requires a tag to be added to pages that you want the form to appear on, not wanting to have to do this manually on each page, I solved this using an extension HeaderFooter Extension:Header_Footer that will add a standard header / footer to any page within a name space.

I also wanted the ability to add comments, be available only to people who have logged in, we display the following on each page if users are not logged in:-
 * Log In at the top of the page to add your own comments or suggestions about this topic for other staff to read on the 'Discussion' page.
 * (Use the Submit Feedback link on the left it you want to contact the policy officers)

To do this I used the extension ConditionalShow Extension:ConditionalShow so I have a template :-

* * Log In at the top of the page to add your own comments or suggestions about this topic for other staff to read on the 'Discussion' page. (Use the Submit Feedback link on the left it you want to contact the policy officers) * Log In at the top of the page to add your own comments or suggestions about this topic for other staff to read on the 'Discussion' page. (Use the Submit Feedback link on the left it you want to contact the policy officers)

So basically conditional show is used to decide what to display in the footer either the comments form or the login message, based on whether the user has logged in, HeaderFooter adds this as a footer to the relevant pages, and if it's the tag then the user gets the comments form. --Unsigned

@Unsigned - I have been trying you approach. However, the comments have not been fully rendering. I am seeing things like 'NaN 5 minutess ago instead of just 5 minutes ago. Did you encounter this issue and if so, how did you address it?

Comment not added (+ Java script extension from User:Pannini/ArticleComments )
After i add a new comment and click on "show comments" the new Comment is not added only in the discussion page but not on the mainpage. Only if i save the page again.

Can somebody help me??

Thanks Jan

See Manual:Purge for purgin cache.

OK Thanks for the information. Now it works. I add this to localsettings.php $wgScript          = "$wgScriptPath/index.php"; $wgArticlePath     = "$wgScript/$1?action=purge";

I dont know if its so right but it works. Thanks again

SimpleAntiBot
If you allowed comments by non-logged-in users you may know those stupid comments left by bots telling you how great your website is or just leaving (mostly russian) website links. For the latter I was happy to see $wgSpamRegex working with this extension but you can only add new rules after the damage. Filter ".ru/" and you disable 50% of the spam (including the slash which I always received to the URL :) Usability-wise any other spam protection is better than using captchas for visitor comments, trust me.

Anway, $wgSpamRegex is not enough? Here's a simple solution to stop bots spamming your wiki via comments. It uses the trick of Extension:SimpleAntiSpam (but there is no need to install it for this tweak). This extension is used by e.g. wikipedia but only affects real page edits. Since bots don't view your website in a browser but check the source code etc and try to fill all given fields, this works quite well:

Add a hidden input field to the comment form. It uses display:none so it's only hidden for humans watching a website but not for bots which will simply fill it with their crap text. The comment will only be processed if the hidden input is empty. If filled, the form will refuse the comment and return the same error message as if the comment itself was missing.

Edit ArticleComments.php and into $content below add: This adds the hidden div with a fake label "Hompage" and fake input field named "wpAuthorHomepage" in my case cos I disabled the real Homapge field by default. So i chose to use Homepage to be sure 99% of the bots would fill it. If you use the real "Homepage", rename it to e.g. E-Mail or sth.

In function specialProcessComment add  as global: and replace with: The  above is not very elegant cos it returns the empty message error. On the other hand nobody would see it anyway assuming display:none works in the browser or is not disabled in another way. Then maybe a real warning should be returned (too lazy).

Remove the display:none in the div style to test it yourself by filling the field like a bot would. You need to purge the page cache to see it.

--Subfader 00:40, 16 March 2009 (UTC)
 * After 1 month in use I can say I clearly reduced spam comments. Of course still humans leave some "fghdfggfh" comments but you can't stop those this way :) --Subfader 11:22, 20 April 2009 (UTC)
 * Isn't it possible to do a check where the first line of the comment is read and you do a char to char comparison?


 * something like:


 * if (char1 == char3 && char2 == char4){delete comment} so that the atleast cant write fgfgfgfg AndiRay 13:48, 23 April 2009 (UTC)
 * Block comments with bad words using $wgSpamRegex --Subfader 15:39, 23 April 2009 (UTC)

LeaveComment statement on every page, with exeptions, and modified talk page
I wanted to have a "leave comment..." statement at the bottom of every site (except mainsites, like User:Subfader/Article Comments) and I wanted it to open a talkpage to each article (like the extension does by default). On the talkpage I wanted the "leave comment..." statement to stand at the top... beneath the comments should be displayed like 1 but the newest ontop.

just check out my changes User:AndiRay/Article Comments and thx for all the info you guys already posted ;)

AndiRay 08:16, 20 April 2009 (UTC)

Error on MW 1.6
I get this error on MW 1.6. Everithing seems to work but after I enter the text and submit it I get the error! Is it because of the upgrades? Have you added something that 1.6 does not support?

Add Cache
You should add a cache on the comment box using the ConfirmEdit. Sachein 21:35, 11 May 2009 (UTC)


 * Add Cache? Anyway, captchas are a very bad solution to stop spam IMO (usability-wise). --Subfader 23:22, 19 May 2009 (UTC)

Define which talk to post to?
Is it possible to post the on say the Main Page but have the comments directed to the talk page of a specific user instead of the Main Page talk? - Omniomi 17:38, 21 May 2009 (UTC)
 * Note: I only need the comment option will always go to the same location, so a hard coded option is fine. I just cannot figure out what to edit in the source. - Omniomi
 * Which User talk page should it go to? to the User page of the posting person or whos article it is? you should look at the code in ArticleComments.php at

$title = Title::newFromDBkey($titleKey); $title->mNamespace = $titleNS - ($titleNS % 2); $article = new Article($title); $talkTitle = Title::newFromDBkey($commenterName);//Orig. titleKey changed to current Username $talkTitle->mNamespace = 2 + 1 - ($titleNS % 2);//Orig. titleNS changed to User Namespace $talkArticle = new Article($talkTitle);
 * 1) Setup title and talkTitle object

Just try this out and tell me if that is what your looking for ^^ if not i will take a look at it again... It could be that this only worked on my site because of changes I made. User:AndiRay/Article Comments AndiRay 14:40, 2 June 2009 (UTC)

Leaving another comment as anonymous user
When you display the comments on the article + you're not logged in + leave a comment that is not the first comment = it will not show up (but it's there though). Oddwise it works when you're logged in. Anyone else noticed this? Is there a solution? --Subfader 01:18, 9 June 2009 (UTC)

Cannot modify header information
When i put this extension, there's an error like this:

Cannot modify header information - headers already sent by (output started at C:\xampp\htdocs\mediawiki\extensions\ArticleComments.php:1) in C:\xampp\htdocs\mediawiki\includes\WebResponse.php on line 16 Main

Do you know what happens? Any advice is appreciated. --Zozzen 12:32, 28 July 2009 (UTC)

don't work in custom namespaces?
I'm using a custom namespace (Wlog) and the extension it's not working for it. Any solution or workaround? (|test page with custom NS & test in sandbox)

--Dvdgmz 18:23, 2 September 2009 (UTC)


 * Sorry. But that's not the problem. It seems that don't work fine when I call the comments from a template. --Dvdgmz 07:24, 3 September 2009 (UTC)
 * The problem seems to be solved setting NS_TEMPLATE in $wgArticleCommentsNSDisplayList. I put  in Localsettings.php after the 'require_once' --Dvdgmz 08:05, 3 September 2009 (UTC)

does not work with PHP 5.3
After I upgraded PHP to Version 5.3 this extension does not work for my anymore. I get this message on every page where I set the comments tag.

Look here for more information: Hooks not working for PHP 5.3.0 Monon 14:50, 2 October 2009 (UTC)

how to sort comments backwards
i want to sort the comments backwards, so that a new comment will be always on the top. can you help me? --Unsigned


 * That's not possible as is. Atm new comments are just added to the end of the talk page. Adding it on top would mean to add it below the heeading and above the last comment which might be difficult to realize. And even if, it wouldn't be backward compatible. --Subfader 14:17, 7 October 2009 (UTC)


 * I did it!! Change this

} else if ($posBelow!==false) { # Insert comments below HTML marker $talkContent = substr( $talkContent, 0, $posBelow + 21 ). $commentText. substr( $talkContent, $posBelow + 21 );

to

} else if ($posBelow!==true) { # Insert comments below HTML marker $talkContent = substr( $talkContent, 0, $posBelow + 85 ). $commentText. substr( $talkContent, $posBelow + 85 );

Name logged in user
Name logged in User is not filled in. (I use mediawiki 1.15.1). --NandaJansen 14:30, 31 October 2009 (UTC)

ConfirmEdit for addURL
Extension:ConfirmEdit has a nice setting for "addURL": When a user adds an URL he has to confirm the edit by a simple math question. This seems like a perfect addition to a wiki's spam protection. However, this is ignored using the comment form. Anyone? --Subfader 20:16, 28 April 2010 (UTC)

Trim whitespace from beginning and end of comment
It's recommended to trim whitespace from the beginning and end of comments. Replace $comment = $_POST['comment']; with $comment = trim($_POST['comment']); --Subfader 23:17, 1 May 2010 (UTC)

"No such special page"
Installed, I can see the "Leave a Comment" link on the pages, but when I submit a comment I get a "No such special page - You have requested an invalid special page..." I see "Process Article Comment" on the list of special pages, and even clicking that link directly takes me to the same error.

I'm running 1.15.3. Have not modified the php in any way.


 * OK, I figured it out. I have an extension installed called DisableSpecialPages, which allows you to disable viewing of certain special pages. I disabled it in my LocalSettings.php and suddenly the comments worked. Even though ProcessComment was NOT in DisableSpecialPages' blacklist array, the extension was apparently interfering somehow.

Fatal error
Hi,

I have latest version of article comments on MW 1.15.2, and when I try to leave a comment I get:

Fatal error: Call to a member function getCleanSignatures on a non-object in C:\Inetpub\vhosts\recordsrx.com\httpdocs\wiki\includes\parser\Parser.php on line 3870

Any ideas?

Thanks 222.154.189.19 20:39, 4 July 2010 (UTC)

I got the same error. any solutions? It happens when you set your signature to no wiki links.--180.158.183.172 09:36, 10 November 2011 (UTC)

Hi - I've got the same error. Can anybody help?

Force new filecache
I use the above modifcations for including comments on the article page directly. Now I want to use file cache but after submitting, the (anonymous) user sees the old cached page again. So the cached version for the article needs to be rewritten after a comment is submitted. I thought of something like this after the spam check, but it doesn't work. $cache = new HTMLFileCache( $title ); ob_start( array(&$cache, 'saveToFileCache' ) ); Any idea how to force it? --Subfader 20:48, 19 August 2010 (UTC)

Adding two inputs to the comment form
Hi i would like to add two more inputs to the comment form, an option and another text field. How can i do this being also able to use them with the template? Thanks in advance,

Cbesozzi 9.24, 22 Novembre 2010 (UTC)

Problem with MW 1.16 - PHP 5.3.0 - MySQL 5.1.37
On the top of each page the following warning appears:

Warning: Missing argument 2 for wfArticleCommentsAfterContentin F:\xampp\htdocs\wiki\extensions\ArticleComments\ArticleComments.php on line 212

Is this problem well-known? Is there any solution or what is the reason for that bug. The Input Fields on the lower end are correct. I can fill the form with text and the text is shown on the discussion page correct. And, by the way, if I format a headline with == TEXT ==, the following signs appears: UNIQ65f7ecaaa021379-h-0--QINU in front of the headlined TEXT. The version of ArticleComments is the latest 0.6

I hope there is a solution for my problem

06.12.2010 00:05 B0tt1
 * See here. --Subfader 20:07, 17 December 2010 (UTC)

Thanks for that reply, but please don´t get angry - what should I do now ?? I´m not that kind of pro, hacking some rows in some sourcecode to make this extension run. As far I understood the problem, it is a bug with PHP 5.3. Is there a solution for it or should I downgrade to a lower version. I´m using XAMPP on a stick. And by the way, my english is very poor, so I have problems to follow the special discussion. Thanks for a little more help. 21.12.2010 21:56 B0tti

After testing to downgrade to a lower PHP-Version I´m still by PHP 5.2.6 The same error. I´m sure, the error has to do with the Mediawiki 1.16,because every version of XAMPP from 1.7.4 down to 1.6.8 produces the same error. And now ?? 22.12.2010 23:16 B0tti
 * In ArticleComments.php, make the following additions and subtractions (based on ArticleComments version 0.6)

- function wfArticleCommentsAfterContent( $data, $skin ) { + function wfArticleCommentsAfterContent( &$data ) { -	global $wgRequest, $wgArticleCommentsNSDisplayList; +	global $wgRequest, $wgArticleCommentsNSDisplayList, $wgUser;

# Short-circuit for anything other than action=view or action=purge if ( $wgRequest->getVal( 'action' ) &&		$wgRequest->getVal( 'action' ) != 'view' &&		$wgRequest->getVal( 'action' ) != 'purge'	) {		return true; }

# Short-circuit if displaylist is undefined, empty or null if ( $wgArticleCommentsNSDisplayList == null ) { return true; }

+     $skin = $wgUser->getSkin; $title = $skin->getTitle; if ( !$title->exists ) { return true; }
 * --Skew 20:14, 29 December 2010 (UTC)

@ Skew - Thank you very much for this clear and well-to-understand instructions. I made the changes as described and really, the error message at the top of the site is gone. I´m very happy with that. But there is one bug still alive. If I have a headline in the text, some signs appears in front of the headlined text. So the extension is still unusable for me. Maybe you can solve this bug also ???? The signs are looking like this "UNIQ4cb4b3174c94ba80-h-1--QINU" and then the Headline follows. B0tti, 01.01.2011 22:45
 * Maybe me or someone else might get a chance to look at it later, but I'm focussed on other things for my site right now. I'm not sure what you mean by headline (Header 1 maybe?).  You should make a new heading for your problem and explain it a little clearer, perhaps showing the wiki text that replicates your issue.  --Skew 00:18, 3 January 2011 (UTC)

UNIQ QINO issue, with some partial, but not pretty solutions
I am having the issue he just described. Essentially if comments are activated on a page it turns any wiki heading such as ==test== into something which looks like this:"UNIQ6260e24221168978-h-0--QINUtest"The problem can be seen here. I've made some minor changes to the source code as you can see, but the problem still occurs off a fresh install.
 * Enclosing content in noinclude tags seems to fix the problem with headings, but its a pretty ugly fix. This extension also appears to break a widget I use, and noinclude doesn't fix that.
 * If you place content after the tag it appears to fix both issues... but I don't really want the comments form sitting half way up the page.
 * I've tried disabling all the other extensions, apart from semanticwiki which I can't disable without disabling the wiki itelf, and none of them are causing the problem.
 * I found one or two sources who attribute problems like this to the use of $wOut but that doesn't seem to be the problem here, or anyway I can't see how it could be (not that I'm an expert).
 * Some sources also suggested zend.ze1_compatibility_mode as the culprit, but I checked and mine is off.

Urbanvintner 09:41, 23 January 2011 (UTC)

Doesn’t work properly with MW 1.16.2
It works, but the heading of each title is like this:











Any idea? Maybe it’s just a little change, for someone who know the ropes. Many thanks in advance.

Installed software

MediaWiki 1.16.2 PHP 5.2.14 (cgi) MySQL 5.0.77-log


 * Got ArticleComments.i18n.php? --Subfader 00:31, 20 February 2011 (UTC)

Solved

Subfader gave the impulse. It works with ArticleComments.i18n.php. Unfortanaly without collapsible/expandable navigation. But for now i think i can live with that. Thanks a lot for the quick response.

Fix for "No such special page" in MW 1.16.2, PHP 5.3.5
After making the changes to wfArticleCommentsAfterContent as suggested above, I still got "No such special page" when trying to add a comment, and going to Special:SpecialPages just shows the following error message: Fatal error: Class 'ProcessComment' not found in C:\xampp\htdocs\mediawiki-1.16.2\includes\GlobalFunctions.php on line 2786

I found a fix, you need to update the way the special page gets registered in ArticleComments.php. Change to

-- Matt V 192.93.164.28 16:13, 23 February 2011 (UTC)

Fixes
Hi, error mentioned above, I noted on my server which is running MW 1.16.0. and PHP 5.3.3. This error will not be just exactly in this version. Both corrections by Skew and Matt make a functional code. Thanks. But the documentation still refers to a skin parameter. It is a cleaner solution to this?

--Achiles 18:52, 4 April 2011 (UTC)

can not hide form
for unknown reasons, is always displayed !!! sancelot@free.fr

because the code was executed before the page was loaded... the same thing should be done for prefilling comment the following solves the problem :

Random codes show up after adding 1.17.0
After adding tag in an article, some gibberish codes popped up throughout the article. e.g.

UNIQe288f2f422154e4-ref-0000000D-QINU

UNIQe288f2f422154e4-ref-0000000A-QINU

Can someone explain what is going on and how to fix it?

>> Got the same problem. Any ideas? Thanks!

>>>> Same exact problem here. Thought I was the only one, but I guess not! --Blicarea 15:06, 4 September 2011 (UTC)

>>>>>> Maybe has something to do with this?

Comment display format- Website
How can i customize where the URL will show up? Shouldnt it have like $5 or something?

Re-sizing the user name who leave the comment
Hi There , Can i minimize the size of the font of user name who leave the comment? Thanks --Unsigned


 * Use CSS via MediaWiki:common.css --Subfader 14:49, 22 November 2011 (UTC)

Installation problem for Media Wiki 1.18 with file from jimbojw.com
Installing the plugin downloaded from jimbojw.com makes my server respond with an HTTP 500 code when trying to access any page in the wiki (though the rest of my site works fine). However, using the files in SVN works fine. I just did a diff between the two files, and the one on jimbojw.com is marked as version 0.4.3, while the one on SVN is 0.6. From the changelog I see that only from version 0.5 does it work with MediaWiki 1.16+. So, if my understanding is right that the two files should be identical, it might be a good idea to update the file on jimbojw.com.

How can i customize where the URL will show up? Shouldnt it have like $5 or something?

Textbox placement
Is there a way to make the textbox appear underneath the existing comments. I'd like to simplify this so that users don't have to click a link at the bottom of the list of comments. A link to respond to individual comments is logical, but I'd like to change this little function. I have already changed LocalSettings.php to include the following code (specifically the last line is what I perceived as important):

require_once("$IP/extensions/ArticleComments/ArticleComments.php");

$wgArticleCommentDefaults['showurlfield'] = false;

$wgArticleCommentDefaults['hideform'] = false;

Sadly, this doesn't seem to do the trick. Any help would be greatly appreciated. -- JustMe, 30 Jan 2012

upgrade to 1.8
I've upgraded my site to 1.8 and now I get the error Fatal error: Call to a member function addMessage on a non-object in public_html/mw/extensions/ArticleComments/ArticleComments.php on line 308 I tried commenting it out in LocalSettings but then I get the error Fatal error: Call to undefined function displayarticlecommentform in /public_html/mw/skins/MonoBook.php on line 93 What should I do?

ArticleComments field appers twice
Hello, I am using

MediaWiki 1.17.1

PHP 5.3.5 (apache2handler)

MySQL 5.5.8

Semantic Forms (Version 2.4)

Semantic MediaWiki (Version 1.6.1)

SMWHalo Extension (Version 1.6.0_29 [B28])

ArticleComments (Version 0.6)

Now the comment field appears twice. The first appearance directly in the article is the correct appearance. But a 2nd one appears is after the article content, directly after the category links. It is in the section of my used skin Vector.php.

In my old version it worked fine without any 2nd appearance. Although there was an in Vector.php, this section didn't appear on the article pages. My old version was:

MediaWiki 1.16.0

PHP 5.2.6-1+lenny16 (apache2handler)

MySQL 5.0.51a-24+lenny5

Semantic Forms (Version 2.0.8_4 [B152])

Semantic MediaWiki (Version 1.5.2_1 [B27])

SMWHalo Extension (Version 1.5.2_0-for-SMW-1.5.2 [B27])

ArticleComments (Version 0.4.1)

How to fix my bug?

--130.75.245.28 10:20, 22 March 2012 (UTC)

'''Use the right code. That was the cause with my wiki/ Bert'''

The "discussion" tab shouldn't appear on the edit page with the Monobook skin
Ftiercel (talk) 10:33, 8 April 2012 (UTC)


 * Use CSS:  --Subfader (talk) 10:47, 8 April 2012 (UTC)
 * Your tip is very useful. I will use it. However, it is not so important for me. I posted this message in order that this bug will be fixed for anyone. Ftiercel (talk) 15:27, 8 April 2012 (UTC)

how to add Email
hi,

i would users ask to add their email. how can i add a field like that?


 * Why would you want such a field in the form when the data is not used/saved ? --Subfader (talk) 16:42, 10 June 2012 (UTC)

comments dont appear, all text appear as labels
running extension version 0.6.1.
 * MediaWiki	1.19.2
 * PHP	5.4.4-1~lucid+1 (apache2handler)
 * MySQL	5.1.63-0ubuntu0.10.04.1

All text for the extension appears as labels. And comments do not appear at all. Below is what I see on my page, after submitting about 5 test comments.





    <article-comments-new-comment-heading> <article-comments-comment-contents> <article-comments-new-comment-heading> <article-comments-comment-contents> <article-comments-new-comment-heading> <article-comments-comment-contents> <article-comments-new-comment-head> <article-comments-comment-contents> <article-comments-new-comment-head> <article-comments-comment-contents>

Fatal Error
ArticleComments.php on line 277

Version 1.19+

Any fix?


 * Found the issue. Seems like $wgMessageCache was deprecated in 1.18, thus rendering all extension which rely on this syntax inoperable. I'm looking into coding an alternative using MessagesPreLoad as an alternative (if that's even possible) this weekend. We'll see where that goes.

Extension does not load at all

 * MediaWiki 	1.21.1
 * PHP 	5.3.3 (apache2handler)
 * MySQL 	5.1.69


 * 1) Installed Mediwiki on Mac OSX 10.8.4 via the Bitnami Stack.
 * 2) Copied the source code for ArticleComments.php and saved it to my mediawiki/extensions/ArticleComments directory.
 * 3) Added require_once("$IP/extensions/ArticleComments/ArticleComments.php"); to various sections of my LocalSettings.php file (as a comment in this talk page indicated positioning of extension declarations can make a difference in them working or not).
 * 4) Tried using the version of require_once shown for non-Mediawiki 1.16 versions: require_once('extensions/ArticleComments.php'); with the file in the specified spot (in the extensions dir, not in it's own ArticleComments dir)
 * 5) Checked file and directory permissions on the extensions ArticleComments dirs
 * 6) Ran php -f ArticleComments.php --> no errors

That's the limit of my php and mediawiki kung fu.

It's dead, Jim.

Too bad because it looks like a useful extension...


 * Looks like it's because MessageCache was deprecated from MW as of 1.18, which has rendered some extensions (ArticleComments being one) inoperable. I'm going to work on coding it using the newer MessagePreLoad syntax, if possible.

Error message: missing "SpecialPage.php"
When I am installing ArticleComments I get the following error message: Warning: require_once(/Sites/.../includes/SpecialPage.php): failed to open stream: No such file or directory in /Sites/.../extensions/ArticleComments/ArticleComments.php on line 273 Fatal error: require_once: Failed opening required '/Sites/.../includes/SpecialPage.php' (include_path='.:') in /Sites/.../extensions/ArticleComments/ArticleComments.php on line 273

This is referring to the "SpecialPage.php", which is not missing, instead is in the subfolder /includes/specialpage/SpecialPage.php. When I change this in ArticleComments.php I get another error:. which is: I don't know where to go from here. Any ideas? --Zabien (talk) 14:29, 2 September 2014 (UTC)


 * Same problem while upgrading to MW 1.23.3. Via support desk:
 * In ArticleComments.php change

require_once($IP.'/includes/SpecialPage.php');
 * to

require_once($IP.'/includes/specialpage/SpecialPage.php');
 * and

SpecialPage::addPage(new SpecialPage('ProcessComment', ' ', false, 'specialProcessComment', false));
 * to

$wgSpecialPages['ProcessComment'] = 'ProcessComment';
 * --Subfader (talk) 15:49, 2 October 2014 (UTC)