|
Cookbook /
CommentBoxSummary: Adds a simple form to post comments
Version: 2.0.19 (released 2007-10-31)
Status: Stable
Prerequisites: pmwiki 2.0 and above; 2.1 recommended
Maintainer: jr
GoalGive authors a simple way to add a comment box to a wiki page. Solution
See also
Update: commentbox.phpΔ and commentboxplus.phpΔ are no longer allowing edit access to pages if no edit permission is present (a former security risk). - Jan 30, 2006. Note: this uses the run-in head markup to lay out comments, so requires the MarkupExtensions to work correctly. However, the variables can also be redefined to work with a standard PmWiki install.
InstallationPut commentbox.php into the cookbook/ directory. Add the following to local/config.php include_once("cookbook/commentbox.php");
UsageFollowing the (:searchbox:) directive naming convention, there are 2 new directives: (:commentbox:)
!!!!12 July 2005
!21:39 by '''[[~Pm]]'''!post again
!21:39 by '''[[~Pm]]'''!Test comment
posts comments latest first
(:commentboxchrono:) posts comments latest last
You can put (:commentbox:) in a GroupHeader -- all comments get posted at the top of the page. You can put (:commentboxchrono:) in a GroupFooter -- all comments get posted at the bottom of the page. If the page name ends in Journal or Diary (configurable), the script automatically inserts a comment box after the GroupHeader and before the text. You don't have to state e.g. (:commentbox:) anywhere for this feature (except loading in local/config.php of course) Posting comments to other pagesThis is a new feature. The recipe also supports posting comments to different pages with the (:commentbox pagename:) option. As this is potentially a security risk, there are a number of controls in place using global variables that an administrator sets in local/config.php:
Format of commentsAn administrator can control the format of comment entries using the following variables. See also samples in source.
The $Date, $Time and $Author strings get str_replaced with the current values within the script. Note the $ for variables defined using " ... ". Administrators will want to test their use of "n" carefully -- the script author kept having too many or too few, leading to unexpected (and unwanted) results.
Journal
SDV($JPDateFmt,'!!!!$Date');
SDV($JPTimeFmt,"\n\n>>journal<<\n!\$Time!");
SDV($JPItemEndFmt,"\n>><<");
Diary
SDV($DPDateFmt,">>diary<<\n!$Date!");
SDV($DPItemFmt,"\n\n: :");
SDV($DPItemEndFmt,"\n>><<");
Message
The default styling is h4.journalhead, h4.messagehead { background:#ffb; border-top:1px dotted #999; }
.message, .journal, .diary {
padding:3px;
border:1px dotted #999;
background:#ffc;
}
History
ContributorsComments(older comments that have been covered in subsequent bug fixes have been removed) jr
Here's what we might do... First, use a date markup yyyy-mm-dd that gets rendered as a long date. Then set an "omit postings older than $Today - $ExpiredCommentsAfterDays" options. For example (:commentbox 30:) would omit postings more than 30 days old. Finally, we'd need to add "show all" "hide all" "hide expired" links. Is this the kind of thing we want?
Thanks for pointing out the security risk. I thought it was enough to hide the comment box, but you are right, it leaves the site open. I will see if this is fixable, meanwhile disable it on my site . What a shame. - HansB
I fixed commentboxstyled.phpΔ with additional security features to make it impossible to edit other pages on an edit protected site. - HansB January 08, 2006, at 09:39 AM
I think the following change fixes the problem. Add this line at the start of the HandleCommentPost function:
if (!@$_POST['post']) Redirect($pagename);
Great recipe! Update: I found a workaround by using the [[<<]] instead. Nothing changes when a comment is posted now. This was a bug caused by the subsequent pmwiki edit handler calling stripmagic and removing single backslashes. Fixed in version 2.0.13. jr
This is Ridiculous.Would it be possible to make the layout a little more difficult to modify? Otherwise, thanks for a solid recipe. UPDATE. You know what, I take it back. This recipe is totally unstable if modified in any way, even for layout changes. How about this: When I included it in a groupfooter it posts the comment above the rest of the page content, and this obvious bug is still in this recipe despite the authors recommendation that the commentbox markup be PUT in the groupfooter. This recipe sucks, and there is no alternative unless one wants to go into comment-pages or mySQL stuff. Which I don't. This problem is not local to this recipe. The sort of instability, dirty versioning and general mishmashing of code exemplified by this crappy code extension is just the sort of problem absolutely plagues PMWiki in it's entirety. the PMWiki philosophy is "leave the extensions out of the core code and let people install what they need to." this is a great philosophy and I am behind it. But the PMWiki strategy is then to take a Wikipedia approach to code: let everyone modify whatever they want, whenever they want, and release it as gospel to the general user public. THIS WORKS (sortof) FOR INFORMATION BUT NOT FOR CODE. I am sick of things half working. PMWiki could be an excellent piece of software, but PM has to exert a lot more authority. There are basic things people want, and they all have to work, and they have to work well together. A blog, a forum, a commentbox, etc. These are CORE EXTENSIONS. These need to be crisp, well-maintained and versioned, and singular - I am saying ONE endorsed extension for all the major components that people want in a website. There is a place for the arena-style development that is currently throttling the Cookbook. It is excellent to have lots of developers putting new stuff out there and improving (sometimes de-proving) on each other's work. But let me say it again my point is that there are about eight blog recipes and none of them are polished. This is basic functionality and PMWiki has still not got it figured out. Until PMWiki has this, it is going to remain a stew of code that is best used as a jumping off point for PHP developers to create their own wiki, because anything a basic user tries to do will be forever bugged. Personally? I'm going off to search for a program that has some idea of what it wants to be. - Disenchanted user Obi The recipe works as advertised. It suggests placing (:commentboxchrono:) in a group footer -- comments will be added to the bottom of the page. It suggests placing (:commentbox:) in a group header -- comments will be added to the top of the page. Perhaps it should explicitly advise against using (:commentboxchrono:) in a group header and (:commentbox:) in a group footer.
Not completely ridiculous.I totally support the idea that core functions like blogs, comments, etc should have an official implementation, and also think that such basics should arrive in the default installation. OTOH, I think PmWiki is about empowering people to write their own quirky variations that wouldn't come in either an official or a free-for-all recipe. This is why I like it - it teaches me PHP. That's why it's called a cookbook and not a restaurant. However, if that is the intention, how come I can't find any docs about the overall architecture? - Adrian.
|