Merge commit 'upstream/master' into pub/po

9 files changed, 130 insertions, 45 deletions

diff --git a/debian/changelog b/debian/changelog
index c684565c5..4e1aa8545 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -18,6 +18,8 @@ ikiwiki (3.13) UNRELEASED; urgency=low
   * Allow curly braces to be used in pagespecs, and avoid a whole class
     of potential security problems, by avoiding performing any string
     interpolation on user-supplied data when translating pagespecs.
+  * ikiwiki-transition: Allow setup files to be passed to all subcommands
+    that need a srcdir.
 
  -- Joey Hess <joeyh@debian.org>  Wed, 06 May 2009 20:45:44 -0400
 
diff --git a/doc/bugs/Insecure_dependency_in_mkdir.mdwn b/doc/bugs/Insecure_dependency_in_mkdir.mdwn
index 28304b3d3..5410ebbfd 100644
--- a/doc/bugs/Insecure_dependency_in_mkdir.mdwn
+++ b/doc/bugs/Insecure_dependency_in_mkdir.mdwn
@@ -127,3 +127,27 @@ dubious
 </pre>
 
 >>>> I get this over and over... I haven't touched that AFAICT, at all. --[[simonraven]]
+
+>>>>> Take a look at your `/usr/bin/ikiwiki`. The first
+>>>>> line should not contain -T. If it does, remove it,
+>>>>> and maybe try to work out or give details about how
+>>>>> you installed ikiwiki and why it got the -T in there,
+>>>>> which certianly doesn't happen by default when ikiwiki
+>>>>> is installed by the Makefile.PL or by any package I know of.
+>>>>> (If there's
+>>>>> no -T, then something *really* weird is going on..)
+>>>>> --[[Joey]] 
+
+>>>>>> nope, no -T in the hashbang line at all. Haven't added any;
+>>>>>> only thing I did there was change `use lib` to `/usr/share/perl5`,
+>>>>>> otherwise I'd get bogus errors about CGI::Cookie_al or some such thing.
+>>>>>>
+>>>>>> How I installed it was in non-public directories in various sites, then
+>>>>>> make it publish stuff to a public dir in the relevant site. Or do you
+>>>>>> mean installed, as in the whole thing? From a .deb I made based on the git tree, with `git-buildpackage`.
+>>>>>>
+>>>>>> This issue is recent, after a `git pull` IIRC. It has never happened before. It's also puzzling me.
+>>>>>>
+>>>>>> You can check it out for yourself by pulling my fork of this, at github or my local repo.
+>>>>>> github will probably be faster for you: git://github.com/kjikaqawej/ikiwiki-simon.git --[[simonraven]]
+
diff --git a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
index c54376aa1..042d6a20c 100644
--- a/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
+++ b/doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
@@ -272,3 +272,8 @@ So, looking at your meta branch: --[[Joey]]
 >>> it in a way that leaves room for #2.
 >>> 
 >>> --[[intrigeri]]
+>>>
+>>>> I agree, we should concentrate on getting just enough functionality
+>>>> for the po plugin, because I want to merge the po plugin soon.
+>>>> If #2 gets tackled later, we will certianly have all kinds of fun.
+>>>> no matter what is done for the po plugin. --[[Joey]] 
diff --git a/doc/ikiwiki-transition.mdwn b/doc/ikiwiki-transition.mdwn
index e0b853ecf..6177f5a46 100644
--- a/doc/ikiwiki-transition.mdwn
+++ b/doc/ikiwiki-transition.mdwn
@@ -44,14 +44,14 @@ Moves values that used to be admin preferences into the setup file.
 Note that all comments and any unusual stuff like perl code in the setup
 file will be lost, as it is entirely rewritten by the move.
 
-# indexdb srcdir
+# indexdb your.setup|srcdir
 
 The `indexdb` mode handles converting a plain text `.ikiwiki/index` file to
 a binary `.ikiwiki/indexdb`. You do not normally need to run
 `ikiwiki-transition indexdb`; ikiwiki will automatically run it as
 necessary.
 
-# hashpassword srcdir
+# hashpassword your.setup|srcdir
 
 The `hashpassword` mode forces any plaintext passwords stored in the
 `.ikiwiki/userdb` file to be replaced with password hashes. (The
@@ -61,7 +61,7 @@ If this is not done explicitly, a user's plaintext password will be
 automatically converted to a hash when a user logs in for the first time
 after upgrade to ikiwiki 2.48.
 
-# deduplinks srcdir
+# deduplinks your.setup|srcdir
 
 In the past, bugs in ikiwiki have allowed duplicate link information
 to be stored in its indexdb. This mode removes such duplicate information,
diff --git a/doc/plugins/contrib/po.mdwn b/doc/plugins/contrib/po.mdwn
index 13176aac4..5b33f6716 100644
--- a/doc/plugins/contrib/po.mdwn
+++ b/doc/plugins/contrib/po.mdwn
@@ -372,6 +372,18 @@ daring a timid "please pull"... or rather, please review again :)
 >> should appear on the current page. That's why I'm testing
 >> `$template->param('discussionlink')`.
 >> 
+>>> Maybe I was really wondering why it says it could lead to a broken
+>>> link if the cgiurl is disabled. I think I see why now: Discussionlink
+>>> will be set to a link to an existing disucssion page, even if cgi is
+>>> disabled -- but there's no guarantee of a translated discussion page
+>>> existing in that case. *However*, htmllink actually checks
+>>> for this case, and will avoid generating a broken link so AFAICS, the
+>>> comment is actually innacurate.. what will really happen in this case
+>>> is discussionlink will be set to a non-link translation of
+>>> "discussion". Also, I consider `$config{cgi}` and `%links` (etc)
+>>> documented parts of the plugin interface, which won't change; po could
+>>> rely on them to avoid this minor problem. --[[Joey]] 
+>
 > * Is there any real reason not to allow removing a translation?
 >   I'm imagining a spammy translation, which an admin might not
 >   be able to fix, but could remove.
@@ -383,6 +395,11 @@ daring a timid "please pull"... or rather, please review again :)
 >> delete the spammy `.po` file by hand using whatever VCS is in use.
 >> Not that I'd really care, but I am slightly in favour of the way
 >> it currently works.
+>>
+>>> That would definitly be confusing. It sounds to me like if we end up
+>>> needing to allow web-based deletion of spammy translations, it will
+>>> need improvements to the deletion UI to de-confuse that. It's fine to
+>>> put that off until needed --[[Joey]] 
 >> 
 > * Re the meta title escaping issue worked around by `change`. 
 >   I suppose this does not only affect meta, but other things
@@ -404,3 +421,5 @@ daring a timid "please pull"... or rather, please review again :)
 >> I'll think about it soon.
 >> 
 >> --[[intrigeri]]
+>>
+>>> Did you get a chance to? --[[Joey]] 
diff --git a/doc/todo/inlines_inheriting_links.mdwn b/doc/todo/inlines_inheriting_links.mdwn
index 12531990c..c53da51c5 100644
--- a/doc/todo/inlines_inheriting_links.mdwn
+++ b/doc/todo/inlines_inheriting_links.mdwn
@@ -18,3 +18,22 @@ This is not just an ugly workaround. The availability of this feature has some r
 So in a sense, in some or most cases, it would indeed be cleaner to "store" the definition of a class of pages referred to in complex pagespecs as a separate object. And the most natural representation for this definition of a class of pages (adhering to the principle of wiki that what you mean is entered/stored in its most natural representation, not through some hidden disconnected code) is making a page with an inline/map/or the like, so that at the same time you store the definition and you see what it is (the set of pages is displayed to you).
 
 I would actually use it in my current "project" in ikiwiki: I actually edit a set of materials as a set of subpages `new_stuff/*`, and I also want to have a combined view of all of them (made through inline), and at another page, I want to list what has been linked to in  `new_stuff/*` and what hasn't been linked to.--Ivan Z.
+
+> I see where you're coming from, but let's think about
+> immplementation efficiency for a second. 
+> 
+> In order for inline inheritlinks=yes to work,
+> the inline directive would need to be processed
+> during the scan pass.
+> 
+> When the directive was processed there, it would need
+> to determine which pages get inlined (itself a moderatly
+> expensive operation), and then determine which pages
+> each of them link to. Since the scan pass is unordered,
+> those pages may not have themselves been scanned yet.
+> So to tell what they link to, inline would have to load
+> each of them, and scan them.
+> 
+> So there's the potential for this to slow
+> down a wiki build by about a factor of 2.
+> --[[Joey]] 
diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index d3c3a1375..b71d7cc5f 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -7,3 +7,31 @@ And in general, it would be quite useful to be able to distinguish different kin
 It could distinguish the links by the `rel=` attribute. ([[Tags already receive a special rel-class|todo/rel_attribute_for_links]].) This means there is a general need for a syntax to specify user-defined rel-classes on wikilink (then bug deps would simply use their special rel-class, either directly, or through a special directive like `\[[!depends ]]`), and to refer to them in pagespecs (in forward and backward direction).
 
 Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z.
+
+> FWIW, the `add_link` function introduced in a recent
+> release adds an abstraction that could be used to get
+> part of the way there to storing data about different types of
+> links. That function could easily be extended to take an optional
+> third parameter specifying the link type.
+> 
+> Then there's the question of how to store and access the data. `%links`
+> does not offer a good way to add additional information about links.
+> Now, we could toss `%links` entirely and switch to an accessor function,
+> but let's think about not doing that..
+> 
+> The data that seems to be needed is basically a deep hash, so
+> one could check `$linktype{$page}{tag}{$link}` to see if
+> the page contains a link of the given type. (Note that pages could
+> contain links that were duplicates except for their types.)
+> 
+> There would be some data duplication, unfortuantly, but if `%linktype`
+> is not populated for regular wikilinks, it would at least be limited to
+> tags and other unusual link types, so not too bad.
+> 
+> `%linktype` could be stored in `%pagestate`.. if so
+> the actual use might look like `$pagestate{$page}{linktype}{tag}{$link}`.
+> That could be implemented by the tag plugin right now
+> with no core changes. (BTW, then I originally wrote tag, pagestate
+> was not available, which is why I didn't make it differentiate from
+> normal links.) Might be better to go ahead and add the variable to
+> core though. --[[Joey]] 
diff --git a/docwiki.setup b/docwiki.setup
index 6d732fd6b..52421e501 100644
--- a/docwiki.setup
+++ b/docwiki.setup
@@ -6,6 +6,7 @@ use IkiWiki::Setup::Standard {
 	srcdir => "doc",
 	destdir => "html",
 	templatedir => "templates",
+	underlaydirbase => "underlays",
 	underlaydir => "underlays/basewiki",
 	discussion => 0,
 	exclude => qr/\/discussion|bugs\/*|todo\/*/,
diff --git a/ikiwiki-transition b/ikiwiki-transition
index ce1807309..7e99c878e 100755
--- a/ikiwiki-transition
+++ b/ikiwiki-transition
@@ -42,16 +42,8 @@ sub handle_directive {
 }
 
 sub prefix_directives {
-	my $setup=shift;
-	if (! defined $setup) {
-		usage();
-	}
-
-	require IkiWiki::Setup;
-	require IkiWiki::Plugin::aggregate;
+	loadsetup(shift);
 
-	%config = IkiWiki::defaultconfig();
-	IkiWiki::Setup::load($setup);
 	IkiWiki::loadplugins();
 	IkiWiki::checkconfig();
 	IkiWiki::loadindex();
@@ -114,31 +106,16 @@ sub hashpassword {
 }
 
 sub aggregateinternal {
-	my $setup=shift;
-	if (! defined $setup) {
-		usage();
-	}
-
-	require IkiWiki::Setup;
+	loadsetup(shift);
 	require IkiWiki::Plugin::aggregate;
-
-	%config = IkiWiki::defaultconfig();
-	IkiWiki::Setup::load($setup);
 	IkiWiki::checkconfig();
-
 	IkiWiki::Plugin::aggregate::migrate_to_internal();
 }
 
 sub setupformat {
 	my $setup=shift;
-	if (! defined $setup) {
-		usage();
-	}
-
-	require IkiWiki::Setup;
 
-	%config = IkiWiki::defaultconfig();
-	IkiWiki::Setup::load($setup);
+	loadsetup($setup);
 	IkiWiki::checkconfig();
 	
 	# unpack old-format wrappers setting into new fields
@@ -175,14 +152,8 @@ sub setupformat {
 
 sub moveprefs {
 	my $setup=shift;
-	if (! defined $setup) {
-		usage();
-	}
-
-	require IkiWiki::Setup;
 
-	%config = IkiWiki::defaultconfig();
-	IkiWiki::Setup::load($setup);
+	loadsetup($setup);
 	IkiWiki::checkconfig();
 
 	eval q{use IkiWiki::UserInfo};
@@ -224,22 +195,38 @@ sub deduplinks {
 }
 
 sub setstatedir {
-	my $dir=shift;
+	my $dirorsetup=shift;
 
-	if (! defined $dir) {
+	if (! defined $dirorsetup) {
 		usage();		
 	}
 
-	if (! -d $dir) {
-		error("ikiwiki-transition: $dir does not exist");
+	if (-d $dirorsetup) {
+		$config{wikistatedir}=$dirorsetup."/.ikiwiki";
+	}
+	elsif (-f $dirorsetup) {
+		loadsetup($dirorsetup);
+	}
+	else {
+		error("ikiwiki-transition: $dirorsetup does not exist");
 	}
-
-	$config{wikistatedir}=$dir."/.ikiwiki";
 
 	if (! -d $config{wikistatedir}) {
 		error("ikiwiki-transition: $config{wikistatedir} does not exist");
 	}
 }
+	
+sub loadsetup {
+	my $setup=shift;
+	if (! defined $setup) {
+		usage();
+	}
+
+	require IkiWiki::Setup;
+
+	%config = IkiWiki::defaultconfig();
+	IkiWiki::Setup::load($setup);
+}
 
 sub usage {
 	print STDERR "Usage: ikiwiki-transition type ...\n";
@@ -248,9 +235,9 @@ sub usage {
 	print STDERR "\taggregateinternal setupfile\n";
 	print STDERR "\tsetupformat setupfile\n";
 	print STDERR "\tmoveprefs setupfile\n";
-	print STDERR "\thashpassword srcdir\n";
-	print STDERR "\tindexdb srcdir\n";
-	print STDERR "\tdeduplinks srcdir\n";
+	print STDERR "\thashpassword setupfile|srcdir\n";
+	print STDERR "\tindexdb setupfile|srcdir\n";
+	print STDERR "\tdeduplinks setupfile|srcdir\n";
 	exit 1;
 }