> 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.
|
