[Phpwiki-talk] PhpWiki enhancements and a humble request for some feedback...

[Rui C. <rui...@ac...>]

Hello,

Apologies for the long subject line. I tend to add summaries to 
everything these days. :)
Also, apologies for the rather long(ish) message, which we can break 
down into separate threads as discussion (hopefully) progresses.

First off, I've been fiddling with PhpWiki for a while now. After three 
months of not-very-subtle hacks, I now have a customized version up at 
http://mac.against.org that draws heavily from things like 
http://everything2.com and http://snipsnap.org.

Some of the customization was done via plugins, and you can see a 
(very) brief description of the SeeAlso and DotGraph plugins here:

http://mac.against.org/space/SeeAlso
http://mac.against.org/space/DotGraph

I've in fact been considering moving to SnipSnap - hence the URL 
structure I'm using - but have decided to stick around for a while and 
figure out where PhpWiki is heading and how I could contribute.

I've also deployed a modified version of my personal Wiki inside my 
company, where it's being used for software/process modelling (hence 
DotGraph) and project documentation (hence SeeAlso). Initial feedback 
was very encouraging, but there were several interesting issues and 
requirements that I came across and that I would like to have the 
list's opinion on:

1) CamelCase is extremely confusing to some people. Square brackets are 
easy to grasp, however, which is interesting. Of special note was the 
fact that coding standards (thisIsAModuleName) sprung "?" all over the 
place when posting code fragments, but that is a separate issue.

Yes, I know it's traditional. I've used Wikis for a while now, but only 
with techies. Case-insensitive bracketed links seem to work better 
(we're Portuguese, so cultural background must have some bearing on 
this that I've yet to grasp).

2) HTML (or simplified HTML) markup, with <code>/<pre> blocks exempt 
from parsing and "normal" headings, tables, etc. And not just for 
normal markup - RawHtml is  extremely useful for inserting HTML form 
mock-ups inside the Wiki, enabling developers to quickly show to 
prospective users what the project will look like, etc., but is fiddly 
to use (oh, yes, normal users abhore plugin syntax...)

3) File attachments (and Wiki markup to refer to them) are of paramount 
importance. I'm considering storing them in the database (an attachment 
becoming a Wiki "node" in its own right) and using something along the 
lines of {inline: NodeName} to refer to them. I was wondering what work 
was being done along these lines, and I've seen some recent posts 
concerning this, but have yet to fetch the code and see how this was 
handled.

Coding this would consist essentially of changing the database schema 
to hold the node mimetype alongside the content, doing some extra 
testing in getCurrentRevision(?) and suchlike and implementing a 
view.php URL handler.

(A wanton hack like serialize()ing stuff into the current database 
schema seems to work, but I've yet to do more than a couple 
experiments.)

4) ACLs. Not just user login (I will probably have to integrate our 
Wiki with an LDAP directory, but Apache can sort that out for me), but 
the ability for any given user to lock a page to prevent users on the 
same privilege level from changing it. It can probably be a Unix-like 
Owner-Group-All field, but I'd like to know what people's opinions are 
on this. User management (which is implied) is done outside the box.

5) Comments. Not inline comments (Wiki editing), but distinct entries 
attached to a parent node. It comes right alongside ACLs as a base 
requirement. I've toured the alpha Wiki, and I've seen some interesting 
things there, but it feels like it should be an intrinsic thing - 
people are wary of editing other people's work and breaking something.

6) XML. Oooh. OK, this one is tricky, in the sense that yes, you can 
generate XML from Wiki markup (and I'm quite fond of the current 
XmlElement module, which seems well thought out), but the idea of 
actually storing XML instead of Wiki markup (and converting between the 
two whenever necessary) has sprung to mind. It makes a lot of sense, 
and would ensure the content is reusable if we have to re-render/import 
it/swap it with other systems. What do the developers think of this?

7) CVS - not as a backend, but as an integrated tool. CVStrac 
(http://cvs.cvstrac.org) has merged CVS, issue management and a (very 
usable) Wiki, and the idea is very appealing. Have there been any 
efforts along these lines? Issue management is also very interesting, 
but we have other tools for that.

These were the recurring issues (and some of that can be seen in my 
http://mac.against.org/space/mac.2003-01-20 node...), and I'd love to 
know what other people think.

Again, sorry for the long(ish) post, but scouring the mailing-list 
archives was not very useful in terms of understanding where PhpWiki 
stands where most of these issues are concerned, and the main PhpWiki 
has a rather sketchy feature roadmap.

So I just had to ask. :)

Best Regards,

Rui Carmo