[pmwiki-users] Blog proposal

Hans design at softflow.co.uk
Wed Jan 11 13:14:11 CST 2006


Wednesday, January 11, 2006, 5:11:17 PM, Patrick wrote:

> I never intended that blog entries could only exist on one trail page.
> I've always been of the opinion that pages can exist on multiple
> trails.  Even though it wasn't explicitly mentioned in my proposal,

I am glad I just misunderstood your intentions.

> ...  And the admin could set

>     $BlogTrailFmt = array('{$Group}.BlogTrail', 'BlogArchive.2005-03', ...);

> to have "(:blog:)" automatically populate to several pages.

It would be good if it is possible to have
    'BlogArchive.{$CurrentMonth}' in the array, so the blog page gets
    added to the current monthly archive. But I think this is very
    easy to achieve.

But it leads to the interesting question of having a series of special
purpose blog page variables defined.

for my blog setup I defined so far:

  {$Today} - returns today's date in form of yyyy-mm-dd, used as a name
                prefix in the newpagebox
  {$BlogTitle} - returns the name of a page without any leading date prefix,
                 if it has a name part at all.
  {$BlogDate} - returns the page creation date in a friendly format
                (I use dd mmm yyyy European fashion)
  {$LastModifiedDate} - returns the date of last modified time without
                        the hour and minutes part, in a friendly
                        format for sidebar lists of recent comments
  {$BlogMonth} - returns month and year in long format from a page
                 name using yyyy-mm format (used for monthly archive
                 pages)
      and i am playing right now with
  {$Revisions} - returns the page rev number, to be used as a crude
            counter for the number of comments posted to the comments page

> But the idea of making it easier to create trails has lots of
> merit.  But I'm wondering if this means that the generic form of
> trails becomes the new way to handle categories as well -- i.e.,
> a page with category markup automatically adds itself to the
> corresponding category trail.

Yes I would have thought so.

> I'm not a great fan of trying to have trail pages specify their
> own format -- that becomes a real pain to manage, especially as
> they're being created automatically.  Better is to have the
> trail page simply contain a bullet list of pages, and then use
> (:pagelist:) to specify alternate formatting options.

This is a good approach and better than the one I was thinking of.
We can have admin or system defined defaults if needed of various
formats, like the $RecentChangesFmt. And we can build special
formatted pages with pagelist using pagelist templates. We can do that
already now, like an alternative formatted RecentPage2 page

> We might also come up with a (:traillist:) version of pagelist
> that reads (and removes) a trail from the current page and replaces
> it with the formatted version of that trail.  Thus the trail can
> continue to be a simple bullet list, but can be formatted on display
> using any pagelist format.

This may be a little hard to maintain and unpredictable in output.
To keep an auto-trail page of a simple list and a separate page for
formatted output using pagelist is simpler and more robust I guess.

This also solves a problem with an auto-generated trail page like
RecentChanges, which is the difficulty in changing the format of the
page later on. Having a raw list of page links on one page and a
formatted list generated through pagelist one can easily change the
format and indeed the info supplied in the list, using various page
variables, and one can hand-edit the raw list to remove unwanted
intrusions etc. So it combines both benefits of a trail page and of
a pagelist using templates for formatting.

And I suppose a pagelist generated from a trailpage should be quick
and easy on the system.

Best, 
~Hans                           






More information about the pmwiki-users mailing list