sub openiduser ($) {
my $user=shift;
- if ($user =~ m!^https?://! &&
+ if (defined $user && $user =~ m!^https?://! &&
eval q{use Net::OpenID::VerifiedIdentity; 1} && !$@) {
my $display;
return $conflict if defined $conflict;
}
- rcs_add($params{file});
- return rcs_commit_staged(
- message => $params{message},
- session => $params{session},
- );
+ return rcs_commit_helper(@_);
}
sub rcs_commit_staged (@) {
# Commits all staged changes. Changes can be staged using rcs_add,
# rcs_remove, and rcs_rename.
+ return rcs_commit_helper(@_);
+}
+
+sub rcs_commit_helper (@) {
my %params=@_;
my %env=%ENV;
$params{message}.=".";
}
}
- push @opts, '-q';
- # git commit returns non-zero if file has not been really changed.
- # so we should ignore its exit status (hence run_or_non).
- if (run_or_non('git', 'commit', @opts, '-m', $params{message})) {
+ if (exists $params{file}) {
+ push @opts, '--', $params{file};
+ }
+ # git commit returns non-zero if nothing really changed.
+ # So we should ignore its exit status (hence run_or_non).
+ if (run_or_non('git', 'commit', '-m', $params{message}, '-q', @opts)) {
if (length $config{gitorigin_branch}) {
run_or_cry('git', 'push', $config{gitorigin_branch});
}
eval q{use File::Temp};
die $@ if $@;
my $fh;
- ($fh, $path)=File::Temp::tempfile("XXXXXXXXXX", UNLINK => 1);
+ ($fh, $path)=File::Temp::tempfile(undef, UNLINK => 1);
my $cmd = "cd $git_dir && ".
"git show $detail->{sha1_to} > '$path'";
if (system($cmd) != 0) {
eval { writefile($file, $config{srcdir}, $content) };
next if $@;
my $conflict=IkiWiki::rcs_commit(
- $file,
- sprintf(gettext("update for rename of %s to %s"), $rename->{srcfile}, $rename->{destfile}),
- $token,
- $session->param("name"),
- $session->remote_addr(),
+ file => $file,
+ message => sprintf(gettext("update for rename of %s to %s"), $rename->{srcfile}, $rename->{destfile}),
+ token => $token,
+ session => $session,
);
push @fixedlinks, $page if ! defined $conflict;
}
-ikiwiki (3.20101113) UNRELEASED; urgency=low
+ikiwiki (3.20101129) unstable; urgency=low
* websetup: Fix encoding problem when restoring old setup file.
* more: Add pages parameter to limit where the more is displayed.
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.
- -- Joey Hess <joeyh@debian.org> Tue, 16 Nov 2010 14:23:47 -0400
+ -- Joey Hess <joeyh@debian.org> Mon, 29 Nov 2010 13:59:10 -0400
ikiwiki (3.20101112) unstable; urgency=HIGH
--- /dev/null
+At least at http://free-thursday.pieni.net/ikiwiki.cgi the "SSH keys" page shows only the first 139 characters of each SSH key. I'm using iceweasel in 1024x768 resolution and there are not scrollbars visible.
+
+Please contact me at timo.lindfors@iki.fi
+
+> I have access to the same wiki, and do not see the problem Timo sees. I see 380 chars of the SSH keys, and do have a scrollbar.
+> Weird. --liw
+
+> Also, that's a Branchable.com site and the bug, if any is
+> in ikiwiki-hosting's plugin, not ikiwiki proper. Moved
+> [here](http://ikiwiki-hosting.branchable.com/bugs/__34__Currently_enabled_SSH_keys:__34___shows_only_first_139_characters_of_each_key/) --[[Joey]]
+
+[[!tag done]]
--- /dev/null
+Commit 3650d0265bc501219bc6d5cd4fa91a6b6ecd793a seems to have been caused by
+a bug in ikiwiki. recentchanges/* was added to the git repo incorrectly.
+
+Part of the problem seems to be that git's `rcs_commit` does a git add followed
+by a `rcs_commit_staged`, and so calling `rcs_commit` on files that were
+not checked in before adds them, incorrectly.
+
+I'm unsure yet why the recentchanges files were being committed. Possibly
+because of the link fixup code run when renaming a page. --[[Joey]]
+
+> See also [[bugs/rename fixup not attributed to author]]. --[[smcv]]
+
+> Ok, there was a call to `rcs_commit` that was still using non-named
+> parameters, which confused it thuroughly, and I think caused
+> 'git add .' to be called. I've fixed that.
+>
+> I think there is still potential for the problem I described above to
+> occur during a rename or possibly otherwise. Ok.. fixed `rcs_commit`
+> to not add too. [[done]] --[[Joey]]
--- /dev/null
+When I renamed `todo/transient_in-memory_pages` to [[todo/transient pages]],
+`rename::fixlinks` was meant to blame me for the link-fixing commit, and title it
+`update for rename of %s to %s`. Instead, it blamed Joey for the commit,
+and didn't set a commit message.
+
+(It also committed a pile of recentchanges pages which shouldn't have
+been committed, for which see [[bugs/git_commit_adds_files_that_were_not_tracked]].)
+
+--[[smcv]]
+
+> It was calling `rcs_commit` old-style, and so not passing the session
+> object that is used to get the user's name. [[fixed|done]] --[[Joey]]
--- /dev/null
+When I originally looked at the "exclude" option, I thought it meant that it excluded pages completely, but it apparently doesn't. What I've found in practice is that a file which matches the "exclude" regex is excluded from *processing*, but it is still copied over to the destination directory. Thus, for example, if I have "^Makefile$" as the exclude pattern, and I have a file `src/foo/Makefile`, then that file is copied unaltered into `dest/foo/Makefile`. However, what I want is for `src/foo/Makefile` to be completely ignored: that it is not only not processed, but not even *copied* into the destination directory.
+
+I'm not sure if the current behaviour is a bug or a feature, but I would like a "totally ignore this file" feature if it's possible to have one.
+
+-- [[KathrynAndersen]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://smcv.pseudorandom.co.uk/"
+ nickname="smcv"
+ subject="expression anchored too closely?"
+ date="2010-11-23T10:43:21Z"
+ content="""
+It looks as though you might only be excluding a top-level Makefile, and not a Makefile in subdirectories. Try excluding `(^|/)Makefile$` instead, for instance? (See `wiki_file_prune_regexps` in `IkiWiki.pm` for hints.)
+
+The match operation in `&file_pruned` ends up a bit like this:
+
+ \"foo/Makefile\" =~ m{…|…|…|(^|/)Makefile$}
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://kerravonsen.dreamwidth.org/"
+ ip="60.241.8.244"
+ subject="Missed It By That Much"
+ date="2010-11-25T02:55:20Z"
+ content="""
+I discovered that I not only needed to change the regexp, but I also needed to delete .ikiwiki/indexdb because `file_pruned` only gets called for files that aren't in the `%pagesources` hash, and since the file in question was already there because it had been put there before the exclude regex was changed, it wasn't even being checked!
+
+[[KathrynAndersen]]
+
+"""]]
--- /dev/null
+[[!comment format=mdwn
+ username="http://kerravonsen.dreamwidth.org/"
+ ip="60.241.8.244"
+ subject="Limitations"
+ date="2010-11-23T02:18:52Z"
+ content="""
+I'd already had a look at this idea before you posted this suggestion, and I ran into difficulties.
+So far as I can see, it makes most sense to use the mechanisms already in place for editing pages, and enhance them.
+Unfortunately, the whole edit-page setup expects a template file (by default, when editing pages, editpage.tmpl)
+and anything apart from \"submit\" buttons must have a placeholder in the template file, or it doesn't get displayed at all in the form.
+At least, that's what I've found - I could be mistaken.
+
+But if it's true, that rather puts the kybosh on dynamically generated forms, so far as I can see.
+I mean, if you knew beforehand what all your fields were going to be, you could make a copy of editpage.tmpl, add in your fields where you want, and then make a plugin that uses that template instead of editpage.tmpl, but that's very limited.
+
+If someone could come up with a way of making dynamic forms, that would solve the problem, but I've come up against a brick wall myself. Joey? Anyone?
+
+-- [[KathrynAndersen]]
+"""]]
+++ /dev/null
-ikiwiki 3.20100915 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * needsbuild hook interface changed; the hooks should now return
- the modified array of things that need built. (Backwards compatibility
- code keeps plugins using the old interface working.)
- * Remove PATH overriding code in ikiwiki script that was present to make
- perl taint checking happy, but taint checking is disabled.
- * teximg: Use Unicode UTF-8 encoding by default. Closes: #[596067](http://bugs.debian.org/596067)
- Thanks, Paul Menzel.
- * po: Make the po\_master\_language use a langpair like "en|English",
- so it can be configured via the web.
- * po: Allow enabling via web setup.
- * po: Auto-upgrade old format settings to new formats when writing
- setup file.
- * Pass array of names of files that have been deleted to needsbuild hook
- as second parameter, to allow for plugins that needs access to this
- information earlier than the delete hook.
- * actiontabs: Improve tab padding.
- * blueview: Fix display of links to translated pages in the page header.
- * Set isPermaLink="no" for guids in rss feeds.
- * blogspam: Fix crash when content contained utf-8.
- * external: Disable RPC::XML's "smart" encoding, which sent ints
- for strings that contained only a number, fixing a longstanding crash
- of the rst plugin.
- * git: When updating from remote, use git pull --prune, to avoid possible
- errors from conflicting obsolete remote branches.
- * cutpaste: Fix bug that occured in some cases involving inlines when
- text was pasted on a page before being cut."""]]
\ No newline at end of file
--- /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
> writing them out, as [[JoeRayhawk]] suggests below? I think
> add_autofile would be the way to do this.
> I've added this to [[todo]] as [[todo/autoindex should use add__95__autofile]]
-> and [[todo/transient in-memory pages]]. --[[smcv]]
+> and [[todo/transient_pages]]. --[[smcv]]
The reason being that I have a lot of directories which need to be autoindexed,
but I would prefer if the index files didn't clutter up my git repository.
by writing to the RCS as the page's contents can change depending on which
other pages claim it as an alias. --[[chrysn]]
-I agree with [[chrysn]]. In fact, is there any good reason that the core tag plugin doesn't do this? The current usability is horrible, to the point that I have gone 2.5 years with Ikiwiki and haven't yet started using tags. -- [[Eric|http://wiki.pdxhub.org/people/eric]]
+I agree with [[chrysn]]. In fact, is there any good reason that the core tag plugin doesn't do this? The current usability is horrible, to the point that I have gone 2.5 years with Ikiwiki and haven't yet started using tags. --
-> See [[todo/transient in-memory pages]] for progress on this. --[[smcv]]
+> See [[todo/transient_pages]] for progress on this. --[[smcv]]
[[!tag done]]
`add_autofile` is a generic version of [[plugins/autoindex]]'s code,
so the latter should probably use the former. --[[smcv]]
-> See [[todo/transient in-memory pages]] for progress on this. --[[smcv]]
+> See [[todo/transient_pages]] for progress on this. --[[smcv]]
+++ /dev/null
-On [[todo/auto-create_tag_pages_according_to_a_template]], [[chrysn]]
-suggests:
-
-> Instead of creating a file that gets checked in into the RCS, the
-> source files could be left out and the output files be written as
-> long as there is no physical source file (think of a virtual underlay).
-> Something similar would be required to implement alias directive,
-> which couldn't be easily done by writing to the RCS as the page's
-> contents can change depending on which other pages claim it as an alias.
-
-`add_autofile` could be adapted to do this, or a similar API could be
-added.
-
-This would also be useful for autoindex, as suggested on
-[[plugins/autoindex/discussion]]. I'd also like to use it for
-[[plugins/contrib/album]].
-
-One refinement I'd suggest is that if the transient page is edited,
-its transient contents are evaluated and used as the initial
-content for the edit box; after that, it'd become a static page. --[[smcv]]
-
---------------------------
-
-[[!template id=gitbranch branch=smcv/transient author="[[smcv]]"]]
-[[!tag patch]]
-
-I had a look at implementing this. It turns out to be harder than I thought
-to have purely in-memory pages (several plugins want to be able to access the
-source file as a file), but I did get this proof-of-concept branch
-to write tag and autoindex pages into an underlay.
-
-This loses the ability to delete the auto-created pages (although they don't
-clutter up git this way, at least), and a lot of the code in autoindex is
-probably now redundant, so this is probably not quite ready for merge, but
-I'd welcome opinions.
-
-Usage: set `tag_underlay` and/or `autoindex_underlay` to an absolute path,
-which you must create beforehand. I suggest *srcdir* + `/.ikiwiki/transient`.
-
-Refinements that could be made if this approach seems reasonable:
-
-* make these options boolean, and have the path always be `.ikiwiki/transient`
-* improve the `remove` plugin so it also deletes from this special underlay
-
->> Perhaps it should be something more generic, so that other plugins could use it (such as "album" mentioned above).
->> The `.ikiwiki/transient` would suit this, but instead of saying "tag_underlay" or "autoindex_underlay" have "use_transient_underlay" or something like that?
->> Or to make it more flexible, have just one option "transient_underlay" which is set to an absolute path, and if it is set, then one is using a transient-underlay.
->> --[[KathrynAndersen]]
-
->>> What I had in mind was more like `tag_autocreate_transient => 1` or
->>> `autoindex_transient => 1`; you might conceivably want tags to be
->>> checked in but autoindices to be transient, and it's fine for each
->>> plugin to make its own decision. Going from that to one boolean
->>> (or just always-transient if people don't think that's too
->>> astonishing) would be trivial, though.
->>>
->>> I don't think relocating the transient underlay really makes sense,
->>> except for prototyping: you only want one, and `.ikiwiki` is as good
->>> a place as any (ikiwiki already needs to be able to write there).
->>>
->>> For [[plugins/contrib/album]] I think I'd just make the photo viewer
->>> pages always-transient - you can always make a transient page
->>> permanent by editing it, after all.
->>>
->>> Do you think this approach has enough potential that I should
->>> continue to hack on it? Any thoughts on the implementation? --[[smcv]]
-
->>>> Ah, now I understand what you're getting at. Yes, it makes sense to put transient pages under `.ikiwiki`.
->>>> I haven't looked at the code, but I'd be interested in seeing whether it's generic enough to be used by other plugins (such as `album`) without too much fuss.
->>>> The idea of a transient underlay gives us a desirable feature for free: that if someone edits the transient page, it is made permanent and added to the repository.
->>>>
->>>> I think the tricky thing with removing these transient underlay pages is the question of how to prevent whatever auto-generated the pages in the first place from generating them again - or, conversely, how to force whatever auto-generated those pages to regenerate them if you've changed your mind.
->>>> I think you'd need something similar to `will_render` so that transient pages would be automatically removed if whatever auto-generated them is no longer around.
->>>> -- [[KathrynAndersen]]
--- /dev/null
+On [[todo/auto-create_tag_pages_according_to_a_template]], [[chrysn]]
+suggests:
+
+> Instead of creating a file that gets checked in into the RCS, the
+> source files could be left out and the output files be written as
+> long as there is no physical source file (think of a virtual underlay).
+> Something similar would be required to implement alias directive,
+> which couldn't be easily done by writing to the RCS as the page's
+> contents can change depending on which other pages claim it as an alias.
+
+`add_autofile` could be adapted to do this, or a similar API could be
+added.
+
+This would also be useful for autoindex, as suggested on
+[[plugins/autoindex/discussion]]. I'd also like to use it for
+[[plugins/contrib/album]].
+
+One refinement I'd suggest is that if the transient page is edited,
+its transient contents are evaluated and used as the initial
+content for the edit box; after that, it'd become a static page. --[[smcv]]
+
+--------------------------
+
+[[!template id=gitbranch branch=smcv/transient author="[[smcv]]"]]
+[[!tag patch]]
+
+I had a look at implementing this. It turns out to be harder than I thought
+to have purely in-memory pages (several plugins want to be able to access the
+source file as a file), but I did get this proof-of-concept branch
+to write tag and autoindex pages into an underlay.
+
+This loses the ability to delete the auto-created pages (although they don't
+clutter up git this way, at least), and a lot of the code in autoindex is
+probably now redundant, so this is probably not quite ready for merge, but
+I'd welcome opinions.
+
+Usage: set `tag_underlay` and/or `autoindex_underlay` to an absolute path,
+which you must create beforehand. I suggest *srcdir* + `/.ikiwiki/transient`.
+
+Refinements that could be made if this approach seems reasonable:
+
+* make these options boolean, and have the path always be `.ikiwiki/transient`
+* improve the `remove` plugin so it also deletes from this special underlay
+
+>> Perhaps it should be something more generic, so that other plugins could use it (such as "album" mentioned above).
+>> The `.ikiwiki/transient` would suit this, but instead of saying "tag_underlay" or "autoindex_underlay" have "use_transient_underlay" or something like that?
+>> Or to make it more flexible, have just one option "transient_underlay" which is set to an absolute path, and if it is set, then one is using a transient-underlay.
+>> --[[KathrynAndersen]]
+
+>>> What I had in mind was more like `tag_autocreate_transient => 1` or
+>>> `autoindex_transient => 1`; you might conceivably want tags to be
+>>> checked in but autoindices to be transient, and it's fine for each
+>>> plugin to make its own decision. Going from that to one boolean
+>>> (or just always-transient if people don't think that's too
+>>> astonishing) would be trivial, though.
+>>>
+>>> I don't think relocating the transient underlay really makes sense,
+>>> except for prototyping: you only want one, and `.ikiwiki` is as good
+>>> a place as any (ikiwiki already needs to be able to write there).
+>>>
+>>> For [[plugins/contrib/album]] I think I'd just make the photo viewer
+>>> pages always-transient - you can always make a transient page
+>>> permanent by editing it, after all.
+>>>
+>>> Do you think this approach has enough potential that I should
+>>> continue to hack on it? Any thoughts on the implementation? --[[smcv]]
+
+>>>> Ah, now I understand what you're getting at. Yes, it makes sense to put transient pages under `.ikiwiki`.
+>>>> I haven't looked at the code, but I'd be interested in seeing whether it's generic enough to be used by other plugins (such as `album`) without too much fuss.
+>>>> The idea of a transient underlay gives us a desirable feature for free: that if someone edits the transient page, it is made permanent and added to the repository.
+>>>>
+>>>> I think the tricky thing with removing these transient underlay pages is the question of how to prevent whatever auto-generated the pages in the first place from generating them again - or, conversely, how to force whatever auto-generated those pages to regenerate them if you've changed your mind.
+>>>> I think you'd need something similar to `will_render` so that transient pages would be automatically removed if whatever auto-generated them is no longer around.
+>>>> -- [[KathrynAndersen]]
--- /dev/null
+[[!template id=gitbranch branch=smcv/ready/sslcookie-auto author="[[smcv]]"]]
+[[!tag patch]]
+
+At the moment `sslcookie => 0` never creates secure cookies, so if you log in
+with SSL, your browser will send the session cookie even over plain HTTP.
+Meanwhile `sslcookie => 1` always creates secure cookies, so you can't
+usefully log in over plain http.
+
+This branch adds `sslcookie => 0, sslcookie_auto => 1` as an option; this
+uses the `HTTPS` environment variable, so if you log in over SSL you'll
+get a secure session cookie, but if you log in over HTTP, you won't.
+(The syntax for the setup file is pretty rubbish - any other suggestions?)
+
+> Does this need to be a configurable option at all? The behavior could
+> just be changed in the sslcookie = 0 case. It seems sorta reasonable
+> that, once I've logged in via https, I need to re-login if I then
+> switch to http.
+>
+> And, if your change is made, the sslcookie option could probably itself
+> be dropped too -- at least I don't see a real use case for it if ikiwiki
+> is more paranoid about cookies by default.
+>
+> Might be best to fix
+> [[todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both]]
+> first, so that dual https/http sites can better be set up. --[[Joey]]
scheme. In theory you could use things like `//static.example.com/wiki/`
and `//dynamic.example.com/ikiwiki.cgi` to preserve choice of http/https
while switching server, but I don't know how consistently browsers
-suppot that.
+support that.
"local" here is short for "locally valid", because these URLs are neither
fully relative nor fully absolute, and there doesn't seem to be a good name
for them...
-I've tested this on a demo website with the CGI enabled, and it seems to
+I've tested this on a demo website with the CGI enabled, and it seemed to
work nicely (there might be bugs in some plugins, I didn't try all of them).
+The branch at [[todo/use secure cookies for SSL logins]] goes well with
+this one.
+
The `$config{url}` and `$config{cgiurl}` are both HTTP, but if I enable
`httpauth`, set `cgiauthurl` to a HTTPS version of the same site and log
in via that, links all end up in the HTTPS version.
>>
>>> That makes a great deal of sense, bravo for actually removing
>>> parameters in the common case while maintaining backwards
- >>> compatability!
+ >>> compatability! --[[Joey]]
+ >>>
+ >>>> Done in my `localurl` branch; not tested in a whole-wiki way
+ >>>> yet, but I did add a regression test. I've used
+ >>>> `urlto(x, undef)` rather than `urlto(x)` so far, but I could
+ >>>> go back through the codebase using the short form if you'd
+ >>>> prefer. --[[smcv]]
>>>
>>> It does highlight that it would be better to have a
>>> `absolute_urlto($link)` (or maybe `absolute(urlto($link))` )
>>> rather than the 3 parameter form. --[[Joey]]
+ >>>
+ >>> Possibly. I haven't added this.
* `IkiWiki::baseurl` has a new second argument which works like the
third argument of `urlto`
>> (But I assume changes to `urlto` will follow through here anyway.)
>> --[[Joey]]
+ >>> I had to use it a bit more, as a replacement for `$config{url}`
+ >>> when doing things like referencing stylesheets or redirecting to
+ >>> the top of the wiki.
+ >>>
+ >>> I ended up redoing this without the extra parameter. Previously,
+ >>> `baseurl(undef)` was the absolute URL; now, `baseurl(undef)` is
+ >>> the local path. I know you objected to me using `baseurl()` in
+ >>> an earlier branch, because `baseurl().$x` looks confusingly
+ >>> similar to `baseurl($x)` but has totally different semantics;
+ >>> I've generally written it `baseurl(undef)` now, to be more
+ >>> explicit. --[[smcv]]
+
* `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1`
- > Possibly changed to making this always be local unless `cgiurl => $x`
- > is given: see below --[[smcv]]
+ > Now changed to always use the `$local_cgiurl`. --[[smcv]]
* `IkiWiki::cgiurl` omits the trailing `?` if given no named parameters
except `cgiurl` and/or `local_cgiurl`
> I assume you have no objection to this --[[smcv]]
>
- >> Nod, although I don't know of a use case. --[[Joey]]
+ >> Nod, although I don't know of a use case. --[[Joey]]
+
+ >>> The use-case is that I can replace `$config{cgiurl}` with
+ >>> `IkiWiki::cgiurl()` for things like the action attribute of
+ >>> forms. --[[smcv]]
-Bugs:
+Fixed bugs:
* I don't think anything except `openid` calls `cgiurl` without also
passing in `local_cgiurl => 1`, so perhaps that should be the default;
>>> if `absolute()` were implemented as suggested above, it could also
>>> be used with cgiurl if necessary.) --[[Joey]]
+ >>>> Done (minus `absolute()`). --[[smcv]]
+
+Potential future things:
+
* It occurs to me that `IkiWiki::cgiurl` could probably benefit from being
exported? Perhaps also `IkiWiki::baseurl`?
> AFACIS, `baseurl` is only called in 3 places so I don't think that's
> needed. --[[Joey]]
- >> OK, wontfix. --[[smcv]]
+ >> OK, wontfix. For what it's worth, my branch has 6 uses in IkiWiki
+ >> core code (IkiWiki, CGI, Render and the pseudo-core part of editpage)
+ >> and 5 in plugins, since I used it for things like redirection back
+ >> to the top of the wiki --[[smcv]]
Name: ikiwiki
-Version: 3.20101112
+Version: 3.20101129
Release: 1%{?dist}
Summary: A wiki compiler
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2010-11-12 00:37-0400\n"
+"POT-Creation-Date: 2010-11-29 14:01-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 "creating new page %s"
msgstr ""
-#: ../IkiWiki/Plugin/aggregate.pm:652 ../IkiWiki/Plugin/edittemplate.pm:133
+#: ../IkiWiki/Plugin/aggregate.pm:652 ../IkiWiki/Plugin/edittemplate.pm:135
msgid "failed to process template:"
msgstr ""
msgid "%s is an attachment, not a page."
msgstr ""
-#: ../IkiWiki/Plugin/git.pm:764 ../IkiWiki/Plugin/git.pm:827
+#: ../IkiWiki/Plugin/git.pm:766 ../IkiWiki/Plugin/git.pm:829
#: ../IkiWiki.pm:1580
#, perl-format
msgid "you are not allowed to change %s"
msgstr ""
-#: ../IkiWiki/Plugin/git.pm:786
+#: ../IkiWiki/Plugin/git.pm:788
#, perl-format
msgid "you cannot act on a file with mode %s"
msgstr ""
-#: ../IkiWiki/Plugin/git.pm:790
+#: ../IkiWiki/Plugin/git.pm:792
msgid "you are not allowed to change file modes"
msgstr ""
-#: ../IkiWiki/Plugin/git.pm:861
+#: ../IkiWiki/Plugin/git.pm:863
msgid "you are not allowed to revert a merge"
msgstr ""
-#: ../IkiWiki/Plugin/git.pm:877
+#: ../IkiWiki/Plugin/git.pm:879
#, perl-format
msgid "Failed to revert commit %s"
msgstr ""
msgid "Source code: %s"
msgstr ""
-#: ../IkiWiki/Plugin/highlight.pm:140
+#: ../IkiWiki/Plugin/highlight.pm:155
msgid ""
"warning: highlight perl module not available; falling back to pass through"
msgstr ""
msgid "failed to process template %s"
msgstr ""
-#: ../IkiWiki/Plugin/inline.pm:630
+#: ../IkiWiki/Plugin/inline.pm:663
msgid "RPC::XML::Client not found, not pinging"
msgstr ""