1 I am serving notice that I am starting work on a calendar plugin inspired by Blosxom's calendar plugin. The current plan is to create a plugin that looks through all the source files matching a certain pagespec, and optionally spit out a month view for the specified month (default to current), or spit out a year view for a given year (defaulting to the current year), of a list of year with posts in them. The output would be a table, with the same CSS directives that the Blosxom plugin used to use (so that I can just reuse my css file). The links would be created to a $config{archivedir}/$year or $config{archivedir}/$year-$month file, which can just have
3 \[[!inline pages="blog/* and !*/Discussion and creation_year($year) and creation_month($month)" rss="no" atom="no" show="0"]]
5 or some thing to generate a archive of postings.
7 Roland Mas suggested a separate cron job to generate these archive indices automatically, but that is another thread.
11 This plugin is inspired by the calendar plugin for Blosxom, but derivesno code from it. This plugin is essentially a fancy front end to archives of previous pages, usually used for blogs. It can produce a calendar for a given month, or a list of months for a given year. To invoke the calendar, just use the preprocessor directive:
17 \[[!calendar type="month" pages="blog/* and !*/Discussion"]]
21 \[[!calendar type="year" year="2005" pages="blog/* and !*/Discussion"]]
24 The year and month entities in the out put have links to archive index pages, which are supposed to exist already. The idea is to create an archives hierarchy, rooted in the subdirectory specified in the site-wide customization variable, archivebase. archivebase defaults to "archives". Links are created to pages "$archivebase/$year" and "$archivebase/$year/$month". The idea is to create annual and monthly indices, for example, by using something like this sample from my archives/2006/01.mdwn
26 \[[!meta title="Archives for 2006/01"]]
27 \[[!inline rootpage="blog" atom="no" rss="no" show="0" pages="blog/* and !*/Discussion and creation_year(2006) and creation_month(01)" ]]
29 I'll send in the patch via email.
35 Since this is a little bit er, stalled, I'll post here the stuff Manoj
36 mailed me, and my response to it. --[[Joey]]
38 > > I'm sending in an updated package, and have removed the older version you had here.--ManojSrivastava
45 've been looking over the calendar plugin. Some items:
47 * Why did you need to use a two-stage generation with a format hook?
48 That approach should only be needed if adding something to a page that
49 would be removed by the htmlscrubber, and as far as I can tell, the
50 calendars don't involve anything that would be a problem. It seems
51 that emitting the whole calendar in the preprocess hook would simplify
52 things and you'd not need to save state about calendars.
54 > I am scared of the html scrubber, and have never turned it on,
55 > and did not look too deeply into what would be scrubbed out --ManojSrivastava
56 >> Unless you're using javascript, a few annoyances link <blink>, or inline
57 >> css, it's unlikly to object to any html you might write. The list of
58 >> allowed tags and attributes is easy to find near the top of the plugin.
60 > In case the option that gets the ctime of the pages from the
61 > SCM itself, %IkiWiki::pagectime is not populated that early,
62 > is it? So I waited until the last possible moment to look at
63 > the time information.
65 >> Actually, since my big rewrite of the rendering path a few months ago,
66 >> ikiwiki scans and populates almost all page information before starting
67 >> to render any page. This includes %pagectime, and even %links. So you
68 >> shouldn't need to worry about running it late.
70 * The way that it defaults to the current year and current month
71 is a little bit tricky, because of course the wiki might not get
72 updated in a particular time period, and even if it is updated, only
73 iff a page containing a calendar is rebuilt for some other reason will
74 the calendar get updated, and change what year or month it shows. This
75 is essentially the same problem described in
76 [[todo/tagging_with_a_publication_date]],
77 although I don't think it will affect the calendar plugin very badly.
78 Still, the docs probably need to be clear about this.
80 > I use it on the sidebar; and the blog pages are almost always
81 > rebuilt, which is where the calendar is looked at most often. Oh,
82 > and I also cheat, I have ikiwiki --setup foo as a @daily cronjob, so
83 > my wiki is always built daily from scratch.
85 > I think it should be mentioned, yes.
87 * There seems to be something a bit wrong with the year-to-year
88 navigation in the calendar, based on the example in your blog. If I'm
89 on the page for 2006, there's an arrow pointing left which takes me to
90 2005. If I'm on 2005, the arrow points left, but goes to 2006, not
93 > I need to look into this.
95 * AIUI, the archivebase setting makes a directory rooted at the top of
96 the wiki, so you can have only one set of archives per wiki, in
97 /archives/. It would be good if it were possible to have multiple
98 archived for different blogs in the same wiki at multiple locations.
99 Though since the archives contain calendars, the archive location
100 can't just be relative to the page with the calendar. But perhaps
101 archivebase could be a configurable parameter that can be specified in
102 the directive for the calendar? (It would be fine to keep the global
103 location as a default.)
105 > OK, this is simple enough to implement. I'll do that (well,
106 > perhaps not before Xmas, I have a family dinner to cook) and send in
111 And that's all I've heard so far. Hoping I didn't miss another patch?
115 >No, you did not. But I am back to hacking on this, and I think I have discovered a major problem with my approach. One of the problems with the current plugin is that the goal of a calendar is to create a calendar, either a month >or year based on, that provides links to blogs for all the days in (for the month calendar), and all the months (in a year calendar) in which there have been blog postings. For the monthly calendar, it needs to know the previous >and next months where there is a posting, and for the year calendar, it needs to know which of the previous (next) years had entries.
117 >Now, this means that it needs to know about at _all_ pages that meet the pagespec, and stash that information, before it begins generating the calandar in question, in order to calculate how to create the symlinks. And, of >course, all pages that have calendars on them might need to change anytime a page that meets the pagespec is added; and again at midnight, when the current day changes.
119 >> I think I have solved the ""Need to look at all pages that match the spec"" issue; but the nightly rebuild to handle the current day changing still remain. I use cron. It is now, however, richly documented :)
124 > Finally reviewed and applied this. [[done]]! --[[Joey]]
projects / ikiwiki / blob