I'm going to need to put a forum into the same site as ewiki for my current project. If possible I'll write it in such a way that others can reuse the code on their projects features under consideration:

• User Logins/tracking
• Revision tracking
• Moderation
• Thread locking

One question I'm mulling over at the moment is just how to store the forum postings. Currently ewiki uses just one table for all the pages with the whole text of the page in a field on that table. The question for me is, assuming the board is run through ewiki should it be one page per record, one post per record, or a whole new table? My notion at the moment is to find a user control system and graft that on first so I can see what that requires from forums.

AndyFundinger: What I need is a forum that allows ThreadMode but does not allow users to edit eachothers comments. I'm going to put this in a corporate environment and in some areas I want to present a classic-looking web forum with support for WikiMarkup but not the ability to edit other user's comments.

milky: This sounds like the *EWIKI_DB_F_APPENDONLY idea that already arised several times before.

AndyFundinger: Was that implemented?

I've been thinking along these same lines. I'd like my pages to be a lockable wiki, that only I can edit, but allow visitors to place comments at the bottom (like the user manual at php.net. So far I've no ideas on how to implement this. -KitzelHoover

milky: Your needs would be suited by a 'double wiki' - one with static pages (or those only you can edit), and a second wiki just displayed below every page which would be editable by everyone else. an example:

   <?php
       #-- not editable wiki page
       $tmp = $ewiki_plugins["action"];
       unset($ewiki_plugins["action"]);
       echo ewiki_page();

       #-- editable comments (as a wiki page)
       $ewiki_plugins["action"] = $tmp;
       if (!strpos($ewiki_id, "_comments")) {
          $ewiki_id .= "_comments";
       }
       echo ewiki_page( $ewiki_id );
   ?>

This is probably not working but I would do it something that way (cheap solution). Note that authentication will never become core functionality (it's a Wiki, not a CMS), you have to code this yourself.

AndyFundinger: So, I'm thinking about how to implement this. My notion is that threads would consist of a page and a set of posts. The posts would consist of pages of the form "Forum EWIKI_NAME_DIVIDER {*ThreadName} EWIKI_NAME_DIVIDER POST{Post number}" if posts were allowed on the "thread page" this would be a comment mode. If text was not allowed on the "thread page" we have a plain forum. A "handler" plugin would then add a wiki action "create thread" for any page that has "Forum" in the title (or maybe metadata). The add post action could be similarly available on any page that has posts or all pages.

Development process: #DevProcess

1. add EWIKI_NAME_DIVIDER define to calendar plugin
2. Done: "aview" plugin to display all posts
3. Done: Add comment action
   1. Done: Make add comment action re-sort to beginning of list for pages with posts
4. Done: "aview" plugin to display all threads
5. Done: Add thread action
6. Make displaying a post show that post's thread/parent page instead.
7. Signatures?
8. Overgrown thread control
   1. Hide post function
   2. Display posts from last X days only
   3. display X posts at a time

Anything I'm missing? Once we have a rights system pages will be editable in a more limited fashion i.e. you can only edit your own post.

milky: The most interesting point is to correctly divide pages just by their names into ordinary wiki pages and specially handled pages. For a forum plugin one could choose all pages whose names begin with "Forum_" to be a forum page.

milky: The next point is to decide if it gets a board or a forum, then you'll know if you'll get names like *Forum_threadname_n1_n2_n3_n4 or just names like Board_threadname_nnn.

AndyFundinger: A thread would not have threads off of it, the highest level of organization would be a forum page though all it does is show a 'create thread' action (which creates an empty thread page and opens post001 for editing. If that isn't what you were asking I'm confused.

milky: Why should the calendar want to know about any character needed for the board handler? Why would users like to change it?

AndyFundinger: Defining a WikiNameSpaceDivision character would allow us to block that character from use in other page titles(or at least define them as erroneous). Users would not change this constant, I suggest defining it for programmer use.

*ryanknoll: How about incorporating an existing forum software? There are so many out there, both mysql and flat file, that are full featured already and you can probably use them by merging the authentication schemes.

milky: Most people will just run a forum software besides a Wiki, so it does not appear to be important at all if ewiki makes only one part of a web site (typical case).

A problem I see with integration of existing software, is that most of the boards and forums aren't integrateable at all - many such scripts are heavily bloated and strike to dominate the UI. So we would end up completely recoding such a forum, if we tried to integrate it.

And then it isn't such a big deal of making one our own. I simply refused, because this isn't really necessary, because Wiki already allows to discuss (even if people are unfamilar on how to do so in a Wiki).

AndyFundinger: Indeed, at each step of this process I do look for external forum packages but none seem to allow me to integrate searches and linking. Search is probably a small thing, I could integrate two search engines behind the scenes. But the linking can be big. If I'm to support a 'special' forum plugin at all--and it's on my list--the thing had best let me link to and from other wiki pages. If you can find a forum that heads in that direction I'd be very interested.