[pmwiki-users] Recommended recipes?

[Kathryn Andersen]

On Fri, Aug 28, 2009 at 02:06:36PM +0200, Twylite wrote:
> It's a bit of a catch-22.  As I mentioned in my mail I am intending to 
> set up 2 sites:
> (1) A knowledge base for my development team, with additional support 
> for issue tracking and CRM.
(puts on Workplace Webmaster's hat)
Knowledge base:

Not only do you want to make it easy for people to add knowledge, but
you want to make it easy for people to *find* knowledge.  So besides
just having wiki pages that link to each other in a tangled web, here
are some things I've found helpful:

* Structure: have different wiki groups for different purposes, whether
  that be a different wiki group for each project, or for resources, or
  whatever.
  If you feel that the single-level hierarchy that PmWiki has isn't
  enough, then you may want to use the Cluster recipe to overlay
  a pseudo-hierarchical structure on your wiki.
* Categories: make sure every page has a category on it.  If you feel
  that just "category" isn't enough, you may find the Tagger recipe
  useful in making it easier to have multiple kinds of category.
* AuthUser with HtpasswdForm: because it makes it easier to ask people
  about what they've written if you know who has written it, but it's
  easier (in an intranet) if you allow people to self-register.
  http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm
* DeleteAction: because you don't want people deleting pages
  accidentally.
* Restrict the creation of new groups (see
  http://www.pmwiki.org/wiki/PmWiki/WikiGroup)
  Initially I didn't do this, but I found I had to, because my users
  couldn't get it through their heads that a link in the form of "A.B"
  would create a new group "A" with a page "B".
* WikiTrails and Pagelists: are very powerful for organizing data,
  especially if you use PageTextVars to make the data on a given
  page even more structured.

Issue tracking:
The WikiForms recipe can be used for Issue tracking, and we use that for
some kinds of issues, but we also use a separate issue tracker (Mantis)
because it is more comprehensive and solely dedicated to issue-tracking.

But to make it easier to link specific issues to the knowledge base, I
use the InterMap markup (http://www.pmwiki.org/wiki/PmWiki/InterMap)
so that one can go

Issue:1234356

and it will link to the given issue (say,
http://www.example.com/mantis?issue=123456)

> (2) A personal web site with a blog (allowing public comments), a 
> knowledge base section (allowing public comments) and a collaborative 
> development section (open for all editing).
I haven't used PmWiki for blogging or public commenting, so I can't
really add much here.
 
> * Table of Contents
> http://www.pmwiki.org/wiki/Cookbook/PageTableOfContents looks widely 
> used, well supported, and is part of the PublishPDF library (which seems 
> like a good thing).  Uses (:toc:)

> But http://www.pmwiki.org/wiki/Cookbook/HandyTableOfContents is also 
> promising and - being JavaScript - may work in situations where 
> PageTableOfContents won't because of generated content.  Uses (:htoc:)
Personally I use both PageTableOfContents and HandyTableOfContents; I
created HandyTableOfContents for the (few) situations when
PageTableOfContents won't work; what I would suggest is to use (:toc:)
whenever you can, and only use (:htoc:) in the specific cases when you
absolutely need to, because you may find that you don't need to at all.
But I guess that's partly my own personal preference for avoiding
JavaScript on my pages if I can, because text-based browsers don't
support it.  That's why I made the markup (:htoc:), so that it could be
used alongside (:toc:) as well.

If you would like me to enhance HandyTableOfContents to optionally use
(:toc:) as its markup instead of (:htoc:) then I could look into that.

> http://www.pmwiki.org/wiki/Cookbook/NumberedHeaders also sounded useful 
> (especially in a corporate environment), but appears to be obsolete 
> because PageTableOfContents can do numbering now ... but that fact isn't 
> immediately obvious.  Uses (:toc:) and other markup.
Yes, I believe that NumberedHeaders is obsolete.

> Then there is http://www.pmwiki.org/wiki/Cookbook/SlimTableOfContents, 
> which will work with SectionEdit -- implying that other ToC recipes like 
> PageTableOfContents won't (and I still don't know the answer to that 
> until I try).  Uses (:toc:) or (:toc:)
> While some of these recipes have compatible markup, other's don't (or 
> have extended markup that would be incompatible across recipes).  
> Discovering a month in that I have made a poor choice will mean altering 
> the markup on numerous pages.

One thing I have noticed from posts on this list is that SectionEdit
tends not to play nice with other recipes.  So I would really avoid
using it if possible.
 
> * Restricted delete
> Recovering deleted pages is often not straightforward (sometimes not 
> possible at all, sometimes not possible through the web interface), so 
> it can be desirable to restrict page deleting to some set of authorised 
> users.
> http://www.pmwiki.org/wiki/Cookbook/DeleteAction seems to be the PmWiki 
> approach for doing this.

Yes, I've used DeleteAction ever since we lost pages because someone
accidentally deleted them.  At least with DeleteAction, one can recover
deleted pages from the command-line.
 
> * A better way to handle attachments
> Most CMS, Blog or Wiki software that supports attachments provides 
> built-in support or extensions to manage attachments: rename, delete, 
> show size and download count, etc.
> At a glance there are about a dozen extensions that may do this: 
> AttachDelete, AttachIcons2, AttachImageSize, AttachLinks, 
> AttachlistEnhanced, AttachListSort, AttachSize and 
> http://www.pmwiki.org/wiki/Cookbook/Attachtable.  The latter seems to 
> have the most functionality but is also the newest (few recommendations 
> an little information on the extent of its use).
I've really liked Attachtable once I started using it.  Being able to
delete attachments with a click and confirm has been very helpful.
 
> In addition I have encountered a couple of extensions that everyone 
> should know about:
> 
> * http://www.pmwiki.org/wiki/Cookbook/NewPageBoxPlus
> NewPageBoxPlus seems to be an excellent building block for just about 
> any site that requires pages based on a template.  For example it is 
> trivial to build a lightweight CRM by creating a "Customers" group with 
> a NewPageBoxPlus to create new customer pages from an appropriate 
> template. 
> There are alternatives, including 
> http://www.pmwiki.org/wiki/Cookbook/Fox from the same author which seems 
> extremely powerful but also a lot more complex (and it competes with 
> other Forms recipes, so they may also warrant consideration).
> If I hadn't encountered NewPageBoxPlus I may have moved on to evaluating 
> another Wiki engine!

As others have said, Fox is probably overkill if you just want a
new-page form; however, if you're blogging and want people to be able to
add comments, then Fox may be what you want, and if you're going to add
Fox, you might as well use it for other things as well.
 
On the other hand, if you find that your forms needs aren't quite enough
to justify the complexity of Fox, PmForms is a good choice too.

> Question: what about John Rankin and HansB - they also seem to be listed 
> as maintainers for a lot of extensions?
HansB is active here and his extensions are good.
John Rankin has written some powerful extensions, and he does maintain
them, but he doesn't seem to be quite as active as HansB.

Kathryn Andersen
-- 
 _--_|\     | Kathryn Andersen	<http://www.katspace.org>
/      \    | 
\_.--.*/    | GenFicCrit mailing list <http://www.katspace.org/gen_fic_crit/>
      v     | 
------------| Melbourne -> Victoria -> Australia -> Southern Hemisphere
Maranatha!  |	-> Earth -> Sol -> Milky Way Galaxy -> Universe