5 files changed, 95 insertions, 3 deletions

diff --git a/doc/bugs/Perl_scripts_depend_on___47__usr__47__bin__47__perl.mdwn b/doc/bugs/Perl_scripts_depend_on___47__usr__47__bin__47__perl.mdwn
index e6a29c48f..d68d506f7 100644
--- a/doc/bugs/Perl_scripts_depend_on___47__usr__47__bin__47__perl.mdwn
+++ b/doc/bugs/Perl_scripts_depend_on___47__usr__47__bin__47__perl.mdwn
@@ -1 +1,6 @@
-On FreeBSD, perl defaults to installation in `/usr/local/bin/perl` since it is not a part of the base system. If the option to create symlinks in `/usr/bin` is not selected, building and running ikiwiki will fail because the shebang lines use `#!/usr/bin/perl [args]`. Changing this to `#!/usr/bin/env -S perl [args]` fixes the issue.
+> On FreeBSD, perl defaults to installation in `/usr/local/bin/perl` since it is not a part of the base system. If the option to create symlinks in `/usr/bin` is not selected, > building and running ikiwiki will fail because the shebang lines use `#!/usr/bin/perl [args]`. Changing this to `#!/usr/bin/env -S perl [args]` fixes the issue.
+
+I think this should be a concern of ikiwiki's official FreeBSD port.
+
+At any rate, even if it is decided that ikiwiki should be fixed, then it is probably better to use
+`$installbin/perl` from `-MConfig` and not the `env` hack.
diff --git a/doc/bugs/logout_in_ikiwiki.mdwn b/doc/bugs/logout_in_ikiwiki.mdwn
index 7b5346864..6696cc689 100644
--- a/doc/bugs/logout_in_ikiwiki.mdwn
+++ b/doc/bugs/logout_in_ikiwiki.mdwn
@@ -33,7 +33,7 @@ It looks like there is no way to logout of ikiwiki at present, meaning that if y
 
 I was referred to this page from posting to the forum. I am also interested in being able to use user class and status to modify the page. I will try to put together a plugin. From what I can see there needs to be a few items in it.
 
-* It should expose a link to a dedicated login page that, once logged in, returns the user to the calling page, or at least the home page.
+* It should expose a link to a dedicated login page that, once logged in, returns the user to the calling page, or at least the home page. I have started a plugin to do this: [[/plugins/contrib/justlogin]]
 
 * it needs to expose a link to a little json explaining the type of user and login status.
 
diff --git a/doc/plugins/contrib/justlogin.mdwn b/doc/plugins/contrib/justlogin.mdwn
new file mode 100644
index 000000000..b9fc6f674
--- /dev/null
+++ b/doc/plugins/contrib/justlogin.mdwn
@@ -0,0 +1,65 @@
+This plugin is still in development. Currently it does bring up the login page and the login page does, with proper credentials, log in the user, but the returning page errors.
+
+Place this code into a page:
+
+<form action="http://portable.local/cgi-bin/ikiwiki.cgi" method="get">
+
+<input type="hidden" name="do" value="justlogin" />
+
+<input type="submit" value="Login" /></form>
+
+
+
+This is the plugin so far:
+
+	#!/usr/bin/perl
+	# Bring up a login page that returns to the calling page
+	package IkiWiki::Plugin::justlogin;
+	
+	use warnings;
+	use strict;
+	use IkiWiki 3.00;
+	
+	sub import {
+		hook(type => "sessioncgi", id => "justlogin", call => \&sessioncgi);
+		hook(type => "auth", id => "justlogin", call => \&auth);
+	}
+	
+	sub sessioncgi ($$) {
+	        my $q=shift;
+	        my $session=shift;
+	
+		debug("jl sessioncgi1 running.");                        
+	
+	        if ($q->param('do') eq 'justlogin') {
+			debug("Justlogin do=justlogin running.");
+			if (! defined $session->param("name") ) {
+				debug("Justlogin param!defined running.");
+				$session->param(postsignin => $ENV{HTTP_REFERER} );
+				$session->param("do" => "justgoback" );
+				IkiWiki::cgi_savesession($session);
+				IkiWiki::cgi_signin($q, $session);
+	                	exit;
+			} 
+		} elsif ($session->param('do') eq 'justgoback') {
+			debug("jl justgoback running.");
+			if (! defined $session->param("name")) {
+				debug("Justlogin redir running.");
+				my $page=IkiWiki::possibly_foolish_untaint($q->param('postsignin'));
+	                	$session->clear("postsignin");
+				$session->clear("do");
+				IkiWiki::cgi_savesession($session);
+				IkiWiki::redirect($q, $page);
+			}
+		}
+	}
+	
+	sub auth ($$) {                 
+	        # While this hook is not currently used, it needs to exist
+	        # so ikiwiki knows that the wiki supports logins, and will
+	        # enable the Preferences page.
+	}
+	            
+	
+	1
+	
diff --git a/doc/tips/integrated_issue_tracking_with_ikiwiki.mdwn b/doc/tips/integrated_issue_tracking_with_ikiwiki.mdwn
index ea7835b33..0c871d6c0 100644
--- a/doc/tips/integrated_issue_tracking_with_ikiwiki.mdwn
+++ b/doc/tips/integrated_issue_tracking_with_ikiwiki.mdwn
@@ -155,7 +155,7 @@ be inlined into a given page. A few examples:
 * A typical list of all open bugs, with their full text, and a form to post new
   bugs.
 
-        \[[!inline pages="bugs/* and !link(done) and !*/Discussion" actions=yes postform=yes show=0]]
+        \[[!inline pages="bugs/* and !link(done) and !*/Discussion" actions=yes postform=yes show=0 rootpage="bugs"]]
 
 * Index of the 30 most recently fixed bugs.
 
diff --git a/doc/todo/feed_enhancements_for_inline_pages.mdwn b/doc/todo/feed_enhancements_for_inline_pages.mdwn
index 2dbadcd60..b48c37d7b 100644
--- a/doc/todo/feed_enhancements_for_inline_pages.mdwn
+++ b/doc/todo/feed_enhancements_for_inline_pages.mdwn
@@ -51,6 +51,9 @@ title and wiki name rather than hard-coding the wiki name as description.
 
 >>> I did not mean to imply that I thought it safe. --[[Joey]] 
 
+>>>> Sorry for assuming you implied that. I do think it is safe, though
+>>>> (I defaulted to not safe just to err on the safe side).
+
 >> The question is what to do for pages that do not have a description
 >> (and are not the index). With your proposal, the Atom feed subtitle
 >> would turn up empty. We could make it conditional in the default
@@ -64,6 +67,22 @@ title and wiki name rather than hard-coding the wiki name as description.
 >>> few RSS consumers likely even use. That's about 3 levels below useful.
 >>> --[[Joey]]
 
+>>>> The way I see it, there are three possibilities for non-index pages
+>>>> which have no description meta: (1) we leave the
+>>>> description/subtitle in feed blank, per your current proposal here
+>>>> (2) we hard-code some string to put there and (3) we make the
+>>>> string to put there configurable. Honestly, I think option #1 sucks
+>>>> aesthetically and option #2 is conceptually wrong (I'm against
+>>>> hard-coding stuff in general), which leaves option #3: however
+>>>> rarely used it would be, I still think it'd be better than #2 and
+>>>> less unaesthetical than #1.
+
+>>>> I'm also not sure what's ‘complex’ about having such an option:
+>>>> it's definitely not going to get much use, but does it hurt to have
+>>>> it? I could understand not wasting time putting it in, but since
+>>>> the code is written already … (but then again I'm known for being a
+>>>> guy who loves options).
+
 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
@@ -88,6 +107,9 @@ created by `urlto()` by fixing the routine itself.
 
 >>> It's impossible to do for perl-format setup files. --[[Joey]]
 
+>>>> Ok. In that case I think that we should document that it must be
+>>>> slash-less. I'll cook up a patch in that sense.
+
 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.