From 63fbfcb0961e33d0e24acdee78689295c0f1faa9 Mon Sep 17 00:00:00 2001 From: "http://www.tobez.org/" Date: Sun, 27 Feb 2011 23:58:13 +0000 Subject: [PATCH 1/5] --- ...erl_scripts_depend_on___47__usr__47__bin__47__perl.mdwn | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) 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. From 2300499bb705f54572b5cce76626bcd7474347c7 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawlYl5TcaZeBgGyH-ze2BTKEhQKaWg7Jzns" Date: Mon, 28 Feb 2011 13:44:11 +0000 Subject: [PATCH 2/5] rootpage="bugs" --- doc/tips/integrated_issue_tracking_with_ikiwiki.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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. From c8ff86eb4e18b319846b4fa0e8dfa9b0bea3c04b Mon Sep 17 00:00:00 2001 From: Giuseppe Bilotta Date: Mon, 28 Feb 2011 16:29:12 +0100 Subject: [PATCH 3/5] Response --- .../feed_enhancements_for_inline_pages.mdwn | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) 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. From 5469b9f1ef4f71c324ab2dffbd34cb7d9a2e4897 Mon Sep 17 00:00:00 2001 From: justint Date: Tue, 1 Mar 2011 14:45:04 +0000 Subject: [PATCH 4/5] --- doc/plugins/contrib/justlogin.mdwn | 65 ++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 doc/plugins/contrib/justlogin.mdwn 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 + From b156dbdcc25aa5f1e8124d0ae14d9aa75835b606 Mon Sep 17 00:00:00 2001 From: justint Date: Tue, 1 Mar 2011 14:46:17 +0000 Subject: [PATCH 5/5] --- doc/bugs/logout_in_ikiwiki.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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.