[pmwiki-users] Blog proposal
dausha at gmail.com
Wed Jan 11 06:38:03 CST 2006
I've not had a good chance to look at this yet (work being what it
is). Would you say the documentation on your site and in this email
are a complete, effective way to blog using PmWiki? Given a choice, I
would rather this be a recipe than a part of the Core as I gather Pm
had suggested. I'm sort of writing half-cocked as I have to finish
getting a site together before anybody else gets in.
> Message: 10
> Date: Wed, 11 Jan 2006 11:20:33 +0000
> From: Hans <design at softflow.co.uk>
> Subject: Re: [pmwiki-users] Blog proposal
> To: Pmwiki-users at pmichaud.com
> Message-ID: <74521017.20060111112033 at flutesong.fsnet.co.uk>
> Content-Type: text/plain; charset=ISO-8859-15
> some more feedback to Pm's blog proposal, archived here:
> I explored a bit more in detail how a blog can be constructed in
> pmwiki with the tools we got now, especially combining use of
> the power of page variables and pagelists. Results you can see here on
> my site: http://softflow.co.uk/design/Blog/Blog
> This features several lists, for recent posts, blog categories and
> monthly archives, as I've seen on blog sites. It also allows comments,
> which are stored on separate pages but included in the blog pages.
> Plus the blog pages names can carry a date as part of their
> names, created semi-automatically using newpageboxplus.
> Now reflecting on Pm's proposal and my attempts:
> > * A blog is simply a WikiTrail, along with some special markups
> > to post, organize, and display blog entries.
> To me there is a lot more to it. A blog contains usually a number of
> lists, not just one blog trail page. Each new blog page should be able
> to be added as link to several trail pages. - In addition setting up a
> wiki blog needs to be highly customisable. I would be most happy if
> pmwiki supplies the basic tools for this, but leaves the
> implementation to skin designers who can integrate blogging function
> with good layout design, and may allow for easy user customisations.
> - But back to the trail pages:
> What we need is a general method to allow a page to add itself as a
> link in a specified format to a number of trail pages. It should not
> be limited to one blogtrail page. For instance in my blog setup each
> blog page is listed on
> 1. Recent Posts
> 2. Categories, i.e a blog category page, if the blog page carries one
> (or more)
> 3. Archive of the month (or some other time-interval specific page)
> I used pagelist markup for each of these, but it would be much better
> if each list is populated over time when new pages are created, to
> serve as wiki trail pages. Then blog pages can carry trail markup to
> link from one to the next. So we can have a trail wandering through
> recent posts, a trail through a past month (archive), a trail through
> a blog category. The only existing mechanism to do something similar
> is used for RecentChanges pages. Recent Changes is populated over time
> with every page change. $RecentChangesFmt allows to output each page
> addition in a certain format.
> It would be nifty if the method used for creating Recent Changes pages
> would become a specific case in a more general method of automatic
> addition to certain trail pages on demand. I will call these
> auto-trail pages. ? Questions arising:
> 1. How would it be determined to what auto-trail page a page-link gets
> 2. Can a page-link be added to a specific location on the trail page,
> at a specific marker?
> 3. Can the trail page determine the format of each page-link addition
> to its growing list?
> My comments to these:
> 1. An array for auto-populating trail pages and their rule-to-add
> attributes would be nice. A page-link will be added according to
> * a general rule to add it (like Recent Changes for all pages)
> * a specific rule to add it if it matches a pattern (is part of a
> group, for instance)
> * a specific markup in the page to instruct addition to a specific
> auto-trail page (like Pm? suggestion to use a (:blog:) markup to add
> the page to a blog trail)
> * An attribute to add it according to time: at creation time or when
> the page gets modified.
> 2. The auto-trail page can carry a markup which specifies the position
> of page additions, i.e. the top of the list it creates
> 3. This markup can include any formatting instructions, ideally
> somehow similar to pagelist using templates for formatting.
> Any comments?
> Best regards,
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> End of pmwiki-users Digest, Vol 7, Issue 28
" Mundus vult decipi, ergo decipiatur"
More information about the pmwiki-users