[pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

[Vince Administration]

Dear Editor,
It might be good to know just what "support" is available for ZAP.
For example: If changes are required to ZAP to have it continue to  
work with later versions of PmWiki or php,  will someone do this?

        Vince


On Jul 10, 2008, at 6:59 PM, The Editor wrote:

> On Thu, Jul 10, 2008 at 5:26 PM, Eemeli Aro <eemeli at gmail.com> wrote:
>> 2008/7/10 The Editor <editor at fast.st>:
>>> Though I'm no longer actively supporting ZAP, it's been able to do
>>> this and much more for a long time.
>>
>> I actually did take a look at ZAP and the MemberMgmt recipe before
>> starting, but it's that "and much more" part that turned me away. By
>> now, I know how PmWiki works; I've read through the code enough times
>> to trust what it's doing. Admittedly Pm's code could do with more
>> documentation aimed at developers and longer variable names, but it
>> does all work and lets me pick which parts to enable or disable.
>
> Just thought it might be helpful to have something that is already set
> up for what you are doing. But then again, support these days for ZAP
> is pretty limited.
>
>> ZAP, on the other hand, is a single monolithic recipe that proudly
>> lists 30 different things that it does. The effort I'd need to put
>> into understanding all of it exceeds the effort I'm putting into
>> writing what I need myself. Since we're dealing with account
>> management I figure I need to be extra careful with what I do.
>> Essentially, I don't think I need generic form processing with extra
>> features to enable account administration.
>
> Actually, ZAP is a pretty simple platform, with a bunch of extension.
> The core engine is lean (under 400 lines).  And the toolbox is just a
> collection of standalone modules. And everywhere possible, ZAP taps
> directly into core PmWiki features (from security to page creation to
> whatever, so it works closely with PmWiki). What I've suggested to
> others (for better performance and security both), is to just delete
> or comment out any functions you don't use from the toolbox. If all
> you want is member mgmt features--that means you'ld only need another
> 30 or 40 lines more. Hardly monolithic.
>
>> Additionally, there are quite a few things that I need that I haven't
>> seen ready solutions for. For example, I want to have
>> <example.com/wiki/SomeUser> resolve to a default profile page for
>> SomeUser that reads a template from somewhere and SomeUser's data  
>> from
>> elsewhere. The tricky part (or at least one of them) is the lack of
>> any default group for these profile pages.
>
> If you could get by with example.com/wiki/Login/SomeUser you could do
> this today in ZAP. I just put a template in the header of the Login
> group and populate it with data saved from their registration form.
> You can even have a form that allows members to edit their profile
> data. As in a button at the bottom if the page name matches their
> member id.  I don't know there is a ready made snippet (probably is),
> but this is the precise purpose ZAP was created for. And I do it all
> the time in BoltWire.
>
> If you can't have the group name (login), surely a line or two in a
> config file could be used to check the page name, and if it matches
> some pattern you simply redirect to the desired page. But using
> Login/SomeUser means you can put a link like [[login.{member}|View
> Profile]] on a page, or the usual ~~.
>
>> Another odd feature that I want is controlled, undoable deletion of
>> other people's user accounts by non-administrators. Most of my sites
>> are internal, and what with the restructuring and changing  
>> secretaries
>> and other things, it's not always clear if someone's still an  
>> employee
>> or not. And since keeping track of people really isn't my job, I
>> figure I ought to make it possible for anyone to update these  
>> details.
>
> This should be a snap in ZAP. Because their login information is
> embedded in their in-wiki login page,anyone with permission can simply
> delete a login page and the password and all data vanishes instantly.
> Plus you don't have to give them access to any critical site pages or
> config files or the like. And if a page were accidently deleted, you
> could always retrieve it like any other deleted PmWiki page as an
> admin.
>
> Anyway, feel free to pursue other options. I'm not pushing ZAP or
> offering to help.
>
> Cheers,
> Dan
>
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>