Re: [Phpwiki-talk] Something very weird has happened to my Wiki

[Adam S. <ad...@pe...>]

> Well, if we're talking release in weeks, I don't expect really much new
> functionality in this area at all.  It will just work more smoothly (on
> all platforms).

i have mixed feelings.  on the one hand i'd like to see a stable release
that i can plan on using for a while, on the other i'm excited and don't
want to slow down progress!

more then anything else i was just wanting to get a feel for what
you/steve/etc were thinking so i could plan accordingly :-)
 
> (On the other hand, if all you want is multiple admin users (with
> hardcoded passwords, like the current admin user) that's an easy hack in
> any of the current PhpWiki version --- just use a hash to store
> 'admin-user' -> 'password' associations, and hack the password checking
> code accordingly.) 

hrm, that's true (and mostly what i want is multiple admins and the
death of shared passwords for them).  are then any issues with an admin
being a wikiname (eg. AdamShand) and will that work via the SignIn
mechanism etc?

> I think it would be great if you continue your work.  Just create a class
> with a good clean API which is reponsible for the actual storage/access
> of the uploaded files --- then when we want to implement a better storage
> system, we just have to drop in the replacement.

we'll i'll do my best.  this is more a learning php experiment for me
then anything else, but it seems fairly simple to do/implement so i'm
giving it a shot.
 
> I sort of started to doodle out a FileCache class to do this.  It's far
> from complete (don't take it too seriously), but I'll attache it to this
> message so you can see what I'm thinking...

i'll check it out, thanks.

> This is easy.  But we need to fix the raw-html syntax (leading '|') since
> it conflicts with the current table syntax.  Maybe <rawhtml></rawhtml> or
> somthing?  It could also maybe be done via plugin, which would keep the
> code completely out of the rest of stock PhpWiki.  Something like:
> 
>  <?plugin RawHTML -- <table><tr>...</tr></table> ?>

hrm, i hadn't really thought about that.  my assumption was that with
the talk of allowing things like <br> and <i> on all pages we could just
make the allowed html syntax broader on locked pages (eg. <table>,
<form> etc).

where would you put the logic for making sure it was a locked page.  it
seems fairly trivial to put it in the plugin (just a check for if the
page is locked otherwise exit with "Sorry, RawHTML not suppported on
unlocked pages) but somehow that doesn't seem right.

adam.