Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info
Joey Hess
commit
efcbb32f7c
|
|
@ -0,0 +1,17 @@
|
|||
In `IkiWiki::preprocess`, the last capturing group in the regex used to parse directives in prefix_directives mode is of the form `(\s+...)?\]\]`, which will not be matched if the directive is something without arguments or whitespace, like `\[[!orphans]]`. As a result, its value is undef instead of being an empty string, causing a warning when it is used in the anonymous sub `$handle`. A trivial fix is to treat it as "" if it is undef.
|
||||
|
||||
[[patch]] in the master branch of my git repository, and quoted here. --[[smcv]]
|
||||
|
||||
diff --git a/IkiWiki.pm b/IkiWiki.pm
|
||||
index 241a7c0..d2c35a2 100644
|
||||
--- a/IkiWiki.pm
|
||||
+++ b/IkiWiki.pm
|
||||
@@ -1167,7 +1167,8 @@ sub preprocess ($$$;$$) { #{{{
|
||||
}sx;
|
||||
}
|
||||
|
||||
- $content =~ s{$regex}{$handle->($1, $2, $3, $4)}eg;
|
||||
+ # $4 can be undef if the directive was \[[!foo]]
|
||||
+ $content =~ s{$regex}{$handle->($1, $2, $3, ($4 or ""))}eg;
|
||||
return $content;
|
||||
} #}}}
|
||||
|
|
@ -1,26 +1,120 @@
|
|||
The [[plugins/map]] plugin has inconsistent behaviour. In particular, I have in my wiki some directory structures holding files without wikitext pointers (I point directly to the files from elsewhere). For example, imagine the following file structure in the source dir:
|
||||
|
||||
* Assignments.mdwn
|
||||
* Assignments
|
||||
* 2004
|
||||
* Assign1.pdf
|
||||
* Assign2.pdf
|
||||
* 2005
|
||||
* Assign1.pdf
|
||||
* Assign2.pdf
|
||||
* 2006
|
||||
* etc., etc.
|
||||
; ls -R dirA dirB
|
||||
dirA:
|
||||
subA subB
|
||||
|
||||
dirA/subA:
|
||||
filea.mdwn fileb.mdwn
|
||||
|
||||
dirA/subB:
|
||||
filec.mdwn filed.mdwn
|
||||
|
||||
dirB:
|
||||
subA subC
|
||||
|
||||
dirB/subA:
|
||||
filea.mdwn
|
||||
|
||||
dirB/subC:
|
||||
fileb.mdwn filec.mdwn
|
||||
|
||||
When I use map to make a map of this, the result looks more like this:
|
||||
|
||||
* Assignments # this is a link to the correct page
|
||||
* 2004 # this has a create link
|
||||
* Assign1.pdf
|
||||
* Assign2.pdf
|
||||
* Assign1.pdf
|
||||
* Assign2.pdf
|
||||
* etc., etc.
|
||||
<ul>
|
||||
<li><span class="createlink">? dirA</span>
|
||||
<ul>
|
||||
<li><span class="createlink">? subA</span>
|
||||
<ul>
|
||||
<li>filea
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>fileb
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>filec
|
||||
</li>
|
||||
<li>filed
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><span class="createlink">? dirB</span>
|
||||
<ul>
|
||||
<li><span class="createlink">? subA</span>
|
||||
<ul>
|
||||
<li>filea
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li><span class="createlink">? subC</span>
|
||||
<ul>
|
||||
<li>fileb
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>filec
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
Note that while the 2004 directory exists with a create link, the 2005 and 2006 (etc) directories are missing from the site map.
|
||||
Note that while the dirA/subA directory exists with a create link, the dirA/subB directory is missing from the map. Interestingly, dirB/subC is shown in the map. If you add a second file to dirB/subA then dirB/subC disappears as well.
|
||||
|
||||
I could imagine including all 'bare' directories in the map, and I could imagine including no 'bare' directories in the map. Just including the first bare directory seems a strange intermediate point.
|
||||
|
||||
Attached is a [[patch]] that fixes the issue. The current map code makes one pass over the sorted list of pages. This adds an initial pass that goes through and makes sure that all parent directories are included. With this initial pass added, the following pass could probably be simplified.
|
||||
|
||||
Note: This patch adds items to a map while it is in a foreach loop over a sorted list of keys from that same map. Changing a map while iterating through it is normally problematic. I'm assuming the sort insulates the code from this - I do not need to iterate over any of the newly added elements.
|
||||
|
||||
diff --git a/IkiWiki/Plugin/map.pm b/IkiWiki/Plugin/map.pm
|
||||
index 5b6a843..16de45e 100644
|
||||
--- a/IkiWiki/Plugin/map.pm
|
||||
+++ b/IkiWiki/Plugin/map.pm
|
||||
@@ -67,6 +67,39 @@ sub preprocess (@) { #{{{
|
||||
# are removed.
|
||||
add_depends($params{page}, join(" or ", keys %mapitems));
|
||||
|
||||
+ # Include all the parent directories in the map
|
||||
+ my $lastbase="";
|
||||
+ my $commonbase = "";
|
||||
+ $commonbase = $common_prefix if defined $common_prefix && length $common_prefix;
|
||||
+ foreach my $item (sort keys %mapitems) {
|
||||
+ $item=~s/^\Q$common_prefix\E\///
|
||||
+ if defined $common_prefix && length $common_prefix;
|
||||
+ my $itembase=IkiWiki::dirname($item);
|
||||
+ if ($itembase ne $lastbase) {
|
||||
+ # find the common dir
|
||||
+ my @a=split(/\//, $itembase);
|
||||
+ my @b=split(/\//, $lastbase);
|
||||
+ my $common_dir=$commonbase;
|
||||
+ while (@a && @b && $a[0] eq $b[0]) {
|
||||
+ if (length $common_dir) {
|
||||
+ $common_dir.="/";
|
||||
+ }
|
||||
+ $common_dir.=shift(@a);
|
||||
+ shift @b;
|
||||
+ }
|
||||
+ # add all the dirs down to the current base
|
||||
+ while (@a) {
|
||||
+ if (length $common_dir) {
|
||||
+ $common_dir.="/";
|
||||
+ }
|
||||
+ $common_dir.=shift(@a);
|
||||
+ $mapitems{$common_dir}=''
|
||||
+ unless defined $mapitems{$common_dir};
|
||||
+ }
|
||||
+ $lastbase = $itembase;
|
||||
+ }
|
||||
+ }
|
||||
+
|
||||
# Create the map.
|
||||
my $parent="";
|
||||
my $indent=0;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,14 @@
|
|||
I've set up a simple sidebar on an otherwise fairly default wiki. The sidebar uses css float:right and sits above most pages quite nicely.
|
||||
|
||||
For example, my wiki's [front](http://www.cse.unsw.edu.au/~cs3431/wiki/) and [news](http://www.cse.unsw.edu.au/~cs3431/wiki/news/) pages show the sidebar nicely floating on top of the background. (As a side note, I had to add:
|
||||
|
||||
#sidebar {
|
||||
border: 1px solid;
|
||||
background: white;
|
||||
}
|
||||
|
||||
to <code>local.css</code> to get the border and make sure that the RSS feed's grey title didn't show through on the news page.)
|
||||
|
||||
Unfortunately, the [recentchanges](http://www.cse.unsw.edu.au/~cs3431/wiki/recentchanges/) page doesn't look so nice - the sidebar appears below the recentchanges list.
|
||||
|
||||
I don't understand why the sidebar is appearing below the recentchanges inline, but above the news inline.
|
||||
|
|
@ -2,9 +2,9 @@ I'd like to be able to drop an unmodified RFC2822 email message into ikiwiki, an
|
|||
|
||||
> We're discussing doing just that (well, whole mailboxes, really) over in
|
||||
> [[comment_by_mail]] --[[Joey]]
|
||||
>> If you like to read code, you can have a gander at the
|
||||
>> The
|
||||
>> [mailbox](http://pivot.cs.unb.ca/git/?p=ikimailbox.git;a=summary)
|
||||
>> plugin. At the moment, it reads all of the messages in a maildir and passes them through
|
||||
>> a template of your choice. Kinda acts like `cat` at the moment because none of the
|
||||
>> css is defined yet. Next missions are threading (Email::Thread?), and maybe some simple css.
|
||||
>> plugin can now be considered a prototype of itself, tested only with maildirs.
|
||||
>> Basic threading and some simple css is now included. Next mission:
|
||||
>> doing something sensible with MIME.
|
||||
>> To see the (unsurprising) syntax, look at [a trivial example markdown file](http://pivot.cs.unb.ca/git/?p=ikimailbox.git;a=blob;f=test/in/index.mdwn;hb=HEAD)
|
||||
|
|
|
|||
|
|
@ -61,6 +61,9 @@ Suggestions of ideas for plugins:
|
|||
> The hard part is just that right now the assumption of html as the one destination
|
||||
> type is in the code a lot. --ChapmanFlack
|
||||
|
||||
>> Readers who bought this also liked: [[format_escape]], [[multiple_output_formats]]
|
||||
>> --[[JeremieKoenig]]
|
||||
|
||||
* list of registered users - tricky because it sorta calls for a way to rebuild the page when a new user is registered. Might be better as a cgi?
|
||||
> At best, this could only show the users who have logged in, not all
|
||||
> permitted by the current auth plugin(s). HTTP auth would need
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
[Amitai Schlair](http://www.schmonz.com/) recently discovered ikiwiki.
|
||||
[Amitai Schlair](http://www.schmonz.com/) recently discovered ikiwiki. His first attempt at contributing is [[plugins/contrib/unixauth]].
|
||||
|
|
|
|||
Loading…
Reference in New Issue