[pmwiki-users] 2.2 Series & Blog/comments
crisses at kinhost.org
Sat Sep 23 06:31:20 CDT 2006
On Sep 22, 2006, at 12:01 PM, Ben Wilson wrote:
> What other features are inherent in a blog nowdays? Tags? Calendars?
> Archive pages? Comments? Tags are just categories. Calendars can be
> coded without the core. Archive pages can also be made a recipe.
> Comments can be seen below.
If pagelists have the ability to group pages by ctime and return a
date() format list, that would resolve the "Archives" problem and may
even be helpful for the PmWiki Magazine and I could see it being used
on normal Wikis as well. So yes, adding in a call for ctime, making
it pagelist compatible, etc. would be very very helpful, and may
warrant being part of the core PmWiki so that all types of recipes
and sites could make use of them.
I'm falling in love with tag clouds -- it's such a refreshingly
simple way to visualize the bulk/ratio of a site's (or blogs,
whatever) posts. I think there's a recipe for that already.
> Without confering with him, I infer that Pm is suggesting adding
> Blogging to the core because of the interest in the threads and lack
> of consensus/uniformity in the recipes. Perhaps the blog authors
> should get together and work with Pm to unify the approach so that
> PmWiki can offer one-solid blog approach, rather than several.
I'm all for simplifying what's going on. One reason I made a new
version of AuthUserDataBase built on the original is so it's clearer
when someone needs one vs the other. If you want to use your Moodle
database to authenticate PmWiki users, you want the original recipe.
If you want PmWiki to use a database all by itself, and not to force
the site admin to become the wiki registration housekeeper manually
entering usernames & encoding passwords to a MySQL database, you want
my recipe. I didn't reinvent the wheel. I took something good and
made it different (not better!). Next someone can take my recipe and
apply my logic to the .htpasswd method of authentication so that
users can add/change passwording via .htpasswd :) -- it might be
easier now that you can store interim info (validation codes & email
addresses, etc.) using FASTData.
> Comments are not incongruent with wikis. If you look at the "original
> wiki," the pages are used in part as threaded discussions, with
> refactoring. So, to add a comments ability to the core is not too far
> off base. However, I think it would be preferable to retain this as a
> recipe. As there are several recipes, perhaps Pm should work with the
> recipe authors to refine the comments system as he is proposing to do
> with the core. Then, rather than adding it to the core, it is made
> available as a recipe.
I personally think it is comments != wiki as well. I give out wikis
as mini content management systems for brochure websites, and use it
that way myself on several sites. While it might do me much good if
I allow my customers & potential clients to comment on my web pages
("Criss! You're babbling! Get to the point!" heh), it's not
something I expect to see on what is traditionally a static page.
Wikis are for collaborative authoring of what appears to be a static
page to the reader (cf the myriad program documentation sites that
use wikis and developer/groupie/evangelist collaboration to write the
documentation). We have talk/discussion pages for authors to discuss
a collaborative page - - this IS a wiki-ful purpose. But website
guestbooks &/or comments on blog entries would fit the category of
not central to the idea of a wiki. I would move a Talk/Discussion
tab into the central distro sooner than visitor comments. I would
make a quick admin switch for generating nofollow links to the
discussion/talk page, as you may not want those to be landing pages
from a search engine -- that's the messy not-for-direct-public-
consumption place where authors wrangle about content.
> IMO, the core should offer hooks that make it easier to make good
> recipes. So far, the core has that. However, blogging and comments can
> be effectively done without adding the specific behavior in the core.
Except as I noted above where it would be helpful if pagelists could
more easily tag/sort pages by creation date/time. That's a core
function issue that PM already has responded to in another thread.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pmwiki-users