[pmwiki-users] Meetup? Drupal?

[The Editor]

On 9/28/06, Crisses <crisses at kinhost.org> wrote:
> On Sep 28, 2006, at 9:08 AM, Stirling Westrup wrote:
>
> > Yesterday I was at a local club meeting and some folks were talking
> > about setting up a CMS to manage a website for the club. It would have
> > the usual features of news and articles, but they were also hoping to
> > use it to replace meetup.com which they are currently using to inform
> > folks of venue and time changes (of which there have been many).
> >
> > I'm not exactly sure how that would be done in PmWiki, but I suggested
> > that we use it anyway because
> >
> >   a) I like it, and
> >   b) I figured it couldn't be too hard.
> >
> > I'm thinking that a good solution would use something like FASTData so
> > that folks could register for the newsletter and/or meeting updates
> > (with double opt-in) and use PmCal or similar to display event
> > dates on
> > the site. Like meetup we'd also want user profiles and RSVP
> > feedback for
> > meeting attendance. There was also talk about using the site to
> > manage a
> > discussion list. Does anyone have any suggestions about best ways of
> > doing all this?
> >
> > Secondly, someone else suggested that we use Drupal instead, not
> > because
> > of any particular familiarity with it (as far as I could tell) but
> > because its well known and has a large user base. I've never used
> > it but
> > I've heard its hard to install and set-up and would like to hear the
> > opinions of anyone here who's used it. I'm not really interested in
> > trashing it, but I would like to have some (reasonably) objective pros
> > and cons to put forward before a decision is made.
> >
> > I've agreed to put together a simple demonstration site to show how it
> > might work under PmWiki and I'm interested in any advice folks have.
>
> My primary business is application installation, customization and
> configuration.
>
> I've looked at a bunch of CMS systems.  Weighed their pros & cons.
>
> I rejected Drupal because I wanted a business directory once and
> couldn't find a good module for it.  That really frustrated me.
>
> I rejected Joomla! (and hence Mambo) because, while their best
> business directory ($99) was ok they have a set number of user groups
> out of the box.  Extending to customizable user groups requires
> breaking the package and comes with NO guarantees that other modules
> (purchased or not) would continue to work after.  That went right
> into the trash.  If ANYONE wants a license for a Joomla business
> directory package I'd be glad to pass on the license at a
> considerable discount and recoup my loss, since I never used it....
>
> I then went to Xoops.  I like Xoops.  It's not as pretty out-of-the-
> box (Joomla is pretty!), but it's extensible, has multiple groups out-
> of-the-box, tons of plug-ins, and I feel like it's a true free-OSS
> package with the same type of giving community I experience with
> PmWiki.  Their package is built with a basic core and EVERY feature
> is a plug-in.  You opt to install the features you want.  All the
> plug-ins are independent.  You don't have to break the core package
> to add an extension (Joomla & oscommerce are guilty as charged!).
>
> I come back after that to PmWiki.  I love PmWiki and greatly look
> forward to the day I can give out PmWiki instead of even Xoops to
> paying clients, as a CMS, shopping cart, and otherwise.
>
> I think that FASTData is young, and in spite of how Caveman gushes
> about how easy it is you're looking at more work than you think to
> create the features you want at this particular moment.  I've been
> working on http://www.similepedia.com for weeks now -- far outside of
> my deadline -- because PmWiki is changing so rapidly right now and
> I'm waiting on upcoming features to finish the package for my client.
>
> However, you may want to fall back on the stable version of PmWiki
> and features that PmWiki does already have.  One forum package is
> broken in the latest releases, but if you fall back to the latest
> 2.1.x stable, you have forums there.  Other plug-ins you mentioned
> are stable.  If you feel confident about doing user logins with
> PmWiki, go for it, but if not I suggest hooking a tiny external
> newsletter package manager in with something that manages using the
> same data to log in with PmWiki.  Or have user logins separate from
> their newsletter subscriptions.  A package I evaluated that looks
> good for newsletter management is Koops mailing list -- looks clean,
> small, just does exactly what it needs to to manage a mailing list
> and opt-outs, and nothing more.  Simple to plug-in to a PmWiki
> template.  That's all you need.  Heck, I'll probably hook it in to my
> MySQL sign-on app (which works on the stable PmWiki) eventually so
> that the mailing list & opt out ties directly in with user account
> management.
>
> So, that's my professional recommendation(s) for you.  Check out
> Xoops if you're not using PmWiki.  If you go with PmWiki, build your
> PmWiki install around stable packages, and upgrade to something
> fancier and with more features when the dust settles and Caveman has
> time to put up some terrific code samples and document things better
> for those of us still scratching our heads.
>
> Crisses

Actually I'll throw in two cents on drupal myself.  I used it for
about 6 months before discovering PmWiki.  It is in my opinion the
best cms out there, very stable, runs smooth and fast, and has nice
features.  But I had problems with its installation, upgrades were a
nightmare, installing modules often required database manipulation,
and the whole database thing was a drag.  Mess up the database and
your site is in trouble.  (That was my problem).  Not being completely
ignorant, I found Drupal out of my technical range, though at first it
was nice getting started and very powerful--and I gave a good effort
at learning it.  It does have a big support community but maybe too
big.  No where's near as helpful or as responsive as PmWiki.  Sort of
get lost in the thousands...

When I switched to PmWiki and became database free it was incredible.
I was able to upload/download individual files.  Backups were a snap.
Upgrades a piece of cake.  It couldn't hardly be broken.  And it just
worked.  Everything was simple, easy to use, well designed, flexible,
and the support community was not too big, not too small--just right.
And VERY helpful.  I'm really thankful to all of you who add to the
community.

There were a few features I missed from drupal that there were not
modules for in PmWiki.  In particular in the area of CMS capabilities,
which is what I really wanted.  That was the whole impetus behind the
FAST Data recipe.  It wasn't really a plan to simply save and retrieve
data, it was to provide a framework that would easily reproduce all
the features not available in PmWiki that I did like in Drupal.  With
FAST Data (or other recipes), and the inherent flexibility in the
upcoming PmWiki, I can assure you personally Drupal is no comparison.
Not even close.  I have never once looked back.  PmWiki far exceeds
Drupal in every way.  Go with PmWiki.  It is much better!

As for FAST Data, it is still going under a lot of development and
polishing.  I will be uploading major new capabilities when I get back
that will dramatically increase its potential.  Namely full list/array
capabilities and full templating (even merging for creating new pages,
emails, and/or logs).  Even so, it is approaching a fairly settled
state--mostly because I have run out of features I can even think up
adding to it.  And as I learn more about php, I just find smarter and
more flexible to do things.  Give me one more week and the next
release should be it for now.  (Except bug fixes).

If it seems difficult to use, it is because you have to think about it
differently than most other recipes. It is almost like a
mini-scripting language, or an interface that directly connects a form
with php.  If you think of creating your form as you would a small
program, it will help you to understand it.  I deliberately tried to
make it as open-ended as possible, and not preset it for specific
applications.  That is the beauty of PmWiki.  I wanted FAST Data to be
the same.  If you can think of something you want to do with PmWiki,
there's probably a way to do it.  The same with FAST Data.  If you can
think of something you want to do with a form, it probably has the
functions you need. You just have to write out the form, like a little
mini script.

There are several examples up on the FAST Data demo site right now.
I've been waiting for the new pagelist code to do the Forum because it
will enhance what you can display.  But that will be up soon too.  I'm
hoping a few other developers will take an interest in FAST Data (wait
till the next release at least though) and use it begin developing
some new applications.  My guess is, a large percentage of the
existing recipes can be replicated in FAST Data. (I went through them
and simply analyzed the core functions needed and then added the
functions).  And because all the FAST Data functions are
interchangeable you have even maximum flexibility.

If the recipe needs to be tweaked to make it more flexible I'll do it.
 I want it to work for everyone.  If you need code for a specific
application, let me know and I can try to put together the form
markup.  Every feature in FAST Data can be activated by simple cut and
paste code.  No config changes.  No php or downloads.  Just cut and
paste.  So ask away and I'll do my best to provide a script.

Anyway, looking forward to working with other to improve FAST Data.
And don't go with Drupal.  PmWiki out does it in everyway!

Cheers,
Caveman