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

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

On Saturday, Jan 25, 2003, at 00:30 Europe/Lisbon, Joby Walker wrote:

> Rui,
>
> We always welcome new developers.  I'm pretty new myself...

I can contribute my code (and layouts/theme/templates), as soon as I 
can remove the embarassing bits.
  :)

> More comments inline:
>
> Rui Carmo wrote:
>> 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
>
> Is this the changing gradient links at the bottom?

Yep. Everything2 has them for a couple years now. That's SeeAlso, which 
is currently a patched BackLinks with some (slightly broken) filtering. 
Bit heavy (I've limited it to 20 links), might need to be cached. I've 
also modified the getPageLinks(?) functions to parse included pages and 
add them to the link list (that's the really heavy part).

>> http://mac.against.org/space/DotGraph
>
> Very nice most definately welcome.

Basically a VisualWiki that lets you write the GraphViz code inline. 
Has some problems with bad graphs (error messages don't print) and 
caching (caching is done in function of the plugin arguments, not an 
MD5 hash of anything between <?plugin <-> ?>, which is the proper way 
IMHO)

>> 1) CamelCase
>
> You can change the PCRE for WikiWords in index.php (currently there) 
> to something impossible so that nothing matches.

Yep, my point was more along the lines of contributing my users' 
feedback. I can't remember if I had to change anything to get the 
case-insensitive [link] matches, though (but then, it's getting late 
here).

>> 2) HTML (or simplified HTML) markup
>
> This has been a frequent request, but it is just a horrible idea.  The 
> point of the wiki syntax is to force standardization across the entire 
> wiki, and it prevents a page from rendering broken.  If you introduce 
> HTML everywhere then you end up with some very broken wikis.

Not if you parse/reparse it into XML. That would also allow for some 
preprocessing of IncludePages and similar plugins, leading to better 
performance ;)

>> 3) File attachments (and Wiki markup to refer to them)
>
> Aren't uploads already in 1.3.4?  Haven't paid much attention to that 
> side...

Yeah, but just uploading files to a directory (which seems to be the 
basic functionality currently in CVS AFAIK) doesn't cut it... Too many 
issues regarding filenames, collisions, access levels, etc.

>> 4) ACLs.
>
> We are already working on a Unix style User,Group,Other (rwx) 
> Permissions
>
> http://phpwiki.sourceforge.net/phpwiki/PagePermissions

Yep. I was just wondering if it was in the code somewhere. I started 
off from 1.3.2 stable, and pecking through CVS wasn't very 
enlightenting as to what the current state of affairs might be.

>> 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.
>
> Not sure what you mean here.  SubPages have been added...

Hmmm... this (http://snipsnap.org/comments/SnipSnap-war) is pretty much 
it. note the simple layout and emphasis on the comment author's name. 
SubPages sort of works, but feels a bit odd (I have plenty of naive 
users to show these things to, and usability-wise, SubPages is tricky 
to grasp). I might have a go at hacking a nice layout into it. :)

>> 6) XML.
>
> Not a very good idea.  If we store the WikiPages as XML, then we will 
> have to convert from XML to WikiSyntax for an edit.  Providing an XML 
> data port should be sufficient.  This can be looked at again (it has 
> been mentioned many times), but IMHO there are higher priorities.

Well, that's a matter of belief systems :)

I don't see any issues with converting/reconverting, provided the 
converter is lenient enough. I've been mostly concerned with the 
parsing and the built-in PHP/XML functions, but nothing usable has come 
out (yet - we use XML and SOAP extensively, so it's just a matter of 
time).

I'm also toying with the idea of using XML and XPath to build a fully 
XML-based Wiki (Cocoon springs to mind as a base), but I haven't had 
much time to investigate (nor does it make much sense with so many Wiki 
frameworks around).

>> 7) CVS - not as a backend, but as an integrated tool.
>
> We do offer integrated diffs and versioning, which can be in a real db 
> rather than the file structure (huge plus). So I am not sure of the 
> advantage.

No no no, not as versioning. :) A CVS backend to a Wiki is not to be 
underestimated, but that's not what I was getting at.

Picture this: You have a RecentChanges-like page that tracks CVS 
commits. Commit comments can (easily) contain WikiLinks, hence 
providing direct links to Wiki nodes. Instant progress tracking ;)

Check this out: http://cvs.cvstrac.org/timeline

>> The main PhpWiki has a rather sketchy feature roadmap.
>
> Yeah... some organization would be nice, but my priorities:
>
> 1) New configuration system
> 2) User Authentication system
> 3) Group Authentication system
> 4) PagePermissions
>
> jbw
>

Seems OK to me. But why Group Auth? PagePermissions would be the same 
issue, no? :)

Is there any info on the database schema changes for those?

R.