Merge branch 'master' of ssh://git.ikiwiki.info

master
Joey Hess 2011-11-30 12:15:39 -04:00
commit 2615b92fd4
11 changed files with 180 additions and 2 deletions

View File

@ -81,5 +81,13 @@ index 73689be..039b7e3 100644
-- fergus -- fergus
---
I've gone ahead and filed a bug on CGI.pm too: I've gone ahead and filed a bug on CGI.pm too:
<https://rt.cpan.org/Ticket/Display.html?id=72678> --[[Joey]] <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

View File

@ -0,0 +1,83 @@
[[!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>
"""]]

View File

@ -0,0 +1,12 @@
[[!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.
"""]]

View File

@ -0,0 +1,9 @@
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

View File

@ -0,0 +1,8 @@
[[!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
"""]]

View File

@ -0,0 +1,12 @@
[[!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.)
"""]]

View File

@ -0,0 +1,34 @@
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]]

View File

@ -2,6 +2,8 @@
Here's my next version of the patch - still a work in progress. 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. 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: * If you specify an event preprocessor in a post, such as:

View File

@ -7,3 +7,7 @@ the author. It would be especially handy if it was generated statically.
One way would be to generate internal pages corresponding to each comment One way would be to generate internal pages corresponding to each comment
that needs moderation; then the feed could be constructed via a usual that needs moderation; then the feed could be constructed via a usual
inline. inline.
----
See [[tips/comments feed]] --liw

View File

@ -0,0 +1 @@
http://hands.com/~phil

View File

@ -1,4 +1,7 @@
[[!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 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 team-documentation management system for a small-sized group of UNIX
sysadmins. sysadmins.
@ -54,7 +57,9 @@ Penultimately, the following are merely half-formed thoughts:
* I'd like to make profiling ikiwiki in action very easy for newcomers. * 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. Perhaps even a plugin that created a file /profile or similar on build.
## backlinks
Finally, backlinks (since I have issues with the current backlinks Finally, backlinks (since I have issues with the current backlinks
implementation, see [[bugs/backlinks onhover thing can go weird]]): implementation, see [[bugs/backlinks onhover thing can go weird]]):
[[!inline pages="link(users/Jon)" archive="yes" feeds="no"]] [[!map pages="link(users/Jon)"]]