-- fergus
+---
+
I've gone ahead and filed a bug on CGI.pm too:
<https://rt.cpan.org/Ticket/Display.html?id=72678> --[[Joey]]
+
+---
+
+That'll be an interesting discussion as I'd suggest that HTTP_ headers are defined in the CGI specification as client headers and thus what `thttpd` is doing is wrong (i.e. mangling the client's own representation). Whether a CGI client should trust HTTP_ header over the server is probably already settled by convention.
+
+-- fergus
--- /dev/null
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 1"
+ date="2011-11-29T00:52:49Z"
+ content="""
+So I ported the original patch mentioned to the latest Debian version. Well at least the bits that matter to me. See below.
+
+In doing so I realized that it does quite work how I imagined it would; instead of generating a dynamic page for a particular day with a list of links it actually fills in the calendar with the details of the posts (making for some ugly formatting).
+
+I'm hoping the tag generation pages will give me a clue how to alter this into what I want.
+
+<pre>
+diff --git a/IkiWiki/Plugin/calendar.pm b/IkiWiki/Plugin/calendar.pm
+index c7d2b7c..c931fe6 100644
+--- a/IkiWiki/Plugin/calendar.pm
++++ b/IkiWiki/Plugin/calendar.pm
+@@ -75,6 +75,8 @@ sub format_month (@) {
+ my %params=@_;
+
+ my %linkcache;
++ my @list;
++ my $detail = 1;
+ foreach my $p (pagespec_match_list($params{page},
+ \"creation_year($params{year}) and creation_month($params{month}) and ($params{pages})\",
+ # add presence dependencies to update
+@@ -88,7 +90,7 @@ sub format_month (@) {
+ my $mtag = sprintf(\"%02d\", $month);
+
+ # Only one posting per day is being linked to.
+- $linkcache{\"$year/$mtag/$mday\"} = $p;
++ $linkcache{\"$year/$mtag/$mday\"}{$p} = $IkiWiki::pagesources{$p};
+ }
+
+ my $pmonth = $params{month} - 1;
+@@ -219,14 +221,38 @@ EOF
+ $tag='month-calendar-day-this-day';
+ }
+ else {
+- $tag='month-calendar-day-link';
++ if ( $detail == 0 ) {
++ $tag='month-calendar-day-link';
++ }
++ else{
++ $tag='month-calendar-day';
++ }
+ }
+ $calendar.=qq{\t\t<td class=\"$tag $downame{$wday}\">};
+- $calendar.=htmllink($params{page}, $params{destpage},
+- $linkcache{$key},
+- noimageinline => 1,
+- linktext => $day,
+- title => pagetitle(IkiWiki::basename($linkcache{$key})));
++ if ( $detail == 0 ) {
++ $calendar.=htmllink($params{page}, $params{destpage},
++ $linkcache{$key},
++ noimageinline => 1,
++ linktext => $day,
++ title => pagetitle(IkiWiki::basename($linkcache{$key})));
++ }
++ else {
++ my $day_label = qq{<span class=\"month-calendar-day-label\">$day</span>};
++ $calendar.=qq{$day_label\n};
++ my $srcpage; my $destpage;
++ while(($srcpage,$destpage) = each(%{$linkcache{$key}})) {
++ my $title = IkiWiki::basename(pagename($srcpage));
++ if (exists $pagestate{$srcpage}{meta}{title} ) {
++ $title = $pagestate{$srcpage}{meta}{title};
++ }
++ $calendar.=qq{\t\t<div class=\"$tag $downame{$wday}\">};
++ $calendar.=htmllink($params{page}, $params{destpage},
++ pagename($destpage),
++ linktext => $title);
++ push @list, pagename($linkcache{$key}{$srcpage});
++ $calendar.=qq{\t\t</div>};
++ }
++ }
+ $calendar.=qq{</td>\n};
+ }
+ else {
+
+</pre>
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"
+ nickname="Matt"
+ subject="comment 2"
+ date="2011-11-29T01:30:09Z"
+ content="""
+To revert the changes made above it is necessary not only to switch the detail level back down but to also regenerate the side-bar index.html file
+
+ ikiwiki --setup blog.setup
+
+should do it.
+"""]]
--- /dev/null
+Hi,
+I'm planning on abusing ikiwiki as a mini-CMS for a static website and think it's exactly the right system for it. Great stuff btw.
+
+But I still got a problem that I can't solve at the moment. For the static website (with commenting enabled tho) I want no one else to edit the pages, i.e. I want to turn off the editing function for everyone except me.
+
+That works with the lockedit plugin so far, and I can also hide the edit and preferences links on the pages. But if someone manually enters the link to the edit page he/she can still create an account (I have disabled openid and plan to use passwordauth only). The account can then not be used to edit pages but still, everyone can create accounts in userdb over and over. Is there a way to solve that? I just don't see it right now.
+
+Best regards,
+Chris
--- /dev/null
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnam4a8RtFwaWkKOX2BkA5I7cpGHcFw8E0"
+ nickname="Christian"
+ subject="comment on my own question"
+ date="2011-11-30T15:15:21Z"
+ content="""
+REALLY great was what I wanted to say - all the essentials are there, including commenting and search function. What else can you want <3
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://smcv.pseudorandom.co.uk/"
+ nickname="smcv"
+ subject="comment 2"
+ date="2011-11-30T16:09:16Z"
+ content="""
+Not currently possible, but you can configure [[plugins/passwordauth]] to
+ require an `account_creation_password`, and not tell anyone else what
+it is; or you could use [[plugins/httpauth]] for authenticated editing.
+(My mostly-static ikiwiki sites only allow [[plugins/httpauth]] over
+HTTPS.)
+"""]]
--- /dev/null
+I've set up a couple of sites where the users use ikiwiki in fairly standard mode as a CMS and I then set up another ikiwiki setup file that's got the edit options turned off, but is pointing at the same git repository in the background. I then make the post-update hook for each be <tt>post-update-hook.ikiwiki</tt> and <tt>post-update-hook.ikiwiki-public</tt> and have the <tt>post-update</tt> hook itself be a script like:
+
+ #!/bin/sh
+
+ $0.ikiwiki "$@"
+ $0.ikiwiki-public "$@"
+
+obviously this results in duplication of most of the <tt>ikiwiki.setup</tt>, a spare working directory that (perhaps) isn't needed, and an extra post-update hook plus wrapper script that is really needless extra complication.
+
+If instead there was a way of specifying additional destdir's, or perhaps more generally a way of specifying that there should be multiple passes through the build process using alternative values for some of the variables, then one could have both the private wiki view, and the public static view generated with minimal additional configuration.
+
+One idea that occurs to me is an <tt>additional_configs</tt> list where one would specify files containing just the settings you want to override compared with the main setup file.
+
+Alternatively, one might invent a new way of specifying alternative settings. i.e.:
+
+ additionalsites:
+ - public
+
+ destdir: /home/wiki/wiki-view
+ destdir[public]: /home/wiki/public_html
+
+ disable_plugins: []
+ disable_plugins[public]:
+ - recentchanges
+ - editpage
+
+ url: https://example.com/editors/
+ url[public]: http://www.example.com/
+
+ ...
+
+where the existance of the <tt>additionalsites</tt> list provokes additional runs through using the settings with matching extra bits to be used to override the defaults found in the rest of the file.
+
+Just brainstorming a bit after [[liw]]'s comment about this being useful on IRC, and thought I'd write the idea up while I was thinking about it. -[[fil]]
Here's my next version of the patch - still a work in progress.
+ Note:I partially updated part of this patch to work on Ikiwiki v3 - see [here](http://ikiwiki.info/forum/Calendar:_listing_multiple_entries_per_day/) -- Matt Ford
+
It provides the following new features. The features are designed to preserve the behavior of the existing plugin by default.
* If you specify an event preprocessor in a post, such as:
One way would be to generate internal pages corresponding to each comment
that needs moderation; then the feed could be constructed via a usual
inline.
+
+----
+
+See [[tips/comments feed]] --liw
--- /dev/null
+http://hands.com/~phil
-[[!meta title="Jon Dowland"]]
+[[!meta title="Jon Dowland"]][[!toc levels=2]]
+
+## intro
+
I'm looking at ikiwiki both for my personal site but also as a
team-documentation management system for a small-sized group of UNIX
sysadmins.
* I'd like to make profiling ikiwiki in action very easy for newcomers.
Perhaps even a plugin that created a file /profile or similar on build.
+## backlinks
+
Finally, backlinks (since I have issues with the current backlinks
implementation, see [[bugs/backlinks onhover thing can go weird]]):
-[[!inline pages="link(users/Jon)" archive="yes" feeds="no"]]
+[[!map pages="link(users/Jon)"]]
projects / ikiwiki.git / commitdiff