[pmwiki-devel] database tools and hacks in PmWiki
crisses at kinhost.org
Sun Dec 10 07:26:46 CST 2006
On Dec 10, 2006, at 1:34 AM, Ben Wilson wrote:
> I believe Crisses (Xes) is working on a database library for PmWiki
> based in ADODB as well. I You may wish to work with her to combine
> effort. I regret I've been sort of out of the loop since about
> October, so I'm not sure of her level of effort or production.
> However, it appears I'm coming back in the loop; sort of.
I'm not working on a database library -- not that I know of. I was
going to work on a generic script for database recipes to use -- you
got to it before me, and I was very happy. I have at least 12+
PmWiki projects upcoming.
Some items on my list may never happen, if the paid projects behind
them don't go live. Some are pet projects - no one has approached me
to do them, I just WANT to do them. Many may use ZAP for part or all
of the features.
* distance by zip code calculator - not a Google map api -- client
wants to NOT give away location under certain circumstances, just
entice paying subscribers by saying how many listings there are on
the site, and how far away they are.
* improved events calendar - perhaps integrating the iCalendar
format (iCalendar portion is pet project, the rest is client proposal)
* paid (PayPal) subscriptions tied into the AuthUserDBase
authentication -> changes what group people are under, which changes
their privileges on the site.
* change page ratings recipe to include aye/nay/abstain for
official group proposals, maybe add multiple "vote" ability per page?
* shopping cart system (and some shipping/payment modules) - this
is the farthest out because it's most complex (pet project).
* obscured downloads -> so people may buy items, or download
documents without being able to give out their URL location (pet
* expiration for pages -> some way for pages or data stored on
pages to "expire" either by moving to a restricted group or using the
PmWiki delete command on a certain date
* email-to-wiki (discussed previously on list - pet project)
* expand the business directory I created yesterday - need to add
categories, a way to bump certain listings to the top of the list,
and so on -- may use the vCard format
* classified ads (one place the page/data expirations comes in)
* method of easy moderator approval for pages/listings/data, etc.
(a link or button on the page that changes the read password? I
don't care, it just has to be quick & easy -- not adding ?action=attr
to the toolbar and changing something to "@nopass" -- think "I don't
have time for this" or "That's too much to remember") Also needs to
come with a method of listing items that need to be approved, of course!
* private messaging - would act a bit like webmail
* newsletter subscription double-opt-in manager (may tie in koops
mailing list, change it to use flat-files?)
I'll go update my profile page -- I have been keeping an "upcoming"
list there if anyone is interested in how busy I am or wants to
volunteer to do something on my list, help with something, or offer a
bounty so that I work on something NOW instead of whenever.
So, on the "database library" that you thought I was building: I
will be working on a couple add-ins for AuthUserDBase (admin panel &
group management too!). I think keeping users' private information in
a database is pretty important, but I LOVE the PmWiki flat-file
system for many reasons. So I will be sticking with flat-file as
much as I can in my recipes, even though I look forward to seeing
other people's wonderful database recipes.
I have thought through the product/service end of the shopping cart,
but not the order storage end. Storing credit card/bank information
in flat files is absolutely out of the question for me, one reason I
love PayPal from a liability/programming point of view -- absolutely
no need to store financial information on the system. The moment the
shopping cart system requires working with other merchant processing
systems that require the shopping cart to handle sensitive financial
information, we're entering very mucky territory in the way PmWiki
handles data. You must store the customer's credit card in case of a
product return, or needing to issue a credit, etc. But you can't
store it in a text file. You can't one-way encrypt it. Do we use
GPG? That doesn't work, because the web server would need access to
the keys. It's a pain, and so far a database is the best answer I
have. I personally prefer to stick with a service like PayPal
because I don't want the liability.
I hope that helps people understand exactly where I'm at, and what
I'm doing with my PmWiki-time. You're not stepping on my toes if you
work on *anything* currently available in PmWiki. Just let me know
if it might break AuthUserDBase :) If you update the
DatabaseStandard or AuthUserDBase pages/scripts, I'll be notified by
email, so go for it. I will be grateful!
More information about the pmwiki-devel