return (srcfile_stat(@_))[0];
}
-sub add_underlay ($) {
+sub add_literal_underlay ($) {
my $dir=shift;
- if ($dir !~ /^\//) {
- $dir="$config{underlaydirbase}/$dir";
- }
-
if (! grep { $_ eq $dir } @{$config{underlaydirs}}) {
unshift @{$config{underlaydirs}}, $dir;
}
+}
+
+sub add_underlay ($) {
+ my $dir = shift;
+
+ if ($dir !~ /^\//) {
+ $dir="$config{underlaydirbase}/$dir";
+ }
+ add_literal_underlay($dir);
+ # why does it return 1? we just don't know
return 1;
}
$config{aggregateinternal} = 0;
my $oldname = "$config{srcdir}/".htmlfn($data->{page});
+ if (! -e $oldname) {
+ $oldname = $IkiWiki::Plugin::transient::transientdir."/".htmlfn($data->{page});
+ }
+
my $oldoutput = $config{destdir}."/".IkiWiki::htmlpage($data->{page});
$config{aggregateinternal} = 1;
- my $newname = "$config{srcdir}/".htmlfn($data->{page});
+ my $newname = $IkiWiki::Plugin::transient::transientdir."/".htmlfn($data->{page});
debug "moving $oldname -> $newname";
if (-e $newname) {
foreach my $guid (values %guids) {
# any guid whose feed is gone should be removed
if (! exists $feeds{$guid->{feed}}) {
- unlink "$config{srcdir}/".htmlfn($guid->{page})
- if exists $guid->{page};
+ if (exists $guid->{page}) {
+ unlink $IkiWiki::Plugin::transient::transientdir."/".htmlfn($guid->{page})
+ || unlink "$config{srcdir}/".htmlfn($guid->{page});
+ }
delete $guids{$guid->{guid}};
}
# handle expired guids
elsif ($guid->{expired} && exists $guid->{page}) {
unlink "$config{srcdir}/".htmlfn($guid->{page});
+ unlink $IkiWiki::Plugin::transient::transientdir."/".htmlfn($guid->{page});
delete $guid->{page};
delete $guid->{md5};
}
}
my $c="";
while (exists $IkiWiki::pagecase{lc $page.$c} ||
+ -e $IkiWiki::Plugin::transient::transientdir."/".htmlfn($page.$c) ||
-e "$config{srcdir}/".htmlfn($page.$c)) {
$c++
}
$c="";
$page=$feed->{dir}."/item";
while (exists $IkiWiki::pagecase{lc $page.$c} ||
+ -e $IkiWiki::Plugin::transient::transientdir."/".htmlfn($page.$c) ||
+
-e "$config{srcdir}/".htmlfn($page.$c)) {
$c++
}
if (ref $feed->{tags}) {
$template->param(tags => [map { tag => $_ }, @{$feed->{tags}}]);
}
- writefile(htmlfn($guid->{page}), $config{srcdir},
- $template->output);
+ writefile(htmlfn($guid->{page}),
+ $IkiWiki::Plugin::transient::transientdir, $template->output);
if (defined $mtime && $mtime <= time) {
# Set the mtime, this lets the build process get the right
# creation time on record for the new page.
- utime $mtime, $mtime, "$config{srcdir}/".htmlfn($guid->{page});
+ utime $mtime, $mtime,
+ $IkiWiki::Plugin::transient::transientdir."/".htmlfn($guid->{page});
# Store it in pagectime for expiry code to use also.
$IkiWiki::pagectime{$guid->{page}}=$mtime
unless exists $IkiWiki::pagectime{$guid->{page}};
my %params=@_;
my $session=$params{session};
- if (exists $config{blogspam_pagespec}) {
- return undef
- if ! pagespec_match($params{page}, $config{blogspam_pagespec},
- location => $params{page});
+ my $spec='!admin()';
+ if (exists $config{blogspam_pagespec} &&
+ length $config{blogspam_pagespec}) {
+ $spec.=" and (".$config{blogspam_pagespec}.")";
}
+ my $user=$session->param("name");
+ return undef unless pagespec_match($params{page}, $spec,
+ (defined $user ? (user => $user) : ()),
+ (defined $session->remote_addr() ? (ip => $session->remote_addr()) : ()),
+ location => $params{page});
+
my $url=$defaulturl;
$url = $config{blogspam_server} if exists $config{blogspam_server};
# The untaint is OK (as in editpage) because we're about to pass
# it to file_pruned and wiki_file_regexp anyway.
- my $page = $form->field('page')=~/$config{wiki_file_regexp}/;
+ my ($page) = $form->field('page')=~/$config{wiki_file_regexp}/;
$page = IkiWiki::possibly_foolish_untaint($page);
if (! defined $page || ! length $page ||
IkiWiki::file_pruned($page)) {
# This untaint is safe because we check file_pruned and
# wiki_file_regexp.
my ($page)=$form->field('page')=~/$config{wiki_file_regexp}/;
- if (! defined $page || ! length $page ||
- file_pruned($page)) {
+ if (! defined $page) {
error(gettext("bad page name"));
}
$page=possibly_foolish_untaint($page);
my $absolute=($page =~ s#^/+##); # absolute name used to force location
+ if (! defined $page || ! length $page ||
+ file_pruned($page)) {
+ error(gettext("bad page name"));
+ }
my $baseurl = urlto($page);
# favor the type of linking page
$type=pagetype($pagesources{$from});
}
- $type=$config{default_pageext} unless defined $type;
+ $type=$config{default_pageext}
+ if ! defined $type || $type=~/^_/; # not internal type
$file=newpagefile($page, $type);
if (! $form->submitted) {
$form->field(name => "rcsinfo", value => "", force => 1);
sub sanitize (@) {
my %params=@_;
+ return $params{content} unless defined $config{htmltidy};
+
my $pid;
my $sigpipe=0;
$SIG{PIPE}=sub { $sigpipe=1 };
if ($feeds) {
if ($rss) {
$rssurl=abs2rel($feedbase."rss".$feednum, dirname(htmlpage($params{destpage})));
- $rssdesc = gettext("%s (RSS feed)", $desc);
+ $rssdesc = sprintf(gettext("%s (RSS feed)"), $desc);
}
if ($atom) {
$atomurl=abs2rel($feedbase."atom".$feednum, dirname(htmlpage($params{destpage})));
- $atomdesc = gettext("%s (Atom feed)", $desc);
+ $atomdesc = sprintf(gettext("%s (Atom feed)"), $desc);
}
}
sub import {
hook(type => "getsetup", id => "po", call => \&getsetup);
- hook(type => "checkconfig", id => "po", call => \&checkconfig);
+ hook(type => "checkconfig", id => "po", call => \&checkconfig,
+ last => 1);
hook(type => "needsbuild", id => "po", call => \&needsbuild);
hook(type => "scan", id => "po", call => \&scan, last => 1);
hook(type => "filter", id => "po", call => \&filter);
our $transientdir;
sub checkconfig () {
- eval q{use Cwd 'abs_path'};
- error($@) if $@;
- $transientdir = abs_path($config{wikistatedir})."/transient";
- add_underlay($transientdir);
+ $transientdir = $config{wikistatedir}."/transient";
+ # add_underlay treats relative underlays as relative to the installed
+ # location, not the cwd. That's not what we want here.
+ IkiWiki::add_literal_underlay($transientdir);
}
sub change (@) {
-ikiwiki (3.20110123) UNRELEASED; urgency=low
+ikiwiki (3.20110125) UNRELEASED; urgency=low
+
+ * editpage: Avoid inheriting internal page types.
+ * htmltidy: Avoid breaking the sidebar when websetup is running.
+
+ -- Joey Hess <joeyh@debian.org> Tue, 01 Feb 2011 21:00:57 -0400
+
+ikiwiki (3.20110124) unstable; urgency=low
+
+ * comments: Fix commenting, broken by security fix.
+ * blogspam: Don't check modifications from admins for spam, and also
+ allow the blogspam_pagespec to do other matches against who the user is.
+ * inline: Fix regression in feed titles. Closes: #610878
+ (Thanks, Paul Wise)
+
+ -- Joey Hess <joeyh@debian.org> Mon, 24 Jan 2011 17:07:44 -0400
+
+ikiwiki (3.20110123) unstable; urgency=low
* Adapt autoindex test suite to work with old Test::More.
+ * Fix posting by blog form, broken by last release.
- -- Joey Hess <joeyh@debian.org> Sat, 22 Jan 2011 11:00:37 -0400
+ -- Joey Hess <joeyh@debian.org> Sun, 23 Jan 2011 10:12:33 -0400
ikiwiki (3.20110122) unstable; urgency=medium
\[[!template id=gitbranch branch=yourrepo/amazingbranch author="\[[yourname]]"]]
+Branches that have been [[reviewed]] and need work will not be listed
+here.
+
Branches referred to in open [[bugs]] and [[todo]]:
[[!inline pages="(todo/* or bugs/*) and link(/branches) and !link(bugs/done)
Also see the [Debian bugs](http://bugs.debian.org/ikiwiki).
+There are [[!pagecount pages="bugs/* and !bugs/done and !bugs/discussion and
+!link(patch) and !link(bugs/done) and !bugs/*/*"
+feedpages="created_after(bugs/no_commit_mails_for_new_pages)"]] "open" bugs:
+
[[!inline pages="bugs/* and !bugs/done and !bugs/discussion and
!link(patch) and !link(bugs/done) and !bugs/*/*"
feedpages="created_after(bugs/no_commit_mails_for_new_pages)"
--- /dev/null
+Hi,
+
+found one strange thing here:
+
+If i enter a link like this
+
+ [#Wikipedia:Mollison]: <http://www.tagari.com/bills_journal>
+
+the underscore appears like this (i inserted a space in the undercore-string to make it 'visible'):
+
+ <a href="http://www.tagari.com/billsb14a7b8059d9c05 5954c92674ce60032journal">http://www.tagari.com/billsb14a7b8059d9c05 5954c92674ce60032journal</a>
+
+Am i doing something wrong?
+
+Thanks for your support and best wishes,
+Tobias.
+
+> I believe you're hitting some kind of Markdown-processing but (so not
+> strictly Ikiwiki related). Could you provide a minimal page source
+> exhibiting the problem, and mention the exact nature of the processor
+> you use? (Markdown, MultiMarkdown, pandoc, ...) --GB
I'll just modify the templates for my own site but I thought I'd report it as a bug in the hopes that it will be useful to others.
Cheers,
-Adam.
+[[AdamShand]].
----
> I just noticed that it's also different on the comments, preferences and edit pages. I'll come up with a diff and see what you guys think. -- Adam.
* page name displayed in 404: http://mcfrisk.kapsi.fi/skiing/posts/Iso-Sy%F6te%20Freeride%202011%20Teaser.html?updated
* page name in the blog feed: http://mcfrisk.kapsi.fi/skiing/posts/Iso-Sy%C3%B6te%20Freeride%202011%20Teaser.html
-Difference is in the word Iso-Syöte. Pehaps also the browsers is part of the game, I use Iceweasel from Debian unstable with default settings.
+Difference is in the word Iso-Syöte. Pehaps also the browsers is part of
+the game, I use Iceweasel from Debian unstable with default settings.
+
+> I remember seeing this problem twice before, and both times it was caused
+> by a bug in the *web server* configuration. I think at least one case it was
+> due to an apache rewrite rule that did a redirect and mangled the correct
+> encoding.
+>
+> I recommend you check there. If you cannot find the problem with your web
+> server, I recommend you get a http protocol dump while saving the page,
+> and post it here for analysis. You could use tcpdump, or one of the
+> browser plugins that allows examining the http protocol. --[[Joey]]
+
+Server runs Debian 5.0.8 but I don't have access to the Apache configs. Here's the tcp stream from wireshark without cookie data, page name is testiä.html. I guess page name is in utf-8 but in redirect after post it is given to browser with 8859-1.
+
+ POST /ikiwiki.cgi HTTP/1.1
+ Host: mcfrisk.kapsi.fi
+ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16)
+ Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+ Accept-Language: en-us,en;q=0.5
+ Accept-Encoding: gzip,deflate
+ Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+ Keep-Alive: 300
+ Connection: keep-alive
+ Referer: http://mcfrisk.kapsi.fi/ikiwiki.cgi
+ Cookie: XXXX
+ Content-Type: multipart/form-data; boundary=---------------------------138059850619952014921977844406
+ Content-Length: 1456
+
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="_submitted"
+
+ 2
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="do"
+
+ edit
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="sid"
+
+ 93c956725705aa0bbdff98e57efb28f4
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="from"
+
+
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="rcsinfo"
+
+ 5419fbf402e685643ca965d577dff3dafdd0fde9
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="page"
+
+ testi..
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="type"
+
+ mdwn
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="editcontent"
+
+ test
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="editmessage"
+
+
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="_submit"
+
+ Save Page
+ -----------------------------138059850619952014921977844406
+ Content-Disposition: form-data; name="attachment"; filename=""
+ Content-Type: application/octet-stream
+
+
+ -----------------------------138059850619952014921977844406--
+ HTTP/1.1 302 Found
+ Date: Wed, 02 Feb 2011 19:45:49 GMT
+ Server: Apache/2.2
+ Location: /testi%E4.html?updated
+ Content-Length: 0
+ Keep-Alive: timeout=5, max=500
+ Connection: Keep-Alive
+ Content-Type: text/plain
+
+ GET /testi%E4.html?updated HTTP/1.1
+ Host: mcfrisk.kapsi.fi
+ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16)
+ Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+ Accept-Language: en-us,en;q=0.5
+ Accept-Encoding: gzip,deflate
+ Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+ Keep-Alive: 300
+ Connection: keep-alive
+ Referer: http://mcfrisk.kapsi.fi/ikiwiki.cgi
+ Cookie: XXXX
+
+ HTTP/1.1 404 Not Found
+ Date: Wed, 02 Feb 2011 19:45:55 GMT
+ Server: Apache/2.2
+ Content-Length: 279
+ Keep-Alive: timeout=5, max=499
+ Connection: Keep-Alive
+ Content-Type: text/html; charset=iso-8859-1
+
+ <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+ <html><head>
+ <title>404 Not Found</title>
+ </head><body>
+ <h1>Not Found</h1>
+ <p>The requested URL /testi..html was not found on this server.</p>
+ <hr>
+ <address>Apache/2.2 Server at mcfrisk.kapsi.fi Port 80</address>
+ </body></html>
+
+Getting the pages has worked every time:
+
+ GET /testi%C3%A4.html HTTP/1.1
+ Host: mcfrisk.kapsi.fi
+ User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16)
+ Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+ Accept-Language: en-us,en;q=0.5
+ Accept-Encoding: gzip,deflate
+ Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+ Keep-Alive: 300
+ Connection: keep-alive
+ Cookie: XXXX
+ If-Modified-Since: Wed, 02 Feb 2011 19:45:54 GMT
+ If-None-Match: "1b518d-7c0-49b51e5a55c5f"
+ Cache-Control: max-age=0
+
+ HTTP/1.1 304 Not Modified
+ Date: Wed, 02 Feb 2011 20:01:43 GMT
+ Server: Apache/2.2
+ Connection: Keep-Alive
+ Keep-Alive: timeout=5, max=500
+ ETag: "1b518d-7c0-49b51e5a55c5f"
--- /dev/null
+The [[plugins/inline]] and [[plugins/comments]] plugins both generate feed links.
+
+In both cases, the generated markup include an element with `id="feedlink"`.
+
+[XHTML 1.0 Strict](http://www.w3.org/TR/xhtml1/#h-4.10) (Ikiwiki's default output type) forbids multiple elements with the same ID:
+
+> In XML, fragment identifiers are of type ID, and there can only be a single attribute of type ID per element. Therefore, in XHTML 1.0 the id attribute is defined to be of type ID. In order to ensure that XHTML 1.0 documents are well-structured XML documents, XHTML 1.0 documents MUST use the id attribute when defining fragment identifiers on the elements listed above. See the HTML Compatibility Guidelines for information on ensuring such anchors are backward compatible when serving XHTML documents as media type text/html.
+
+As does [W3C's HTML5](http://www.w3.org/TR/html5/elements.html#the-id-attribute).
+
+Any page with both a comments feed and an inline feed will be invalid XHTML 1.0 Strict or HTML 5.
+
+-- [[Jon]]
+
+> [[news/version_3.2011012]] suggests this is fixed for `inline`, at least, I will test to see if it is cleared up for comments too. -- [[Jon]]
--- /dev/null
+If a comment contains a WikiLink, for a page that doesn't exist, and the
+user clicks on the edit link, and creates the page, it will itself be saved
+as a comment, with "._comment" extension.
+
+This is very surprising and wrong behavior. The page editor tries to
+preserve the linking page's format type, but it shouldn't do so if the page
+is an internal page. --[[Joey]]
+
+[[done]] --[[Joey]]
Yes I am only trying to set it to loaded and working plugins.
ikiwiki version 3.20101129
+
+> I've tested `default_pageext` with 3.20110124, and it works fine.
+>
+> It seems to me from what you describe that you expect
+> it to have an effect when you go and edit an existing page.
+> That's not what it's for, it only chooses the default used
+> when creating a new page.
+>
+> Closing this bug as apparent user error. --[[Joey]] [[done]]
* 27. March
* 99. November
* 42. April
+
+> That's a consequence of Markdown syntax. The syntax for ordered lists
+> (HTML `<ol>`) in Markdown is to use arbitrary numeric prefixes in that style,
+> so your text gets parsed as:
+>
+> <ul>
+> <li>
+> <ol>
+> <li>January</li>
+> </ol>
+> </li>
+> ...
+>
+> You can avoid that interpretation by escaping the dot with a backslash
+> (`1\. January`) like so:
+>
+> * 1\. January
+> * 27\. March
+>
+> or by writing "1st January" and so on. --[[smcv]]
+
+>> I think that this is a bug in Text::Markdown (and probably other
+>> versions of markdown). The [markdown spec)(http://daringfireball.net/projects/markdown/syntax.text),
+>> though unmaintained and bitrotted into near illegibility, seems to say
+>> that list items can only be preceeded by whitespace:
+>>
+>>> "List markers typically start at the left margin, but may be indented by
+>>> up to three spaces."
+>>
+>> So "* * * 1. 2. 3." should not be parsed as a deeply nested list.
+>>
+>> Forwarded to [upsteam RT](https://rt.cpan.org/Ticket/Display.html?id=65116). [[done]] --[[Joey]]
--- /dev/null
+I'm using the [[map_directive|ikiwiki/directive/map]] to build dynamic navigation menus, and it's working really nicely!
+
+However on some pages, each nested item each get wrapped in a full set of `<ul>` tags. This doesn't actually hurt anything, but it's does it inconsistently which seems like a bug. I don't like it because it puts extra vertical spacing into my menu bar.
+
+Here's what I expect it to look like:
+
+ <div class="map">
+ <ul>
+ <li><span class="selflink">Archives</span>
+ <ul>
+ <li><a href="./2010/" class="mapitem">2010</a></li>
+ <li><a href="./2011/" class="mapitem">2011</a></li>
+ </ul>
+ </li>
+ </ul>
+ </div>
+
+And here's what it's actually doing:
+
+ <div class="map">
+ <ul>
+ <li><span class="selflink">Archives</span>
+ <ul>
+ <li><a href="./2010/" class="mapitem">2010</a></li>
+ </ul>
+ <ul>
+ <li><a href="./2011/" class="mapitem">2011</a></li>
+ </ul>
+ </li>
+ </ul>
+ </div>
+
+I've tried to replicate the problem on this site and cannot, I'm not sure if that's because of exactly how I'm using map or if there's something different with my site. I just upgraded ikiwiki to the latest Debian unstable as well as most of the required Perl modules and nothing changed.
+
+If you look at [this page on my site](http://adam.shand.net/ikidev/archives/) (getsource is enabled) you can see it working as expected in the main page and not working in the side bar.
+
+But it also doesn't work on the sitemap page: <http://adam.shand.net/ikidev/site/map/>
+
+This might be really simple, but I've been staring at it too long and it only looks like a bug to me. :-( Any suggestions would be gratefully accepted. -- [[AdamShand]]
+
+> Okay, I think I've figured this out, it looks like ikiwiki behaves differently depending on the level of heirarchy. I'll post the details once I'm sure. -- [[AdamShand]]
+
+>> I managed to replicate the issue on my ikiwiki, and I believe it is a
+>> bug. The current upstream logic for going up/down by a level opens
+>> (and closes) the unnecessary lists that you are seeing. Although the
+>> resulting markup is semantically correct, it has superflous stuff
+>> that introduces whitespace issues at the very least.
+
+>> I have a [[patch]] up [on my git repo](http://git.oblomov.eu/ikiwiki/patch/55fa11e8a5fb351f9371533c758d8bd3eb9de245)
+>> that ought to fix the issue.
+
+>>> Wonderful, thank you very much for the help! I've installed the patch and it's working great, but it looks like there a minor bug. Sometimes it doesn't print the top/first map item. Cheers, -- [[AdamShand]]
+>>>
+>>> <http://adam.shand.net/tmp/map-orig.jpg>
+>>> <http://adam.shand.net/tmp/map-patched.jpg>
+
+>>>> Thanks for testing. I managed to reproduce it and I adjusted the logic.
+>>>> An updated [[patch]] can be found [here](http://git.oblomov.eu/ikiwiki/patch/dcfb18b7989a9912ed9489f5ff15f871b6d8c24a)
+
+>>>>> Seems to work perfectly to me, thanks! -- [[AdamShand]]
for instance, if you have `add_plugins => qw(po smiley)`, you'll probably
not get the translated versions of `smileys.mdwn`. (I haven't tested this.)
+> It doesn't happen because smiley adds the underlay unconditionally on
+> import. Which is really more usual.
+
To see them all, `po` should use `last => 1` when registering the hook.
--[[smcv]]
+
+> At least all that don't last their hooks too! But, added, since
+> it will make the problem much less likely to occur. --[[Joey]] [[done]]
[[todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both]]
that made `baseurl(undef)` relative.
And I suppose, re-opening that todo. :( --[[Joey]]
+
+----
+
+This was fixed in version 3.20110105 [[done]] --[[Joey]]
## Debian / Ubuntu packages
-To install with apt, if using Debian or Ubuntu:
+To install with [apt](http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_basic_package_management_operations), if using Debian or Ubuntu:
apt-get install ikiwiki
--- /dev/null
+Hi there..
--- /dev/null
+Do custom [[themes]] have to live outside of the wiki (eg. `/usr/share/ikiwiki/themes/`) or is there a way for them to live inside of the wiki srcdir?
+
+I haven't been able to find a way so for now I'm just using a symlink, but that's a bit ugly.
+
+I ask because I do most of my ikiwiki work on my laptop and then push changes to my server. It's not a big deal but it's annoying to have to sync the themes separately and it seems like something which should be able to live inside the wiki like templates.
+
+Cheers,
+[[AdamShand]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://smcv.pseudorandom.co.uk/"
+ nickname="smcv"
+ subject="comment 1"
+ date="2011-01-29T18:17:40Z"
+ content="""
+The theme plugin is just a shortcut for adding an underlay with a style.css and maybe some images. If you want to base your design on a modified theme, copy the theme's style.css (or part of it) to the local.css in your wiki's repository; you can also copy in the images and disable the theme plugin entirely.
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://adam.shand.net/"
+ nickname="Adam"
+ subject="Doh."
+ date="2011-01-29T19:32:18Z"
+ content="""
+Ah that makes sense, thanks!
+"""]]
--- /dev/null
+Hi People,
+
+first thanks for this nice an usable piece of software.
+
+Recently i moved to a new server, reinstalled ikiwiki via aptitude and now i'm getting this error:
+
+ ikiwiki -setup /etc/ikiwiki/auto.setup
+ /etc/ikiwiki/auto.setup: Can't locate IkiWiki/Setup/Automator.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at (eval 10) line 13.
+
+Or with an existing wiki:
+
+ ikiwiki -setup younameit.setup
+ younameit.setup: Can't use an undefined value as an ARRAY reference at /usr/share/perl5/IkiWiki/Setup/Standard.pm line 33.
+ BEGIN failed--compilation aborted at (eval 10) line 293.
+
+Can you help?
+
+Best wishes,
+Tobias.
--- /dev/null
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 1"
+ date="2011-01-25T19:18:21Z"
+ content="""
+You're using an old version of ikiwiki with setup files from a newer version. That won't work for various reasons, and the simplest fix is to upgrade your server to the version you had before.
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="tk"
+ ip="79.222.20.29"
+ subject="comment 4"
+ date="2011-01-26T12:34:29Z"
+ content="""
+Thank you for the fast reply, Joey!
+I tried it with ikiwiki from debian backports and it works as usual :)
+
+Bye,
+Tobias.
+
+"""]]
--- /dev/null
+I'm new to ikiwiki and I'm trying to install it and set it up. I've read the documentation but I still don't understand how access to the repository works. We want ikiwiki to run on one machine but we want the repository to be on a separate machine running svn. How can I configure ikiwiki to access the repository on the remote machine? And how is authentication on the remote host handled in ikiwiki? Does there have to be a one-to-one correspondence between account names (and passwords) on the ikiwiki machine and the accounts on the svn machine? Thanks,
+
+Eric
--- /dev/null
+[[!comment format=mdwn
+ username="http://adam.shand.net/"
+ nickname="Adam"
+ subject="Depending ..."
+ date="2011-01-25T03:00:12Z"
+ content="""
+... on exactly what you are trying to do, you may find some answers [[here|forum/how_to_setup_ikiwiki_on_a_remote_host/]].
+
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="here's the scoop .. but, don't do it"
+ date="2011-01-25T18:30:01Z"
+ content="""
+To do what you describe, you would set up the svn repository on your server, and then do a regular svn checkout of it to the machine running ikiwiki, and configure ikiwiki to use that directory as its srcdir. The only unix user ikiwiki does anything as is the one you use to set it up, so it's up to you to allow that user to commit to svn without needing to enter a password.
+
+However, I don't recommend this configuration at all. You're adding a ssh (or webdav) connection overhead to every edit to the wiki, since ikiwiki's commit to svn will have to be pushed across the network to the server. And ikiwiki's svn support is missing many of the [[newer_ikiwiki_features|rcs]], such as including for example support for easily reverting edits.
+"""]]
--- /dev/null
+I'm trying to create a [[!iki plugins/template desc=template]] which references variables from the [[!iki plugins/meta desc=meta]] plugin, but either it's not supported or I'm doing something wrong. This is what my template looks like:
+
+ <div class="attributionbox">
+ <p><b>Written by:</b> <a href="<TMPL_VAR AUTHORURL>"><TMPL_VAR AUTHOR></a></p>
+ <p><TMPL_VAR text></b></p>
+ </div>
+
+The template is working because I get the content, but all the places where I reference meta variables are blank. Is this supposed to work or am I trying to do something unsupported? Many thanks for any pointers.
+
+Cheers,
+[[AdamShand]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://smcv.pseudorandom.co.uk/"
+ nickname="smcv"
+ subject="not supported at the moment"
+ date="2011-01-24T15:17:59Z"
+ content="""
+This isn't supported, because [[ikiwiki/directive/template]] templates
+don't run `pagetemplate` hooks (which is how information gets from
+[[ikiwiki/directive/meta]] into, for instance, `page.tmpl`). The only
+inputs to the `HTML::Template` are the parameters passed to the
+directive, plus the `raw_`-prefixed versions of those, plus the extra
+parameters passed to every `preprocess` hook (currently `page`, `destpage`
+and `preview`).
+
+I think having `pagetemplate` hooks run for this sort of template
+by default would be rather astonishing, but perhaps some sort of
+opt-in while defining the template would be reasonable? One problem
+with that is that the templates used by [[ikiwiki/directive/template]]
+are just wiki pages, and don't really have any special syntax support.
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://adam.shand.net/"
+ nickname="Adam"
+ subject="Bummer."
+ date="2011-01-24T15:26:33Z"
+ content="""
+Thanks for the quick response! I'm trying to figure out some way that I can reference meta variables inside of a page. Specifically I'm trying to create an attribution box which lists all of the information I have about who wrote the page, where the original can be found etc. I can just pass the values to the template, but it would be really nice not have to put this information in for the meta plugin and my attribution box!
+
+The changes you suggest sound wonderful but are beyond my abilities right row. Any ideas how I might accomplish this in the mean time?
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://smcv.pseudorandom.co.uk/"
+ nickname="smcv"
+ subject="comment 3"
+ date="2011-01-24T20:58:52Z"
+ content="""
+I usually just have a template that contains a suitable `\[[!meta]]` directive.
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://kerravonsen.dreamwidth.org/"
+ ip="202.173.183.92"
+ subject="contrib plugins can do this"
+ date="2011-01-24T23:11:40Z"
+ content="""
+You can do this by using the [[plugins/contrib/field]] plugin with the [[plugins/contrib/ftemplate]] plugin.
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://adam.shand.net/"
+ nickname="Adam"
+ subject="Thanks!"
+ date="2011-01-25T02:51:35Z"
+ content="""
+smcv, sorry I don't understand? How are you getting the \[[!meta] to work on a template page, I thought that's what you said didn't work? Do you mean a pagetemplate?
+
+kerravonsen, thanks for the pointer I'll check those out.
+
+I realised last night that I think I could also do this with a pagetemplate, since I should be able to access meta variables there. A little clumsy for what I want to do but should hopefully work fine. Would be really neat with the [section template](http://ikiwiki.info/todo/Set_templates_for_whole_sections_of_the_site/) plugin, I'll have to look at that.
+"""]]
* [[privat]] `git://github.com/privat/ikiwiki.git`
* [[blipvert]] `git://github.com/blipvert/ikiwiki.git`
* [[bzed|BerndZeimetz]] `git://git.recluse.de/users/bzed/ikiwiki.git`
-* [[wtk]]: `git://github.com/wking/ikiwiki.git`
+* [[wtk]] `git://github.com/wking/ikiwiki.git`
## branches
\[[!meta field="value" param="value" param="value"]]
The first form sets a given field to a given value, while the second form
-also specifies some additional sub-parameters.
+also specifies some additional sub-parameters. You can have only one field
+per `meta` directive, use more directives if you want to specify more fields.
The field values are treated as HTML entity-escaped text, so you can include
a quote in the text by writing `"` and so on.
* [PDFpirate Community](http://community.pdfpirate.org/)
* [Banu](https://banu.com/) uses Ikiwiki for its website, to convert static Markdown pages into PHP scripts which are served along with non-Ikiwiki PHP generated contents. The static contents benefit from use of Ikiwiki's plugins. Ikiwiki is purely used as a CMS and no wiki or web-based editing is allowed. Ikiwiki is run offline, and the resulting scripts are uploaded using rsync to the website.
* [Software in the Public Interest](http://spi-inc.org/)
+* [NXT Improved Firmware](http://nxt-firmware.ni.fr.eu.org/)
Personal sites and blogs
========================
+++ /dev/null
-ikiwiki 3.20101129 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * websetup: Fix encoding problem when restoring old setup file.
- * more: Add pages parameter to limit where the more is displayed.
- (thanks, dark)
- * Fix escaping of filenames in historyurl. (Thanks, aj)
- * inline: Improve RSS url munging to use a proper html parser,
- and support all elements that HTML::Tagset knows about.
- (Which doesn't include html5 just yet, but then the old version
- didn't either.) Bonus: 4 times faster than old regexp method.
- * Optimise glob() pagespec. (Thanks, Kathryn and smcv)
- * highlight: Support new format of filetypes.conf used by version 3.2
- of the highlight package.
- * edittemplate: Fix crash if using a .tmpl file or other non-page file
- as a template for a new page.
- * git: Fix temp file location.
- * rename: Fix to pass named parameters to rcs\_commit.
- * git: Avoid adding files when committing, so as not to implicitly add
- files like recentchanges files that are not normally checked in,
- when fixing links after rename."""]]
\ No newline at end of file
+++ /dev/null
-ikiwiki 3.20101201 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * meta: Fix calling of htmlscrubber to pass the page parameter.
- The change of the htmlscrubber to look at page rather than destpage
- caused htmlscrubber\_skip to not work for meta directives."""]]
\ No newline at end of file
--- /dev/null
+ikiwiki 3.20110123 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Adapt autoindex test suite to work with old Test::More.
+ * Fix posting by blog form, broken by last release."""]]
\ No newline at end of file
--- /dev/null
+ikiwiki 3.20110124 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * comments: Fix commenting, broken by security fix.
+ * blogspam: Don't check modifications from admins for spam, and also
+ allow the blogspam\_pagespec to do other matches against who the user is.
+ * inline: Fix regression in feed titles. Closes: #[610878](http://bugs.debian.org/610878)
+ (Thanks, Paul Wise)"""]]
\ No newline at end of file
The `blogspam_pagespec` setting is a [[ikiwiki/PageSpec]] that can be
used to configure which pages are checked for spam. The default is to check
all edits. If you only want to check [[comments]] (not wiki page edits),
-set it to "postcomment(*)".
+set it to "postcomment(*)". Posts by admins are never checked for spam.
By default, the blogspam.net server is used to do the spam checking. To
change this, the `blogspam_server` option can be set to the url for a
> that ikiwiki itself does not require. --[[Joey]]
### Once one has enabled the 'theme' plugin in the setup file, how does one use themes?
+
+Choose one of the [[themes]] which are bundled with ikiwiki and configure ikiwiki to use it by setting this in your setup file, eg.
+
+ theme => 'blueview',
+
+-- [[AdamShand]]
repositories are also clones of the bare root repository above --
and these have a working directory for you to work on. Use either
the `git` transport (if available), or `ssh`. These repositories may
- be on remote machines, your laptop, whereever you find convenient to
- hack on your wiki. you can commit local changes to the version on
+ be on remote machines, your laptop, wherever you find convenient to
+ hack on your wiki. You can commit local changes to the version on
the laptop, perhaps while offline. Any new content should be pushed to the
bare master repository when you are ready to publish it, and then
the post-update hook of the bare repository will ensure that the
--- /dev/null
+This page lists [[branches]] that have been reviewed. If your branch
+shows up here, the ball is back in your court, to respond to the review and
+deal with whatever is preventing it from being merged into ikiwiki. Once
+you do, remove the "reviewed" tag.
+
+[[!inline pages="(todo/* or bugs/*) and link(/branches) and !link(bugs/done)
+and !link(todo/done) and !*/*/* and link(.)" show=0 archive=yes]]
## Install ikiwiki
-If you're using Debian or Ubuntu, ikiwiki is an `apt-get install ikiwiki` away.
+If you're using Debian or Ubuntu, ikiwiki is an <code><a href="http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_basic_package_management_operations">apt-get</a> install ikiwiki</code> away.
If you're not, see the [[download]] and [[install]] pages.
## Create your wiki
[[by_hand|byhand]].
"""]]
- % ikiwiki -setup /etc/ikiwiki/auto.setup
+ % ikiwiki --setup /etc/ikiwiki/auto.setup
Or, set up a blog with ikiwiki, run this command instead.
- % ikiwiki -setup /etc/ikiwiki/auto-blog.setup
+ % ikiwiki --setup /etc/ikiwiki/auto-blog.setup
`librpc-xml-perl` and `python-docutils` dependencies are needed.
destdir: ~/public_html/foo
repository: ~/foo.git
To modify settings, edit ~/foo.setup and then run:
- ikiwiki -setup ~/foo.setup
+ ikiwiki --setup ~/foo.setup
Done!
After making changes to this file, you need to tell ikiwiki to use it:
- % ikiwiki -setup foo.setup
+ % ikiwiki --setup foo.setup
Alternatively, you can ask ikiwiki to change settings in the file for you:
- % ikiwiki -changesetup foo.setup -plugin goodstuff
+ % ikiwiki --changesetup foo.setup --plugin goodstuff
See [[usage]] for more options.
Finally, edit the setup file. Modify the settings for `srcdir`, `destdir`,
`url`, `cgiurl`, `cgi_wrapper`, `git_wrapper`, etc to reflect where
-you moved things. Remember to run `ikiwiki -setup` after editing the
+you moved things. Remember to run `ikiwiki --setup` after editing the
setup file.
## Enjoy your new wiki!
external Markdown executable in your ikiwiki config file. If you do
not set a path, the plugin will use the usual config options to
determine which Perl module to use.
+
+> This adds a configuration in which a new process has to be worked
+> for every single page rendered. Actually, it doesn't only add
+> such a configuration, it makes it be done by *default*.
+>
+> Markdown is ikiwiki's default, standard renderer. A configuration
+> that makes it slow will make ikiwiki look bad.
+>
+> I would not recommend using Gruber's perl markdown. It is old, terminally
+> buggy, and unmaintained. --[[Joey]] [[!tag reviewed]]
--- /dev/null
+pushing [[this|todo/httpauth feature parity with passwordauth]] and [[this|todo/htpasswd mirror of the userdb]] further (although rather in the [[wishlist]] priority): would it make sense for users to have a `$USER/credentials` page that is by default locked to the user and admins, where the user can state one or more of the below?
+
+* OpenID
+* ssh public key (would require an additional mechanism for writing this to a `authorized_keys` file with appropriate environment variables or prefix that makes sure the commit is checked against the right user and that the user names agree)
+* gpg public key (once there is a mechanism that relies on gpg for authentication))
+* https certificate hash (don't know details; afair the creation of such certificates is typically initiated server-side)
+* password hash (this is generally considered a valuable secret; is this still true with good hashes and proper salting?)
+
+such a page could have a form as described in [[todo/structured page data]] and could even serve as a way of managing users. --[[chrysn]]
+
+> I was just thinking about something along these lines myself. The
+> idea, if I understand correctly, is to allow users to have multiple
+> login options all leading to the same identity. This would allow a
+> user to login for example via either their Google account or their
+> WordPress account, while still being identified as the same user.
+
+> However, I'm not sure this should be a static page (I guess you
+> mean `$USER/credentials`, I don't think ‘creditentials’ actually
+> exists). Something entirely managed at the CGI level is probably
+> better, as it also helps keeping the data in its place (such as ssh
+> public keys in `authorized_keys` etc).
+
+> -- GB
+
+>> having multiple login options leading to the same identity, and (more important to me) giving the user an easy way to review and edit them. i'm thinking a bit of foaf+ssl style "i am $USER and you can recognize me by my client certificate $CERTIFICATE" statements.
+>>
+>> the reason why i want this in a static place instead of cgi level is that it can be used, for example, for automatically creating htpasswd files for read-only (cgi-less) replicas of private wikis. furthermore, it all gets versioned and it can easily be seen where the data really is. the credentials have to be filed appropriately by plugins anyway, but that can happen as a part of the regular rebuild process.
+>>
+>> and yes, you're right about the word misusage; thanks for pointing it out and fixing it.
+>>
+>> --[[chrysn]]
+
+an issue to be considered: for ways of authentication that don't explicitly mention the user name (and that would be everything but password; especially OpenID), there has to be a way to prevent users from hijacking an admin's account. the user wouldn't get more privileges, but the admin could find himself logged in as a user instead of an admin when he logs in using his OpenID, for example. he could fix it by removing the openid from the user's ("his") page, but it has to be taken care of nevertheless. --[[chrysn]]
[[!template id=gitbranch branch=GiuseppeBilotta/inlinestuff author="Giuseppe Bilotta"]]
-A few patches to clean up and improve feed management for inline pages.
-
-(I moved the picked/scratched stuff at the bottom.)
-
-* the (now first) patch tries to define the default description for a feed based not only on the wiki name,
- but also on the current page name. The actual way this is built might not be the optimal one,
- so I'm open to suggestions
-
- > I don't really like using "wikiname/page" as the name of the feed. It's
- > a bit too mechanical. I'd be ok with using just the page name,
- > with a fallback to wikiname for the toplevel index. Or maybe
- > something like "$wikiname's $page".
- >
- > Also, shouldn't `pagetitle` be run on the page name? (Haven't checked.)
- > --[[Joey]]
-
- >> The rewritten patch now sets the feed title using the page title, and the feed description
- >> using the page _description_, both obtained from meta if possible. If there is no page
- >> description, then we use the page title combined with the wiki name. I introduce a new
- >> configuration key to customize the actual automatic description.
-
- >>> The feed title part of this seems unnecessary. As far as I can see,
- >>> ikiwiki already uses the page title as the feed title; TITLE in the
- >>> rsspage.tmpl is handled the same as TITLE in page.tmpl. --[[Joey]]
-
- >>>> I'm afraid this is not the case in the ikiwiki I have. It might be the effect of some kind of interaction of
- >>>> this with the next patch, but apparently I need both to ensure that the proper title is being used.
-
- >>>> Some further analysis: before my patch, the feed title would be set to
- >>>> `pagetitle($page)`, or to the wiki name if the pagetitle was index. As
- >>>> it turns out, in my setup (see below for details) this happens quite
- >>>> often on my `dirN.mdwn` index pages, where I would like to have `dirN`
- >>>> as title instead. Plus, unless I'm mistaken, `pagetitle()` doesn't
- >>>> actually use `meta` information, which my patch does. So I still think
- >>>> the title part of the patch is worth it. As a bonus, it also allows title
- >>>> customization by the `title=` parameter as offered in another patch.
-
-* the (now second) patch passes uses the included rather than the including page for the URL. This is
- actually a forgotten piece from my previous patch (now upstream) to base the feed name on the
- included rather than the including page, and it's only relevant for nested inline pages.
-
- > I have a vague memory of considering doing this before, and not,
- > because there is actually no guarantee that the inlined page (that
- > itself contains an inline) will generate an url. It could be excluded;
- > it could be an internal page; it could use a conditional to omit the
- > inline when not inlined.
-
- >> I would say that in this cases my patch wouldn't change anything because
- >> either the code would still act as before or it wouldn't be triggered at
- >> all. --GB
-
- > Also, I think that `destpage` gets set wrong. And I think that
- > `get_inline_content` is called with the source page, rather than the
- > destpage, and so could generate urls that don't work on the destpage.
-
- >> `destpage` getting set wrong is probably a bug that should be
- >> fixed, but I must say I haven't come across it (yet).
- >> `get_inline_content` is called with both the source and dest page,
- >> and in my experience the urls have always been generated correctly.
-
- > All in all, this is an edge case, and currently seems to work ok, so
- > why change it? --[[Joey]]
-
- >> Because it does not work ok for me. I have a number of directories `dir1/`, `dir2/`, `dir3/`
- >> each with a corresponding `dir1.mdwn`, `dir2.mdwn`, `dir3.mdwn` etc that is basically just
- >> an inline instruction. Then my index.mdwn inlines `dir[123]`. Without these two patches, the
- >> `dir[123]` feeds get the wrong title.
-
-* the (new) fourth patch introduces a `feedtitle` parameter to override the feed title. I opted for
- not squashing it with the second patch to allow you to scrap this but still get the other, in case
- you're not too happy about having a plethora of parameters
-
- > This seems clearly a good idea, since there is already a "description"
- > parameter. But, by analogy with that parameter, it should just be
- > called "title". --[[Joey]]
-
- >> I'll rework the patch to that effect.
-
-* a fifth patch introduces an `id` parameter to allow setting the HTML id attribute in the
- blogpost/feedlinks template. Since we replace their id with a class (first patch), this brings
- back the possibility for direct CSS customization and JavaScript manipulation based on id.
-
- > That sort of makes sense, but it somehow seems wrong that "id" should
- > apply to only cruft at the top of the inline, and not the entire div
- > generated for it. --[[Joey]]
-
- >> Good point. I'll look into a way to move the id to the `inlinepage` div, although I guess
- >> that falling back to `id`ing the `feedlink` div in the feedonly case would be ok.
-
- >> After looking into it, I hit again the same naive error I did while
- >> working on inline the first time: there is no "outer" div that
- >> encloses all of the generated content: each inlined page has its
- >> "inlinepage"-classed div, and the lot of them is prefixed by either
- >> the feedlinks or postform template output. So the only way to "id"
- >> a whole block of inlines is by adding a wrapping div that encloses
- >> the whole product of the inline directive. I can do that if you
- >> believe it's worth it.
-
-* 30a4de2aa3ab29dd9397c2edd91676e80bc06feb "urlto: prevent // when {url} ends with /"
-
- > The `url` in the setup file should not end in a slash. Probably more
- > things get ugly doubled slashes if someone does that. --[[Joey]]
-
- >> I was not aware of this. Did I miss it or is it just not documented?
- >> Also, grepping through the current official code (core and plugins)
- >> there is only one other place that looks like it could be affected
- >> by the `url` config ending in slash, and it's the `$local_url`
- >> stuff in `IkiWiki.pm`, but that code does terminal double-slash
- >> sanitation itself. So it would seem that my proposed patch would
- >> lift the restriction about the terminal / (an otherwise unnecessary
- >> restriction) without affecting much, as long as `url` users rely on
- >> the core functions to build paths with it (as in the next patch).
-
-* 57a9b5c4affda9e855f09a64747e5225d6254079 "inline: use urlto instead of manually building the RSS url"
-
- > Well, that seems ok. 3 parameter urlto should give us an absolute url.
- >
- > But we have to be careful and verify that it will always produce
- > exactly the same url as before. Changing the feed url unnecessarily
- > can probably flood aggregators or something... --[[Joey]]
-
- >> AFAICS, the feed url would only change in the case of /-terminating
- >> `$config{url}`, and even then only if the preceding urlto sanitation patch
- >> was included too.
-
-
------
-
-* the first patch simply replaces the id attribute in the default template for feedlinks with a class attribute by the same name. This is necessary in pages with multiple inlines to guarantee correctness
-
- > Ok, but blogform.tmpl has the same problem. And either change can need
- > CSS changes. (blogform in particular is used in style.css as an id.)
- > So this needs more documentation and associated work. --[[Joey]]
-
- >> I didn't include blogform in the change because the case of two
- >> blog post forms in the same page is probably extremely rare. But
- >> then again I remember doing having them in one of my ikiwiki
- >> draftings, so I rewrote the patch to include blogform. I had
- >> checked the distributed CSS for #feedlinks references, without
- >> finding any. The new patch does include CSS changes for the
- >> \#blogform -> .blogform change. I have no idea on where to document
- >> this change though.
-
- >>> Picked. NEWSed. --[[Joey]]
-
-
-* the (former) third patch passes the feed titles to the templates, changing the default templates to use these as title attributes for the links. a rel="alternate" attribute is also included
-
- > Seems reasonable. Cherry-picked. Note that the title attribute
- > will be shown by browsers as a tooltip. So I made it say
- > "$name (RSS feed)"
-
- >> Good, thanks.
-
-* the (former) fourth patch introduces a feedlinks parameter to the inline directive, to allow for the specifications of the locations where the feed links should appear. Currently, two options are allowed (head and body), plus both and none with obvious significance
-
- > Hmm. This doesn't affect the feed links in the blogform.tmpl. Anyway,
- > this is not something I see a real benefit of making configurable above
- > the template editing level. I don't see any point whatsoever of
- > allowing to turn off the feed links in the `<head>` -- they are not
- > user-visible, and IIRC that is the recommended and most portable way
- > to encode the information for feed discovery agents (rather than
- > putting it in the body). And the sorry state of "modern" browsers,
- > such as chromium's support for RSS means that it still makes sense to
- > have user-visible feed buttons. If that changed, it would make sense to
- > modify ikiwiki to globally remove them. --[[Joey]]
-
- >> I was actually quite surprised myself by the lack of automatic feed
- >> discovery in chromium (although I noticed there's a sort-of
- >> official plugin to do it). Overall, I believe your critique is
- >> well-founded, I'll scratch this patch.
+I rearranged my patchset once again, to clearly identify the origin and
+motivation of each patch, which is explained in the following.
+
+In my ikiwiki-based website I have the following situation:
+
+* `$config{usedirs}` is 1
+* there are a number of subdirectories (A/, B/, C/, etc)
+ with pages under each of them (A/page1, A/page2, B/page3, etc)
+* 'index pages' for each subdirectory: A.mdwn, B.mdwn, C.mdwn;
+ these are rather barebone, only contain an inline directive for their
+ respective subpages and become A/index.html, etc
+* there is also the main index.mdwn, which inlines A.mdwn, B.mdwn, C.mdwn,
+ etc (i.e. the top-level index files are also inlined on the homepage)
+
+With the upstream `inline` plugin, the feeds for A, B, C etc are located
+in `A/index.atom`, `B/index.atom`, etc; their title is the wiki name and
+their main link goes to the wiki homepage rather than to their
+respective subdir (e.g. I would expect `A/index.atom` to have a link to
+`http://website/A` but it actually points to `http://website/`).
+
+This is due to them being generated from the main index page, and is
+fixed by the first patch: ‘inline: base feed urls on included page
+name’. As explained in the commit message for the patch itself, this is
+a ‘forgotten part’ from a previous page vs destpage fix which has
+already been included upstream.
+
+The second patch, ‘inline: improve feed title and description
+management’, aligns feed title and description management by introducing
+a `title` option to complement `description`, and by basing the
+description on the page description if the entry is missing. If no
+description is provided by either the directive parameter or the page
+metadata, we use a user-configurable default based on both the page
+title and wiki name rather than hard-coding the wiki name as description.
+
+The third patch, ‘inline: allow assigning an id to postform/feedlink’,
+does just that. I don't currently use it, but it can be particularly
+useful in the postform case for example for scriptable management of
+multiple postforms in the same page.
+
+In one of my wiki setups I had a terminating '/' in `$config{url}`. You
+mention that it should not be present, but I have not seen this
+requirement described anywhere. Rather than restricting the user input,
+I propose a patch that prevents double slashes from appearing in links
+created by `urlto()` by fixing the routine itself.
+
+The inline plugin is also updated (in a separate patch) to use `urlto()`
+rather than hand-coding the feed urls. You might want to keep this
+change even if you discard the urlto patch.
>>> will be easier to merge or reject. Note the new branch name:
>>> `raw_inline`. I'll open separate todo items for items mentioned in my
>>> previous comment. --[[wtk]]
+
+----
+
+Reviewing your patch the first thing I see is this:
+
+<pre>
++ if (! $file) {
++ error("Missing file.");
++ }
+</pre>
+
+This fails if the filename is "0". Also, `pagetype()`
+currently cannot fail; allowing it to crash the entire
+wiki build if the filename is somehow undefined seems
+unwise.
+
+I didn't look much further, because it seems to me what you're trying to do
+can be better accomplished by using the highlight plugin. Assuming the raw
+file you want to inline and comment on is some source-code-like thing,
+which seems likely.
+
+Or, another way to do it would be to use the templates plugin, and make
+a template there that puts an inline directive inside pre tags.
+ --[[Joey]] [[!tag reviewed]]
[[!meta title="Adam Shand"]]
-New IkiWiki user (well not really "new" anymore), long time wiki user. :-)
+New ikiwiki user (well not really "new" anymore), long time wiki user. :-)
<http://adam.shand.net/iki/>
+
+[[!map pages="link(AdamShand)"]]
+
+<!-- for map bug
+## Correct? (No extra ULs)
+\[[!map pages="setup*" show="title"]]
+
+## Bug? (Extra UL for each LI)
+\[[!map pages="tagged(done) and tagged(patch)" show="title"]]
+-->
Name: ikiwiki
-Version: 3.20110122
+Version: 3.20110124
Release: 1%{?dist}
Summary: A wiki compiler
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2011-01-22 10:35-0400\n"
+"POT-Creation-Date: 2011-01-27 17:13-0400\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
msgid "automatic index generation"
msgstr ""
-#: ../IkiWiki/Plugin/blogspam.pm:112
+#: ../IkiWiki/Plugin/blogspam.pm:118
msgid ""
"Sorry, but that looks like spam to <a href=\"http://blogspam.net/"
"\">blogspam</a>: "
msgid "Comment Moderation"
msgstr ""
-#: ../IkiWiki/Plugin/comments.pm:372 ../IkiWiki/Plugin/editpage.pm:96
+#: ../IkiWiki/Plugin/comments.pm:372 ../IkiWiki/Plugin/editpage.pm:95
+#: ../IkiWiki/Plugin/editpage.pm:101
msgid "bad page name"
msgstr ""
msgid "removing old preview %s"
msgstr ""
-#: ../IkiWiki/Plugin/editpage.pm:114
+#: ../IkiWiki/Plugin/editpage.pm:117
#, perl-format
msgid "%s is not an editable page"
msgstr ""
-#: ../IkiWiki/Plugin/editpage.pm:294
+#: ../IkiWiki/Plugin/editpage.pm:297
#, perl-format
msgid "creating %s"
msgstr ""
-#: ../IkiWiki/Plugin/editpage.pm:312 ../IkiWiki/Plugin/editpage.pm:331
-#: ../IkiWiki/Plugin/editpage.pm:342 ../IkiWiki/Plugin/editpage.pm:387
-#: ../IkiWiki/Plugin/editpage.pm:429
+#: ../IkiWiki/Plugin/editpage.pm:315 ../IkiWiki/Plugin/editpage.pm:334
+#: ../IkiWiki/Plugin/editpage.pm:345 ../IkiWiki/Plugin/editpage.pm:390
+#: ../IkiWiki/Plugin/editpage.pm:432
#, perl-format
msgid "editing %s"
msgstr ""
msgid "warning: Old po4a detected! Recommend upgrade to 0.35."
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:175
+#: ../IkiWiki/Plugin/po.pm:176
#, perl-format
msgid "%s is not a valid language code"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:187
+#: ../IkiWiki/Plugin/po.pm:188
#, perl-format
msgid ""
"%s is not a valid value for po_link_to, falling back to po_link_to=default"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:192
+#: ../IkiWiki/Plugin/po.pm:193
msgid ""
"po_link_to=negotiated requires usedirs to be enabled, falling back to "
"po_link_to=default"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:456
+#: ../IkiWiki/Plugin/po.pm:457
msgid "updated PO files"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:479
+#: ../IkiWiki/Plugin/po.pm:480
msgid ""
"Can not remove a translation. If the master page is removed, however, its "
"translations will be removed as well."
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:499
+#: ../IkiWiki/Plugin/po.pm:500
msgid ""
"Can not rename a translation. If the master page is renamed, however, its "
"translations will be renamed as well."
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:941
+#: ../IkiWiki/Plugin/po.pm:942
#, perl-format
msgid "POT file (%s) does not exist"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:955
+#: ../IkiWiki/Plugin/po.pm:956
#, perl-format
msgid "failed to copy underlay PO file to %s"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:964
+#: ../IkiWiki/Plugin/po.pm:965
#, perl-format
msgid "failed to update %s"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:970
+#: ../IkiWiki/Plugin/po.pm:971
#, perl-format
msgid "failed to copy the POT file to %s"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:1006
+#: ../IkiWiki/Plugin/po.pm:1007
msgid "N/A"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:1017
+#: ../IkiWiki/Plugin/po.pm:1018
#, perl-format
msgid "failed to translate %s"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:1096
+#: ../IkiWiki/Plugin/po.pm:1097
msgid "removed obsolete PO files"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:1153 ../IkiWiki/Plugin/po.pm:1165
-#: ../IkiWiki/Plugin/po.pm:1204
+#: ../IkiWiki/Plugin/po.pm:1154 ../IkiWiki/Plugin/po.pm:1166
+#: ../IkiWiki/Plugin/po.pm:1205
#, perl-format
msgid "failed to write %s"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:1163
+#: ../IkiWiki/Plugin/po.pm:1164
msgid "failed to translate"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:1216
+#: ../IkiWiki/Plugin/po.pm:1217
msgid "invalid gettext data, go back to previous page to continue edit"
msgstr ""
-#: ../IkiWiki/Plugin/po.pm:1258
+#: ../IkiWiki/Plugin/po.pm:1259
#, perl-format
msgid "%s has invalid syntax: must use CODE|NAME"
msgstr ""
use warnings;
use strict;
-use Test::More tests => 21;
+use Test::More tests => 22;
BEGIN { use_ok("IkiWiki"); }
BEGIN { use_ok("IkiWiki::Render"); }
is($autofiles{"tags/lucky.mdwn"}{plugin}, "tag");
is($autofiles{"tags/numbers.mdwn"}{plugin}, "tag");
is($autofiles{"tags/primes.mdwn"}{plugin}, "tag");
+is_deeply([sort keys %autofiles], [qw(tags/lucky.mdwn tags/numbers.mdwn tags/primes.mdwn)]);
ok(!-e "t/tmp/tags/lucky.mdwn");
my (%pages, @del);
IkiWiki::gen_autofile("tags/lucky.mdwn", \%pages, \@del);
-is_deeply(\%pages, {"t/tmp/tags/lucky" => 1}) || diag explain \%pages;
-is_deeply(\@del, []) || diag explain \@del;
+is_deeply(\%pages, {"t/tmp/tags/lucky" => 1});
+is_deeply(\@del, []);
ok(-s "t/tmp/tags/lucky.mdwn");
# generating an autofile that already exists does nothing
%pages = @del = ();
IkiWiki::gen_autofile("tags/numbers.mdwn", \%pages, \@del);
-is_deeply(\%pages, {}) || diag explain \%pages;
-is_deeply(\@del, []) || diag explain \@del;
+is_deeply(\%pages, {});
+is_deeply(\@del, []);
# generating an autofile that we just deleted does nothing
%pages = ();
@del = ('tags/primes.mdwn');
IkiWiki::gen_autofile("tags/primes.mdwn", \%pages, \@del);
-is_deeply(\%pages, {}) || diag explain \%pages;
-is_deeply(\@del, ['tags/primes.mdwn']) || diag explain \@del;
+is_deeply(\%pages, {});
+is_deeply(\@del, ['tags/primes.mdwn']);
+
+
+# cleanup
+ok(! system("rm -rf t/tmp"));
1;
projects / ikiwiki.git / commitdiff