Merge branch 'ready/postform-no'
authorSimon McVittie <smcv@debian.org>
Fri, 12 Sep 2014 20:46:04 +0000 (21:46 +0100)
committerSimon McVittie <smcv@debian.org>
Fri, 12 Sep 2014 20:46:04 +0000 (21:46 +0100)
99 files changed:
IkiWiki.pm
IkiWiki/CGI.pm
IkiWiki/Plugin/comments.pm
IkiWiki/Plugin/conditional.pm
IkiWiki/Plugin/highlight.pm
IkiWiki/Plugin/trail.pm
Makefile.PL
debian/changelog
debian/control
doc/bugs/Inlining_adds_newlines_which_can_break_markdown.mdwn [new file with mode: 0644]
doc/bugs/Please_update_highlight_plugin_for_highlight_3.18.mdwn [new file with mode: 0644]
doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn
doc/bugs/can__39__t_upload_a_simple_png_image:_prohibited_by_allowed__95__attachments___40__file_MIME_type_is_application__47__octet-stream....mdwn
doc/bugs/conditional_preprocess_during_scan.mdwn
doc/bugs/debwiki_shortcut_creates_buggy_URLs_to_subpages.mdwn [new file with mode: 0644]
doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
doc/bugs/garbled_non-ascii_characters_in_body_in_web_interface.mdwn [new file with mode: 0644]
doc/bugs/image_rescaling_distorts_with_small_pictures.mdwn
doc/bugs/linkmap_displays_underscore_escapes.mdwn
doc/bugs/notifyemail_fails_with_some_openid_providers.mdwn
doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
doc/bugs/possible_to_post_comments_that_will_not_be_displayed.mdwn
doc/bugs/preprocessing_loop_control_too_tight.mdwn
doc/bugs/pythonproxy-utf8_again.mdwn
doc/bugs/redirect.mdwn
doc/bugs/rst_plugin_fails_with___34__uncaught_exception:___39__ascii__39___codec_can__39__t_encode_character__34__.mdwn
doc/bugs/rst_plugin_hangs_when_used_with_Python_3.mdwn [new file with mode: 0644]
doc/bugs/svg_and_pdf_conversion_fails.mdwn
doc/bugs/template_creation_error.mdwn
doc/bugs/template_evaluation_oddities.mdwn [new file with mode: 0644]
doc/bugs/trails_depend_on_everything.mdwn [new file with mode: 0644]
doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
doc/css_market.mdwn
doc/forum/Right-to-left_support.mdwn [new file with mode: 0644]
doc/forum/Right-to-left_support/comment_1_5b2bf4d037ae8db940296e6f58884927._comment [new file with mode: 0644]
doc/forum/Spaces_in_URLs.mdwn [new file with mode: 0644]
doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn [new file with mode: 0644]
doc/forum/Using_reverse_proxy__59___base_URL_is_http_instead_of_https/comment_5_674f56100c0682eba36cc5327fbdae4a._comment [new file with mode: 0644]
doc/forum/__34__Error:_cannot_decode_string_with_wide_characters__34___on_Mageia_Linux_x86-64_Cauldron.mdwn
doc/forum/__34__Error:_cannot_decode_string_with_wide_characters__34___on_Mageia_Linux_x86-64_Cauldron/comment_1_abf7ec7c378ab0908685d72d159e9fd2._comment [new file with mode: 0644]
doc/forum/how_to_have_a_plugin_delete_a_file.mdwn [new file with mode: 0644]
doc/forum/how_to_have_a_plugin_delete_a_file/comment_1_061c8bca174f7155d4065dd200c0c8db._comment [new file with mode: 0644]
doc/forum/how_to_have_a_plugin_delete_a_file/comment_2_864a20147885642ad3bbcf8400d8ee46._comment [new file with mode: 0644]
doc/ikiwiki/markdown/discussion.mdwn [new file with mode: 0644]
doc/news/openid.mdwn
doc/news/version_3.20130904.1.mdwn [deleted file]
doc/news/version_3.20140102.mdwn [deleted file]
doc/news/version_3.20140815.mdwn [new file with mode: 0644]
doc/news/version_3.20140831.mdwn [new file with mode: 0644]
doc/plugins/contrib/addtag.mdwn
doc/plugins/contrib/album.mdwn
doc/plugins/contrib/album/discussion.mdwn
doc/plugins/contrib/created_in_future.mdwn
doc/plugins/contrib/datetime_cmp.mdwn
doc/plugins/contrib/jscalendar.mdwn
doc/plugins/contrib/monthcalendar.mdwn
doc/plugins/contrib/navbar.mdwn
doc/plugins/contrib/parenttag.mdwn
doc/plugins/contrib/poetry.mdwn [new file with mode: 0644]
doc/plugins/contrib/sidebar2.mdwn
doc/plugins/contrib/taskreport.mdwn
doc/plugins/osm.mdwn
doc/plugins/trail/discussion.mdwn
doc/sandbox.mdwn
doc/sandbox/discussion.mdwn [new file with mode: 0644]
doc/shortcuts.mdwn
doc/spam_fighting.mdwn
doc/tips/Hosting_Ikiwiki_and_master_git_repository_on_different_machines.mdwn
doc/tips/Hosting_Ikiwiki_and_master_git_repository_on_different_machines/separate-web-git-servers.svg [new file with mode: 0644]
doc/tips/Right-to-left___40__RTL__41___page_text.mdwn [new file with mode: 0644]
doc/tips/distributed_wikis.mdwn
doc/tips/ikiwiki_on_mac_os_x.mdwn
doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn
doc/todo/add_remove_to_actionlist.mdwn [new file with mode: 0644]
doc/todo/calendar_autocreate.mdwn
doc/todo/do_not_make_links_backwards.mdwn
doc/todo/document_dependency_influences_in_code.mdwn
doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
doc/todo/expose_html_language_and_direction.mdwn
doc/todo/flexible_relationships_between_pages.mdwn
doc/todo/manpages.mdwn
doc/todo/pagespec__95__match__95__list_can_result_in_excessive_dependencies.mdwn [new file with mode: 0644]
doc/todo/per-page_comment_control.mdwn [new file with mode: 0644]
doc/todo/should_use_a_standard_encoding_for_utf_chars_in_filenames.mdwn
doc/todo/support_linking_to_cgit.mdwn
doc/todo/support_multi-row_table_headers.mdwn [new file with mode: 0644]
doc/todo/upload__95__figure.mdwn
doc/users/kjs.mdwn
doc/users/mhameed.mdwn
doc/users/smcv.mdwn
doc/users/smcv/ready.mdwn [moved from doc/users/smcv/yesplease.mdwn with 51% similarity]
doc/users/spalax.mdwn
ikiwiki.spec
plugins/proxy.py
po/ikiwiki.pot
underlays/attachment/ikiwiki/jquery-ui.css [moved from underlays/attachment/ikiwiki/jquery-ui.full.css with 100% similarity]
underlays/attachment/ikiwiki/jquery-ui.js [moved from underlays/attachment/ikiwiki/jquery-ui.full.js with 100% similarity]
underlays/attachment/ikiwiki/jquery.tmpl.js [moved from underlays/attachment/ikiwiki/jquery.tmpl.full.js with 100% similarity]
underlays/jquery/ikiwiki/jquery.js [moved from underlays/jquery/ikiwiki/jquery.full.js with 100% similarity]

index e5da04a3bb86d8aa47d96cac3df679623ad707ee..49ac9719658496953dc5f32c920e27ee5ba9d20c 100644 (file)
@@ -1819,7 +1819,8 @@ sub loadindex () {
                        open ($in, "<", "$config{wikistatedir}/indexdb") || return;
                }
                else {
-                       $config{gettime}=1; # first build
+                       # gettime on first build
+                       $config{gettime}=1 unless defined $config{gettime};
                        return;
                }
        }
@@ -2459,6 +2460,19 @@ sub pagespec_match ($$;@) {
        return $sub->($page, @params);
 }
 
+# e.g. @pages = sort_pages("title", \@pages, reverse => "yes")
+#
+# Not exported yet, but could be in future if it is generally useful.
+# Note that this signature is not the same as IkiWiki::SortSpec::sort_pages,
+# which is "more internal".
+sub sort_pages ($$;@) {
+       my $sort = shift;
+       my $list = shift;
+       my %params = @_;
+       $sort = sortspec_translate($sort, $params{reverse});
+       return IkiWiki::SortSpec::sort_pages($sort, @$list);
+}
+
 sub pagespec_match_list ($$;@) {
        my $page=shift;
        my $pagespec=shift;
index c0d8f598b5f882b27bd2d5671d476aa5164a812b..cb83319e62ee893d92fd1d5f64695c23144d2614 100644 (file)
@@ -110,11 +110,23 @@ sub decode_cgi_utf8 ($) {
        }
 }
 
+sub safe_decode_utf8 ($) {
+    my $octets = shift;
+    # call decode_utf8 on >= 5.20 only if it's not already decoded,
+    # otherwise it balks, on < 5.20, always call it
+    if ($] < 5.02 || !Encode::is_utf8($octets)) {
+        return decode_utf8($octets);
+    }
+    else {
+        return $octets;
+    }
+}
+
 sub decode_form_utf8 ($) {
        if ($] >= 5.01) {
                my $form = shift;
                foreach my $f ($form->field) {
-                       my @value=map { decode_utf8($_) } $form->field($f);
+                       my @value=map { safe_decode_utf8($_) } $form->field($f);
                        $form->field(name  => $f,
                                     value => \@value,
                                     force => 1,
index a0ca9f32e484090969fbfa605875268cd112e9d8..98ae13810200269a34fbfb8b24093e26dc5ad4bb 100644 (file)
@@ -438,6 +438,16 @@ sub editcomment ($$) {
                        $page));
        }
 
+       # There's no UI to get here, but someone might construct the URL,
+       # leading to a comment that exists in the repository but isn't
+       # shown
+       if (!pagespec_match($page, $config{comments_pagespec},
+               location => $page)) {
+               error(sprintf(gettext(
+                       "comments on page '%s' are not allowed"),
+                       $page));
+       }
+
        if (pagespec_match($page, $config{comments_closed_pagespec},
                location => $page)) {
                error(sprintf(gettext(
index 0a3d7fb4cd18ef14261eb6896722c0991d8405dd..b450f1a0a1cea267e3e2791376142c67438f03b9 100644 (file)
@@ -33,11 +33,15 @@ sub preprocess_if (@) {
            # An optimisation to avoid needless looping over every page
            # for simple uses of some of the tests.
            $params{test} =~ /^([\s\!()]*((enabled|sourcepage|destpage|included)\([^)]*\)|(and|or))[\s\!()]*)+$/) {
-               add_depends($params{page}, "($params{test}) and $params{page}");
                $result=pagespec_match($params{page}, $params{test},
                                location => $params{page},
                                sourcepage => $params{page},
                                destpage => $params{destpage});
+               my $i = $result->influences;
+               foreach my $k (keys %$i) {
+                       # minor optimization: influences are always simple dependencies
+                       $IkiWiki::depends_simple{$params{page}}{lc $k} |= $i->{$k};
+               }
        }
        else {
                $result=pagespec_match_list($params{page}, $params{test},
index fbe7ddff44f0c9111b63cca96f6a58fb80ac41f8..ce919748a4d10c6308cea7c1ea6559c47c608534 100644 (file)
@@ -60,14 +60,22 @@ sub checkconfig () {
        }
 
        if (! exists $config{filetypes_conf}) {
-               $config{filetypes_conf}= 
-                    ($data_dir ? $data_dir->getConfDir() : "/etc/highlight/")
-                         . "filetypes.conf";
+         if (! $data_dir ) {
+               $config{filetypes_conf}= "/etc/highlight/filetypes.conf";
+             } elsif ( $data_dir -> can('searchFile') ) {
+               # 3.18 +
+               $config{filetypes_conf}=
+                 $data_dir -> searchFile("filetypes.conf");
+             } else {
+               # 3.9 +
+               $config{filetypes_conf}=
+                 $data_dir -> getConfDir() . "/filetypes.conf";
+             }
        }
+       # note that this is only used for old versions of highlight
+       # where $data_dir will not be defined.
        if (! exists $config{langdefdir}) {
-               $config{langdefdir}=
-                    ($data_dir ? $data_dir->getLangPath("")
-                     : "/usr/share/highlight/langDefs");
+               $config{langdefdir}= "/usr/share/highlight/langDefs";
 
        }
        if (exists $config{tohighlight} && read_filetypes()) {
@@ -147,17 +155,27 @@ sub read_filetypes () {
 }
 
 
+sub searchlangdef {
+  my $lang=shift;
+
+  if ($data_dir) {
+    return $data_dir->getLangPath($lang . ".lang");
+  } else {
+    return "$config{langdefdir}/$lang.lang";
+  }
+
+}
 # Given a filename extension, determines the language definition to
 # use to highlight it.
 sub ext2langfile ($) {
        my $ext=shift;
 
-       my $langfile="$config{langdefdir}/$ext.lang";
+       my $langfile=searchlangdef($ext);
        return $langfile if exists $highlighters{$langfile};
 
        read_filetypes() unless $filetypes_read;
        if (exists $ext2lang{$ext}) {
-               return "$config{langdefdir}/$ext2lang{$ext}.lang";
+               return searchlangdef($ext2lang{$ext});
        }
        # If a language only has one common extension, it will not
        # be listed in filetypes, so check the langfile.
index d5fb2b5d624c1b21cf0fa9163b5b223a090e917e..476db4dcb90130ce895c9480300ac84e12c482b1 100644 (file)
@@ -319,10 +319,9 @@ sub prerender {
                }
 
                if (defined $pagestate{$trail}{trail}{sort}) {
-                       # re-sort
-                       @$members = pagespec_match_list($trail, 'internal(*)',
-                               list => $members,
-                               sort => $pagestate{$trail}{trail}{sort});
+                       @$members = IkiWiki::sort_pages(
+                               $pagestate{$trail}{trail}{sort},
+                               $members);
                }
 
                if (IkiWiki::yesno $pagestate{$trail}{trail}{reverse}) {
index c03142aaea4cd672d935391e5ecce63ba9975bb3..ad3e4623c8a9acf41c58a1301964d50dec8f31fa 100755 (executable)
@@ -75,7 +75,7 @@ underlay_install:
        install -d $(DESTDIR)$(PREFIX)/share/ikiwiki
        for dir in `cd underlays && $(FIND) . -follow -type d`; do \
                install -d $(DESTDIR)$(PREFIX)/share/ikiwiki/$$dir; \
-               for file in `$(FIND) underlays/$$dir -follow -maxdepth 1 -type f ! -name \\*.full.js ! -name \\*.full.css`; do \
+               for file in `$(FIND) underlays/$$dir -follow -maxdepth 1 -type f ! -name jquery.js ! -name jquery-ui.css ! -name jquery-ui.js ! -name jquery.tmpl.js`; do \
                        cp -pRL $$file $(DESTDIR)$(PREFIX)/share/ikiwiki/$$dir 2>/dev/null || \
                        install -m 644 $$file $(DESTDIR)$(PREFIX)/share/ikiwiki/$$dir; \
                done; \
index 11ad07712daee58cc6cf96c404348ae1f7252245..59a9e6ba1a98f66a162e40e11e5ca2cf47f4dbe9 100644 (file)
@@ -1,9 +1,29 @@
-ikiwiki (3.20140614) UNRELEASED; urgency=medium
+ikiwiki (3.20140912) UNRELEASED; urgency=medium
+
+  * Don't double-decode CGI submissions with Encode.pm >= 2.53,
+    fixing "Error: Cannot decode string with wide characters".
+    Thanks, Antoine Beaupré
+
+ -- Simon McVittie <smcv@debian.org>  Fri, 12 Sep 2014 21:23:58 +0100
+
+ikiwiki (3.20140831) unstable; urgency=medium
+
+  * Make --no-gettime work in initial build. Closes: #755075
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 31 Aug 2014 14:17:24 -0700
+
+ikiwiki (3.20140815) unstable; urgency=medium
 
   * Add google back to openid selector. Apparently this has gotten a stay
     of execution until April 2015. (It may continue to work until 2017.)
-
- -- Joey Hess <joeyh@debian.org>  Thu, 03 Jul 2014 16:19:40 -0400
+  * highlight: Add compatibility with highlight 3.18, while still supporting
+    3.9+. Closes: #757679
+    Thanks, David Bremner
+  * highlight: Add support for multiple language definition directories
+    Closes: #757680
+    Thanks, David Bremner
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 15 Aug 2014 12:58:08 -0400
 
 ikiwiki (3.20140613) unstable; urgency=medium
 
index c06e8fbac96b8d1244e635906deb19749da2b4f8..2ab6207e038ea3e9ee50bf7652d4498eea161e5f 100644 (file)
@@ -7,7 +7,8 @@ Build-Depends-Indep: dpkg-dev (>= 1.9.0), libxml-simple-perl,
   libtimedate-perl, libhtml-template-perl,
   libhtml-scrubber-perl, wdg-html-validator,
   libhtml-parser-perl, liburi-perl (>= 1.36), perlmagick, po4a (>= 0.34),
-  libfile-chdir-perl, libyaml-libyaml-perl, python-support
+  libfile-chdir-perl, libyaml-libyaml-perl, python-support, librpc-xml-perl,
+  libcgi-session-perl
 Maintainer: Joey Hess <joeyh@debian.org>
 Uploaders: Josh Triplett <josh@freedesktop.org>
 Standards-Version: 3.9.5
diff --git a/doc/bugs/Inlining_adds_newlines_which_can_break_markdown.mdwn b/doc/bugs/Inlining_adds_newlines_which_can_break_markdown.mdwn
new file mode 100644 (file)
index 0000000..eb71994
--- /dev/null
@@ -0,0 +1,43 @@
+I'm trying to put a list of tags in a table, so I carefully make a newline-free taglist.tmpl and then do:
+
+    | \[[!inline pages="link(/category/env)" feeds=no archive=yes sort=title template=taglist]] |
+
+but there's a line in `inline.pm` that does:
+
+    return "&lt;div class=\"inline\" id=\"$#inline\"&gt;&lt;/div&gt;\n\n";
+
+And the extra newlines break the table.  Can they be safely removed?
+
+> If you want an HTML table, I would suggest using an HTML table, which
+> should pass through Markdown without being interpreted further:
+>
+>     <table><tr>
+>     \[[!inline pages="link(/category/env)" feeds=no archive=yes sort=title template=tagtd]]
+>     </tr></table>
+>
+> where tagtd.tmpl is of the form `<td>your markup here</td>`; or even just
+>
+>     \[[!inline pages="link(/category/env)" feeds=no archive=yes sort=title template=tagtable]]
+>
+> where tagtable.tmpl looks like
+>
+>     <TMPL_IF FIRST>
+>     <table><tr>
+>     </TMPL_IF>
+>
+>     <td>your tag here</td>
+>
+>     <TMPL_IF LAST>
+>     </tr></table>
+>     </TMPL_IF>
+>
+> I don't think you're deriving much benefit from Markdown's table syntax
+> if you have to mix it with HTML::Template and ikiwiki directives,
+> and be pathologically careful with whitespace. "Right tool for the job"
+> and all that :-)
+>
+> When I edited this page I was amused to find that you used HTML,
+> not Markdown, as its format. It seems oddly appropriate to my answer, but
+> I've converted it to Markdown and adjusted the formatting, for easier
+> commenting.
+> --[[smcv]]
diff --git a/doc/bugs/Please_update_highlight_plugin_for_highlight_3.18.mdwn b/doc/bugs/Please_update_highlight_plugin_for_highlight_3.18.mdwn
new file mode 100644 (file)
index 0000000..e98f668
--- /dev/null
@@ -0,0 +1,12 @@
+I have put two patches 
+
+     git://pivot.cs.unb.ca/ikiwiki.git -b master
+
+The first works around a highlight API change, and the second supports the new(ish) 
+feature of having multiple directories with language defintions for highlight.
+
+The corresponding version of libhighlight-perl is in Debian experimental if you want to test.
+
+[[!tag patch]] 
+
+> [[done]] thanks --[[Joey]]
index 70deda2ab79c03e1dea280504451306ea5dfb35a..7e7548657812fdac4b3d18dd48478a6b9259483c 100644 (file)
@@ -1,3 +1,8 @@
+[[!tag patch users/smcv/ready]]
+[[!template id=gitbranch branch=smcv/ready/postform-no
+author="[[Simon McVittie|smcv]]"
+browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/postform-no]]
+
 The [[ikiwiki/directive/inline]] directive generates a form if
 it has either rootpage, or postform with a "yes-like" value. This
 means that
@@ -9,4 +14,10 @@ mentioning rootpage there is useless).
 
 See also [[forum/How_to_disable_"Add_a_new_post_titled:"_submission_form?]].
 
+My `ready/postform-no` branch also contains a trivial regression test for
+`inline`. So far the only thing it really tests is that this bug was fixed,
+not the actual inlining of pages, but it's a start.
+
 --[[smcv]]
+
+>> this looks simple, straightforward and good to me --[[chrysn]]
index 4e3332748db2cb25c13dc1c53793ee2bf0a91870..627b2c82764de62be9f2609e686a58665645fffc 100644 (file)
@@ -56,16 +56,22 @@ Weird... --[[anarcat]]
 > > 
 > > --[[anarcat]]
 
+> > > [[!template  id=gitbranch branch=ready/more-magic author="[[smcv]]" browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/commitdiff/ready/more-magic]]
 > > > If the regex match isn't necessary and it's just about deleting the
-> > > parameters, I think I'd prefer something like
+> > > parameters, I think I'd prefer
 > > >
 > > >     if (! defined $mimetype) {
 > > >         ...
 > > >     }
 > > >     $mimetype =~ s/;.*//;
 > > >
-> > > but I'd be hesitant to do that without knowing why Joey implemented it
-> > > the way it is. If it's about catching a result from file(1) that
+> > > as done in my `ready/more-magic` branch.
+> > >
+> > > I'm a little hesitant to do that without knowing why Joey implemented it
+> > > the way it is, but as far as I can tell it's just an oversight.
+> > >
+> > > Or, if the result of the s/// is checked for a reason, and it's
+> > > about catching a result from file(1) that
 > > > is not, in fact, a MIME type at all (empty string or error message
 > > > or something), maybe something more like this?
 > > >
@@ -74,3 +80,12 @@ Weird... --[[anarcat]]
 > > > (or whatever the allowed characters in MIME types are). --[[smcv]]
 
 > > > > I don't mind either way, but i feel this should be fixed for the next release, as I need to reapply this patch at every upgrade now. -- [[anarcat]]
+
+> > > > > This is still a problem in 3.20140831. -- [[anarcat]]
+
+> > > > > > I still don't think appending a semicolon is the right answer:
+> > > > > > at best it's equivalent to what I suggested, and at worst it's
+> > > > > > disabling a check that does have some reason behind it.
+> > > > > > I've turned the version I suggested above into a proper branch.
+> > > > > > Review by someone who can commit to ikiwiki.git would be appreciated.
+> > > > > > --[[smcv]]
index 1ba142331dd0804b63a25f6d3c48d171c8f5ef00..739be82863fa4c7984046548ffc4b6d71e731c66 100644 (file)
@@ -55,3 +55,58 @@ reprocessed is done so in the same conditions as the original call.
 >> with vicious conditional dependency circles that would break/unbreak
 >> depending on which pass we are in. And I believe this is an intrinsic
 >> limitation of the system, which cannot be solved at all.
+
+>>> One way forward that I can think of for this issue is to
+>>> have a way to tell `\[[!if]]` which answer it should assume for
+>>> scanning purposes, so it would assume that answer when running
+>>> in the scan phase, and really evaluate the pagespec when running
+>>> in the render phase. For instance:
+>>>
+>>>     \[[!if test="enabled(foo)" scan_assume=yes then="""
+>>>     \[[!foo]]
+>>>     """]]
+>>>
+>>> could maybe scan \[[!foo]] unconditionally.
+>>>
+>>> This makes me wonder whether `\[[!if]]` was too general: by having
+>>> the full generality of pagespecs, it reduces its possible uses to
+>>> "those contexts where pagespecs work".
+>>>
+>>> Another possibility might be to have "complex" pagespecs and sort
+>>> orders (those whose correct answer requires scanning to have completed,
+>>> like `link()` and sorting by `meta(title)`) throw an error when used in
+>>> the scan phase, but simple pagespecs like `enabled()` and `glob()`, and
+>>> simple sort orders like `title` and `path`, could continue to work?
+>>> My `wip-too-soon` work-in-progress branch is heading in this direction,
+>>> although it currently makes `pagespec_match` fail completely and does
+>>> not even allow "simple" pagespecs and sort orders.
+>>>
+>>> At the moment, if a pagespec cannot be evaluated, `\[[!if]]` will
+>>> produce neither the `then` clause nor the `else` clause. This could
+>>> get pretty confusing if it is run during the scan phase and produces
+>>> an error, then run during the render phase and succeeds: if you had,
+>>> say,
+>>>
+>>>     \[[!if run_during_scan=1 test="link(foo)" then="""
+>>>     there is a link to foo
+>>>     \[[!tag there_is_a_link_to_foo]]
+>>>     """ else="""
+>>>     there is no link to foo
+>>>     \[[!tag there_is_no_link_to_foo]]
+>>>     """]]
+>>>
+>>> then the resulting page would contain one of the snippets of text,
+>>> but its metadata would contain neither of the tags. Perhaps the plugin
+>>> would have to remember that it failed during the scan phase, so that
+>>> it could warn about the failure during the render phase instead of,
+>>> or in addition to, producing its normal output?
+>>>
+>>> Of the conditional-specific tests, `included()` and `destpage(glob)`
+>>> can never match during scan.
+>>>
+>>> Does anyone actually use `\[[!if]]` in ways that they would want to
+>>> be active during scan, other than an `enabled(foo)` test?
+>>> I'm increasingly tempted to add `\[[!ifenabled foo]]` to solve
+>>> that single case, and call that a solution to this bug...
+>>>
+>>> --[[smcv]]
diff --git a/doc/bugs/debwiki_shortcut_creates_buggy_URLs_to_subpages.mdwn b/doc/bugs/debwiki_shortcut_creates_buggy_URLs_to_subpages.mdwn
new file mode 100644 (file)
index 0000000..f83f960
--- /dev/null
@@ -0,0 +1,5 @@
+E.g. [[!debwiki Derivatives/Guidelines]].
+
+Maybe we should use `%S` instead of `%s` in the shortcut definition?
+
+> seems reasonable, [[done]] --[[smcv]]
index 057a50f0c93d8d4891877df0f53c5b10efe96cb1..c7d0ffbe2ef20e92cfb607f0c06204b4235cb16c 100644 (file)
@@ -33,7 +33,7 @@ of the problem is that it evaluates the pagespec
 > [[!template id=gitbranch branch=smcv/ready/perf
 author="[[Simon McVittie|smcv]]"
 browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/perf]]
-> [[!tag patch]]
+> [[!tag patch users/smcv/ready]]
 >
 > Previously, if a page like `plugins/trail` contained a conditional like
 >
diff --git a/doc/bugs/garbled_non-ascii_characters_in_body_in_web_interface.mdwn b/doc/bugs/garbled_non-ascii_characters_in_body_in_web_interface.mdwn
new file mode 100644 (file)
index 0000000..657b86b
--- /dev/null
@@ -0,0 +1,126 @@
+since my latest jessie upgrade here, charsets are all broken when editing a page. the page i'm trying to edit is [this wishlist](http://anarc.at/wishlist/), and it used to work fine. now, instead of:
+
+`Voici des choses que vous pouvez m'acheter si vous êtes le Père Nowel (yeah right):`
+
+... as we see in the rendered body right now, when i edit the page i see:
+
+`Voici des choses que vous pouvez m'acheter si vous �tes le P�re Nowel (yeah right):`
+
+... a typical double-encoding nightmare. The actual binary data is this for the word "Père" according to `hd`:
+
+~~~~
+anarcat@marcos:ikiwiki$ echo "Père" | hd
+00000000  50 c3 a8 72 65 0a                                 |P..re.|
+00000006
+anarcat@marcos:ikiwiki$ echo "P�re" | hd
+00000000  50 ef bf bd 72 65 0a                              |P...re.|
+00000007
+~~~~
+
+> I don't know what that is, but it isn't the usual double-UTF-8 encoding:
+>
+>     >>> u'è'.encode('utf-8')
+>     '\xc3\xa8'
+>     >>> u'è'.encode('utf-8').decode('latin-1').encode('utf-8')
+>     '\xc3\x83\xc2\xa8'
+>
+> A packet capture of the incorrect HTTP request/response headers and body
+> might be enlightening? --[[smcv]]
+>
+> > Here are the headers according to chromium:
+> > 
+> > ~~~~
+> > GET /ikiwiki.cgi?do=edit&page=wishlist HTTP/1.1
+> > Host: anarc.at
+> > Connection: keep-alive
+> > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
+> > User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
+> > Referer: http://anarc.at/wishlist/
+> > Accept-Encoding: gzip,deflate,sdch
+> > Accept-Language: fr,en-US;q=0.8,en;q=0.6
+> > Cookie: openid_provider=openid; ikiwiki_session_anarcat=XXXXXXXXXXXXXXXXXXXXXXX
+> > 
+> > HTTP/1.1 200 OK
+> > Date: Mon, 08 Sep 2014 21:22:24 GMT
+> > Server: Apache/2.4.10 (Debian)
+> > Set-Cookie: ikiwiki_session_anarcat=XXXXXXXXXXXXXXXXXXXXXXX; path=/; HttpOnly
+> > Vary: Accept-Encoding
+> > Content-Encoding: gzip
+> > Content-Length: 4093
+> > Keep-Alive: timeout=5, max=100
+> > Connection: Keep-Alive
+> > Content-Type: text/html; charset=utf-8
+> > ~~~~
+> > 
+> > ... which seem fairly normal... getting more data than this is a little inconvenient since the data is gzip-encoded and i'm kind of lazy extracting that from the stream. Chromium does seem to auto-detect it as utf8 according to the menus however... not sure what's going on here. I would focus on the following error however, since it's clearly emanating from the CGI... --[[anarcat]]
+
+Clicking on the Cancel button yields the following warning:
+
+~~~~
+Error: Cannot decode string with wide characters at /usr/lib/x86_64-linux-gnu/perl/5.20/Encode.pm line 215.
+~~~~
+
+> Looks as though you might be able to get a Python-style backtrace for this
+> by setting `$Carp::Verbose = 1`.
+>
+> The error is that we're taking some string (which string? only a backtrace
+> would tell you) that is already flagged as Unicode, and trying to decode
+> it from byte-blob to Unicode again, analogous to this Python:
+>
+>     some_bytes.decode('utf-8').decode('utf-8')
+>
+> --[[smcv]]
+> > 
+> > I couldn't figure out where to set that Carp thing - it doesn't work simply by setting it in /usr/bin/ikiwiki - so i am not sure how to use this. However, with some debugging code in Encode.pm, i was able to find a case of double-encoding - in the left menu, for example, which is the source of the Encode.pm crash.
+> > 
+> > It seems that some unicode semantics changed in Perl 5.20, or more precisely, in Encode.pm 2.53, according to [this](https://code.activestate.com/lists/perl-unicode/3314/). 5.20 does have significant Unicode changes, but I am not sure they are related (see [perldelta](https://metacpan.org/pod/distribution/perl/pod/perldelta.pod)). Doing more archeology, it seems that Encode.pm is indeed where the problem started, all the way back in [commit 8005a82](https://github.com/dankogai/p5-encode/commit/8005a82d8aa83024d72b14e66d9eb97d82029eeb#diff-f3330aa405ffb7e3fec2395c1fc953ac) (august 2013), taken from [pull request #11](https://github.com/dankogai/p5-encode/pull/11) which expressively forbids double-decoding, in effect failing like python does in the above example you gave (Perl used to silently succeed instead, a rather big change if you ask me).
+> > 
+> > So stepping back, it seems that this would be a bug in Ikiwiki. It could be in any of those places:
+> > 
+> > ~~~~
+> > anarcat@marcos:ikiwiki$ grep -r decode_utf8 IkiWiki* | wc -l
+> > 31
+> > ~~~~
+> > 
+> > Now the fun part is to determine which one should be turned off... or should we duplicate the logic that was removed in decode_utf8, or make a safe_decode_utf8 for ourselves? --[[anarcat]]
+
+The apache logs yield:
+
+~~~~
+[Mon Sep 08 16:17:43.995827 2014] [cgi:error] [pid 2609] [client 192.168.0.3:47445] AH01215: Died at /usr/share/perl5/IkiWiki/CGI.pm line 467., referer: http://anarc.at/ikiwiki.cgi?do=edit&page=wishlist
+~~~~
+
+Interestingly enough, I can't reproduce the bug here (at least in this page). Also, editing the page through git works fine.
+
+I had put ikiwiki on hold during the last upgrade, so it was upgraded separately. The bug happens both with 3.20140613 and 3.20140831. The major thing that happened today is the upgrade from perl 5.18 to 5.20. Here's the output of `egrep '[0-9] (remove|purge|install|upgrade)' /var/log/dpkg.log | pastebinit -b paste.debian.net` to give an idea of what was upgraded today:
+
+http://paste.debian.net/plain/119944
+
+This is a major bug which should probably be fixed before jessie, yet i can't seem to find a severity statement in reportbug that would justify blocking the release based on this - unless we consider non-english speakers as "most" users (i don't know the demographics well enough). It certainly makes ikiwiki completely unusable for my users that operate on the web interface in french... --[[anarcat]]
+
+Note that on this one page, i can't even get the textarea to display and i immediately get `Error: Cannot decode string with wide characters at /usr/lib/x86_64-linux-gnu/perl/5.20/Encode.pm line 215`: http://anarc.at/ikiwiki.cgi?do=edit&page=hardware%2Fserver%2Fmarcos.
+
+Also note that this is the same as [[forum/"Error: cannot decode string with wide characters" on Mageia Linux x86-64 Cauldron]], I believe. The backtrace I get here is:
+
+~~~~
+Error: Cannot decode string with wide characters at /usr/lib/x86_64-linux-gnu/perl/5.20/Encode.pm line 215. Encode::decode_utf8("**Menu**\x{d}\x{a}\x{d}\x{a} * [[\x{fffd} propos|index]]\x{d}\x{a} * [[Logiciels|software]]"...)
+called at /usr/share/perl5/IkiWiki/CGI.pm line 117 IkiWiki::decode_form_utf8(CGI::FormBuilder=HASH(0x2ad63b8))
+called at /usr/share/perl5/IkiWiki/Plugin/editpage.pm line 90 IkiWiki::cgi_editpage(CGI=HASH(0xd514f8), CGI::Session=HASH(0x27797e0))
+called at /usr/share/perl5/IkiWiki/CGI.pm line 443 IkiWiki::__ANON__(CODE(0xfaa460))
+called at /usr/share/perl5/IkiWiki.pm line 2101 IkiWiki::run_hooks("sessioncgi", CODE(0x2520138))
+called at /usr/share/perl5/IkiWiki/CGI.pm line 443 IkiWiki::cgi()
+called at /usr/bin/ikiwiki line 192 eval {...}
+called at /usr/bin/ikiwiki line 192 IkiWiki::main()
+called at /usr/bin/ikiwiki line 231
+~~~~
+
+so this would explain the error on cancel, but doesn't explain the weird encoding i get when editing the page... <sigh>...
+
+... and that leads me to this crazy patch which fixes all the above issue, by avoiding double-decoding... go figure that shit out...
+
+[[!template  id=gitbranch branch=anarcat/dev/safe_unicode author="[[anarcat]]"]] 
+
+> [[Looks good to me|users/smcv/ready]] although I'm not sure how valuable
+> the `$] < 5.02 || ` test is - I'd be tempted to just call `is_utf8`. --[[smcv]]
+
+>> [[merged|done]] --[[smcv]]
index c535f88a400c2840b73ac5aedab0e0fe896e1b38..6425c1ece829146eec6bfe76027532383b5a3a87 100644 (file)
@@ -1 +1,49 @@
 If you use the rescaling feature of the directive [[ikiwiki/directive/img/]] with a smaller image it will distort. E.g. an image with 150x250 rescaled into size=200x200. --bastla
+
+> More specifically: `img` normally preserves aspect ratio:
+> `size=200x200` normally means "as large as possible, keeping
+> the width 200px or less, the height 200px or less, and the
+> aspect ratio correct". So a 4:3 image with `size=200x200`
+> would actually come out 200px wide and 150px tall.
+>
+> However, when (desired width is specified) && (desired height is specified)
+> && ((width > desired width) || (height > desired height)),
+> it uses exactly the desired size, without preserving aspect ratio.
+> --smcv
+
+>> [[!template id=gitbranch branch=chrysn/imgforpdf-and-more author="[[chrysn]]"]]
+>>
+>> [[!tag patch]]
+>>
+>> i've implemented a fix for this along with a unit test.
+>>
+>> the patch branch is based on the imgforpdf branch
+>> ([[bugs/svg and pdf conversion fails]]), because it would not cleanly merge.
+>> the  branch also enhances on how images are handled in preview, falling back
+>> to data: urls if the image has not been rendered in a saved version. please
+>> review. --[[chrysn]]
+
+>>> Mostly [[looks good to me|users/smcv/ready]].
+>>>
+>>> Minor things, which wouldn't stop me merging it if I could:
+>>>
+>>> * `$imgdatalink = "data:image/".$im->Get("magick").";base64,".encode_base64($blob[0]);`:
+>>>   is the ImageMagick file type always valid as the second part of
+>>>   a MIME type?
+>>> * In this code:
+>>>
+>>>       +open (my $outhtmlfd, "<", "$outpath.html");
+>>>       +local $/=undef;
+>>>       +my $outhtml = <$outhtmlfd>;
+>>>       +close $outhtmlfd;
+>>>
+>>>   no block is closed, so the "local" is ineffective, so the `<>` operator
+>>>   remains in read-entire-file mode afterwards. To avoid odd side-effects,
+>>>   I would suggest using `readfile()` like `t/trail.t` does.
+>>>
+>>> [[!template id=gitbranch branch=smcv/ready/imgforpdf-and-more author="[[chrysn]], [[smcv]]"
+      browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/imgforpdf-and-more]]
+>>> I've used `readfile()` (but not done anything about the ImageMagick file type)
+>>> in my copy of the branch.
+>>>
+>>> --[[smcv]]
index 75b917163438aa7e3c5280917e887820112efa83..14164d0761edecfa6a55c048e882869fb1918493 100644 (file)
@@ -17,9 +17,7 @@ the attached [[!taglink patch]] fixes this; from its commit message:
 
 the output will look much better (at least in my wikis) with the "[[bugs/pagetitle function does not respect meta titles]]" issue fixed.
 
-> I agree that it's (likely to be) a bug to not use `pagetitle()`. I
-> haven't reviewed this particular implementation yet but I'll try to
-> do that soon.
+> [[Looks good to me|users/smcv/ready]].
 >
 > I don't think it's correct for `pagetitle()` to output `\[[!meta title]]`
 > though, as discussed on the linked bug: it appears in an assortment of
index 9ff36b98df32a4efad497d6db2f99248ebe023c7..dd5016619588e2d177efcdc7e521187b876d5c24 100644 (file)
@@ -67,3 +67,25 @@ Any other ideas? --[[anarcat]]
 > Note: it seems that my email *is* given by my OpenID provider, no idea why this is not working, but the fix proposed in my branch works. --[[anarcat]]
 
 >> Note: this is one of two patches i need to apply at every upgrade. The other being [[can__39__t_upload_a_simple_png_image:_prohibited_by_allowed__95__attachments___40__file_MIME_type_is_application__47__octet-stream...]]. --[[anarcat]]
+
+>>> Is there any sort of check that the owner of the given email address
+>>> wants to receive email from us, or way for the owner of that email
+>>> address to stop getting the emails?
+>>>
+>>> With passwordauth, if someone maliciously subscribes my email
+>>> address to high-traffic pages or something (by using it as the
+>>> email address of their wiki login), I can at least use
+>>> password-recovery to hijack their account and unsubscribe myself.
+>>> If they're signing in with an OpenID not associated with my
+>>> email address and then changing the email address in the userdb
+>>> to point to me, I don't think I can do that.
+>>>
+>>> With OpenID, I think we're just trusting that the OpenID provider
+>>> wouldn't give us an unverified email address, which also seems
+>>> a little unwise.
+>>>
+>>> It might be better to give ikiwiki a concept of verifying an
+>>> email address (the usual send-magic-token flow) and only be
+>>> willing to send notifications to a verified address?
+>>>
+>>> --[[smcv]]
index ec22f0c78e6a732190c3f08c4ee8237783939067..073c10d14bb492089d8aa62c19d191acddd5010e 100644 (file)
@@ -4,6 +4,37 @@ On some ikiwikis that I run, I get the following error on OpenID logins:
 
 > Is this fixed now that [[!debbug 738493]] has been fixed? --[[smcv]]
 
+> > No, it isn't. I still get: `no_identity_server: Could not determine ID provider from URL.` from the latest ikiwiki in jessie (3.20140831), with liblwpx-paranoidagent-perl 1.10-3. Debugging tells me it's still related to the `500 Can't verify SSL peers without knowing which Certificate Authorities to trust` error, so probably because `Mozilla::CA` is not packaged ([[!debbug 702124]]). I still had to apply the patch to disable SSL verification at the end of this file. However, setting `$ENV{PERL_LWP_SSL_CA_PATH} = '/etc/ssl/certs';` seems to work now, so the following dumb patch works:
+> > 
+> > ~~~~
+> > --- /usr/bin/ikiwiki.orig       2014-09-08 15:48:35.715868902 -0400
+> > +++ /usr/bin/ikiwiki    2014-09-08 15:50:29.666779878 -0400
+> > @@ -225,4 +225,5 @@
+> >         }
+> >  }
+> > 
+> > +$ENV{PERL_LWP_SSL_CA_PATH} = '/etc/ssl/certs';
+> >  main;
+> > ~~~~
+> > 
+> > may not be the best place to fiddle around with this, but then again it makes sense that it applies to the whole program. it should probably be reported upstream as well. also in my git repo. -- [[anarcat]]
+> >
+> > > This seems Debian-specific. I would be inclined to consider this to be
+> > > a packaging/system-integration (i.e. non-upstream) bug in
+> > > `liblwpx-paranoidagent-perl` rather than an upstream bug in IkiWiki;
+> > > it certainly seems inappropriate to put this Debian-specific path
+> > > in upstream IkiWiki. If it can't be fixed in LWPX::ParanoidAgent for
+> > > whatever reason, applying it via some sort of sed in ikiwiki's
+> > > `debian/rules` might be more reasonable? --[[smcv]]
+> > >
+> > > > by "upstream", i did mean `liblwpx-paranoidagent-perl`. so yeah, maybe this should be punted back into that package's court again. :( --[[anarcat]]
+> > > > 
+> > > > done, by bumping the severity of [[!debbug 744404]] to release-criticial. --[[anarcat]]
+> > > > 
+> > > > > ooh cool, the bug was fixed already with an upload, so this should probably be considered [[done]] at this point, even without the patch below! great! -- [[anarcat]]
+
+[[!template  id=gitbranch branch=anarcat/dev/ssl_ca_path author="[[anarcat]]"]] 
+
 I seem recall having that error before, and fixing it, but it always seems to come back and I forget how to fix it. So I'll just open this bug and document it if i can figure it out... -- [[users/anarcat]]
 
 The Perl module manual says:
@@ -157,18 +188,13 @@ Workaround - disable error checking:
 > My only workaround for now was to fix `PERL_LWP_SSL_VERIFY_HOSTNAME` to 0 directly in `ikiwiki` :-(  -- [[users/bbb]]
 
 ~~~~
-*** /home/bruno/opt/ikiwiki/bin/ikiwiki.bad     2014-04-17 15:41:38.868972152 +0200
---- /home/bruno/opt/ikiwiki/bin/ikiwiki 2014-04-17 15:04:56.524996905 +0200
-*************** sub main () {
-*** 226,229 ****
-        }
-  }
-  
-! main;
---- 226,229 ----
+--- /usr/bin/ikiwiki.orig       2014-09-08 15:48:35.715868902 -0400
++++ /usr/bin/ikiwiki    2014-09-08 15:48:38.895947911 -0400
+@@ -225,4 +225,5 @@
         }
-  }
-  
-! $ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0 ; main;
+ }
+
++$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0;
+ main;
 ~~~~
 
index 488fa00667ccc6cb8578e7c86a7c2bdc0a9e69d5..bb6cd17d3f28404eb489bb670172665cd0015d8f 100644 (file)
@@ -1,6 +1,6 @@
 [[!template id=gitbranch branch=smcv/ready/comments author="[[smcv]]"
 browse="http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/comments"]]
-[[!tag patch]]
+[[!tag patch users/smcv/ready]]
 
 The ability to post comments depends on several factors:
 
index 807d6b7ef4e50e13a75a4d144e99afd48823e78e..7cf92af572c58a0f642d29f526b79e5c4a27ef69 100644 (file)
@@ -18,6 +18,6 @@ index 75c9579..ad0f8b0 100644
 
 [[!tag patch]]
 
-> [[Seems reasonable|users/smcv/yesplease]] --smcv
+> [[Seems reasonable|users/smcv/ready]] --smcv
 
 >> [[done]] --[[Joey]]
index fa702a22c41a7e7a3a4e1e6babcb194b290ae4f8..cc6d11de7a6c08eacda2625a5ef3bdbd05f740d9 100644 (file)
@@ -1,4 +1,6 @@
 [[!template  id=gitbranch branch=chrysn/more-proxy-utf8-fail author="[[chrysn]]"]]
+[[!template id=gitbranch author="[[chrysn]], [[smcv]]" branch=smcv/ready/more-proxy-utf8-fail
+  browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/more-proxy-utf8-fail]]
 
 the recently introduced fixes for [[crashes in the python proxy even if disabled]]
 caused the typical python2 implicit conversion failures ("'ascii' codec
@@ -52,3 +54,15 @@ patch.
 >>> a `unicode`. (i'd happily ditch python2 and port all plugins to python3,
 >>> where this is all easier, but my [[todo/vCard rendering]] still uses an
 >>> ancient module.) --[[chrysn]]
+
+>>>> You were right about this, `encode` is appropriate to go from `unicode`
+>>>> to `str` under Python 2. However, Python 3 is still broken.
+>>>>
+>>>> My `ready/more-proxy-utf8-fail` branch, based on yours,
+>>>> [[fixes the `rst` test when run under Python 3|bugs/rst_plugin_hangs_when_used_with_Python_3]]
+>>>> and hopefully also fixes this one. Please check that it still
+>>>> fixes your test-case too.
+>>>>
+>>>> Joey, I think this is [[ready for merge|users/smcv/ready]] even if it
+>>>> doesn't fix chrysn's bug - it does fix Python 3 support
+>>>> in general. --[[smcv]]
index 6296c3df125565bfb7975eacfa71684f40a0ed9a..87f6a67e7658e7652dba9eeac988889344029f53 100644 (file)
@@ -24,3 +24,30 @@ then the following command should print 302
 > In current ikiwiki, you can get a broadly similar effect by either
 > using \[[!meta redir=foo]] (which does a HTML `<meta>` redirect)
 > or reconfiguring the web server. --[[smcv]]
+
+>> The CGI spec (http://www.ietf.org/rfc/rfc3875) says that a CGI can cause a redirect by returning a Location: header.
+>> So it's possible; desirable (due to your point about conflicting with git-annex support) is a different matter.
+
+>>> One of the major things that separates ikiwiki from other wiki software
+>>> is that ikiwiki is a wiki compiler: ordinary page-views are purely
+>>> static HTML, and the CGI only gets involved when you do something
+>>> that really has to be dynamic (like an edit).
+>>>
+>>> However, there is no server-independent static content that ikiwiki
+>>> could write out to the destdir that would result in that redirect.
+>>>
+>>> If you're OK with requiring the [[plugins/404]] plugin (and a
+>>> web server where it works, which I think still means Apache) then
+>>> it would be possible to write a plugin that detected symlinks,
+>>> stored them in the `%wikistate`, and used them to make the
+>>> [[plugins/404]] plugin (or its own hook similar to the one
+>>> in that plugin) do a 302 redirect instead of a 404.
+>>> Similarly, a plugin that assumed a suitable Apache
+>>> configuration with fairly broad `AllowOverrides`,
+>>> and wrote out `.htaccess` files, would be a feasible thing
+>>> for someone to write.
+>>>
+>>> I don't think this is a bug; I think it's a request for a
+>>> feature that not everyone will want. The solution to those
+>>> is for someone who wants the feature to
+>>> [[write a plugin|plugins/write]]. --[[smcv]]
index ff2a41c0719a2bb62cd4cd23b13fc026fb0cdd7e..1893e708923bdd34e206abdaa203b16c745adf9a 100644 (file)
@@ -36,5 +36,5 @@ name, repr(ret))` (which should not hurt since it's a message
 for debugging purposes only).
 
 
-> this is fixed in commit [154c4ea9](http://source.ikiwiki.branchable.com/?p=source.git;a=commit;h=154c4ea9e65d033756330a7f8c5c0fa285380bf0)
+> this is [[fixed|done]] in commit [154c4ea9](http://source.ikiwiki.branchable.com/?p=source.git;a=commit;h=154c4ea9e65d033756330a7f8c5c0fa285380bf0)
 >  (november 2013), which is included in 3.20140227. --[[chrysn]]
diff --git a/doc/bugs/rst_plugin_hangs_when_used_with_Python_3.mdwn b/doc/bugs/rst_plugin_hangs_when_used_with_Python_3.mdwn
new file mode 100644 (file)
index 0000000..ca0738a
--- /dev/null
@@ -0,0 +1,35 @@
+During ikiwiki make phase the rst process hangs:  
+[ps output](http://dpaste.com/21TQQKT)  
+[gdb backtrace 1](http://dpaste.com/0VQBW6D)   
+[gdb backtrace 1](http://dpaste.com/1VHS88Y)  
+  
+working with python 2.7  
+[http://dpaste.com/0985A91](http://dpaste.com/0985A91)  
+not working with python3.3~3.4  
+[http://dpaste.com/0ACNK3W](http://dpaste.com/0ACNK3W)  
+  
+> Retitled this bug report since it seems to be specific to Python 3.
+>
+> The `rst` plugin is probably more commonly used with Python 2.
+> It seems likely that there is some Python-3-specific bug in `proxy.py`,
+> perhaps introduced by [commit 154c4ea
+ "properly encode and decode from/to utf8 when sending rpc to ikiwiki"](
+http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=154c4ea9e65d033756330a7f8c5c0fa285380bf0).
+>
+> I can reproduce this on Debian by installing `python3-docutils`
+> and changing the first line of `plugins/proxy.py`, the first
+> line of `plugins/pythondemo`, the first line of `plugins/rst`
+> and the `system()` call in `t/rst.t` to use `python3` instead
+> of `python`. --[[smcv]]
+
+looks like the problem is in proxy.py  
+ml = _IkiWikiExtPluginXMLRPCHandler._read(in_fd).decode('utf8')  
+
+without decode('utf8') is working
+
+> That call was introduced
+> [[to fix a bug under Python 2|bugs/crashes_in_the_python_proxy_even_if_disabled]]
+> so it cannot just be removed, but I've put a proposed branch on
+> [[this related bug|bugs/pythonproxy-utf8_again]]. [[!tag patch]] --smcv
+
+tested and fixed with patch [http://git.pseudorandom.co.uk/smcv/ikiwiki.git/commitdiff/38bd51bc1bab0cabd97dfe3cb598220a2c02550a](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/commitdiff/38bd51bc1bab0cabd97dfe3cb598220a2c02550a) and patch [http://git.pseudorandom.co.uk/smcv/ikiwiki.git/commitdiff/81506fae8a6d5360f6d830b0e07190e60a7efd1c](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/commitdiff/81506fae8a6d5360f6d830b0e07190e60a7efd1c)
index da241b4bcc1948ee15bb88513a5ad699039e01ef..ac18fe8aa31c42cae33218b97d187d685d10a6f9 100644 (file)
@@ -25,3 +25,34 @@ should be safe for inclusion.
 > meantime, i noticed that the desired effect doesn't happen when no explicit
 > size is set. as scalable graphics don't necessarily have a natural size
 > anyway, i don't consider that a showstopper. --[[chrysn]]
+
+>> This all looks good in principle, but I would like to do a more detailed
+>> review, and test it with "real ImageMagick" in case its behaviour differs
+>> from GraphicsMagick.
+>>
+>> An automated regression test for the desired behaviour in `t/` would
+>> be great. There are SVGs and PNGs in the docwiki already; there are no
+>> JPEGs or PDFs, but perhaps you could add a trivially small example
+>> of each to `t/`? Imitating `t/tag.t` or `t/trail.t`, and skipping the
+>> test if the required modules are missing like `t/podcast.t` does,
+>> seems like it would work best.
+>>
+>> I agree that everything not in an interoperable web format should be
+>> converted to PNG when it's scaled down, but yes, that's more likely
+>> to be a breaking change, so it seems best to do that as a separate
+>> branch. In practice I think this means JPEG -> JPEG and everything
+>> else -> PNG, since JPEG is commonly used for photos and photo-like
+>> images that don't compress well under lossless compression. --[[smcv]]
+
+>>> i've added a unit test and tested it with the [[!debsid perlmagick]]
+>>> package, the [[!debsid graphicsmagick-libmagick-dev-compat]] package and
+>>> the experimental [[!debpts libimage-magick-perl]] package (where the
+>>> [[!debpts libmagickcore-6.q16-2-extra]] package is required too), in the
+>>> meantime filing [[!debbug 753770]]. (why is it that it sometime seems i
+>>> find more bugs in ikiwiki's dependencies than in itself when working with
+>>> it?)
+>>>
+>>> the unit test also checks for file removal when it is not created any more,
+>>> which works, so my biggest fear about the all-to-png change is unwarranted.
+>>> i'll have a look at that some time, but i think as things are, this is
+>>> ready now, please review again. --[[chrysn]]
index aae75a3048a4f091796dd97be5196f3bf4f606db..d1fb788f5287878f28910e6a1def1e0336e18cd1 100644 (file)
@@ -198,7 +198,7 @@ Please, let me know what to do to avoid this kind of error.
 
 [[!template id=gitbranch author="[[smcv]]" branch=smcv/ready/templatebody
   browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/templatebody]]
-[[!tag patch]]
+[[!tag patch users/smcv/ready]]
 Branch and directive renamed to `ready/templatebody` as chrysn suggested.
 It's on-by-default now (or will be if that branch is merged).
 Joey, any chance you could review this?
@@ -255,3 +255,16 @@ same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
 >>> is a start towards that; the docwiki builds successfully, but
 >>> the tests that use IkiWiki internals also need updating to
 >>> set `$phase = PHASE_RENDER` before they start preprocessing. --s
+
+>>>> reviewing those modifications, i think this is a good way to go. along
+>>>> with warning about pagespecs evaluated in scan phase, i think it should be
+>>>> an error to invoke scan in the render phase; that would mean that
+>>>> `readtemplate` needs to check whether it's invoked as a scan or not to
+>>>> decide whether to scan the template page, but would be generally more
+>>>> robust for future plugin writing.
+>>>>
+>>>> **addendum**: if the new phase state is used to create warnings/errors
+>>>> about improper ikiwiki api use of plugins (which is something i'd
+>>>> advocate), that should likewise warn if `add_link` actually adds a link in
+>>>> the render phase.  such a warning would have helped spotting the
+>>>> link-related [[template evaluation oddities]] earlier. --[[chrysn]]
diff --git a/doc/bugs/template_evaluation_oddities.mdwn b/doc/bugs/template_evaluation_oddities.mdwn
new file mode 100644 (file)
index 0000000..06ef573
--- /dev/null
@@ -0,0 +1,67 @@
+[[ikiwiki/directive/template]]s expose odd behavior when it comes to composing
+links and directives:
+
+* the parameters are passed through the preprocessor twice, once on
+  per-parameter basis and once for the final result (which usually contains the
+  preprocessed parameters).
+
+  one of the results it that you have to write:
+
+      \[[!template id="infobox" body="""
+          Just use the \\\[[!template]] directive!
+      """]]
+
+  (that'd be three backslashes in front of the opening [.)
+
+  <!-- if you read this and wonder why there are only three backslashes in the
+  source code too, look at how backslash-escaping directives is implemented.
+  -->
+
+  this also means that parts which are not used by the template at all still
+  have their side effects without showing.
+
+  furthermore, the evaluation sequence is hard to predict. this might or might
+  not be a problem, depending on whether someone comes up with a less contrived
+  example (this one assumes a ``\[[!literal value]]`` directive that just
+  returns value but protects it from the preprocessor):
+
+  we can use `\[[!literal """[[!invalid example]]"""]]`, but we can't use
+  `\[[!template id=literalator value="""[[!invalid example]]"""]]` with a
+  'literalator' template `<span class="literal">\[[!literal """<TMPL_VAR
+  value>"""]]</span>` because then the `invalid` directive comes to action in
+  the first (per-argument) preprocessor run
+
+* links in templates are not stored at all; they appear, but the backlinks
+  don't work unless the link is explicit in one of the arguments.
+
+      \[[!template id="linker" destination="foo"]]
+
+  with a 'linker' template like
+
+      Go to \[[<TMPL_VAR destination>]]!
+
+  would result in a link to 'destination', but would not be registered in the
+  scan phase and thus not show a backlink from 'foo'.
+
+  (a ``\[[!link to=...]]`` directive, as suggested in
+  [[todo/flexible relationships between pages]], does get evaluated properly
+  though.)
+
+  this seems to be due to linkification being called before preprocess rather
+  than as a part of it, or (if that is on purpose) by the template plugin not
+  running linkification as an extra step (not even once).
+
+(nb: there is a way to include the ``raw_`` value of a directive, but that only
+refers to htmlification, not directive evaluation.)
+
+both those behaviors are non-intuitive and afaict undocumented. personally, i'd
+swap them out for passing the parameters as-is to the template, then running
+the linkifier and preprocessor on the final result. that would be as if all
+parameters were queried `raw_` -- then again, i don't see where `raw_` makes
+anything not work that worked originally, so obviously i'm missing something.
+
+
+i think it boils down to one question: are those behaviors necessary for
+compatibility reasons, and if yes, why?
+
+--[[chrysn]]
diff --git a/doc/bugs/trails_depend_on_everything.mdwn b/doc/bugs/trails_depend_on_everything.mdwn
new file mode 100644 (file)
index 0000000..babb1e3
--- /dev/null
@@ -0,0 +1,14 @@
+[[!template id=gitbranch branch=smcv/ready/trail-sort
+author="[[Simon McVittie|smcv]]"
+browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/trail-sort]]
+[[!tag patch users/smcv/ready]]
+
+On [[trail's discussion page|plugins/trail/discussion]], [[kjs]] pointed out
+that [[plugins/trail]] and [[plugins/contrib/album]] get excessive
+dependencies on `internal(*)`. I tracked this down to their (ab)use of
+`pagespec_match_list` with the pagespec `internal(*)` to sort a pre-existing
+list of pages.
+
+They should just sort the pages instead; they'll already have all the
+dependencies they need. My branch adds `IkiWiki::sort_pages` but does not
+make it plugin API just yet. --[[smcv]]
index 702608831bb618b2e430eacc239312efc4f548bc..0673aa6740dfb900eb395f4a95140b6434a34ffd 100644 (file)
@@ -6,9 +6,11 @@
 
 Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-test/rendered/tag/index.html` exist?
 
-[[!tag patch]]
-[[!template id=gitbranch branch=smcv/ready/autoindex author=smcv]]
-[[!template id=gitbranch branch=smcv/ready/autoindex-more-often author=smcv]]
+[[!tag patch users/smcv/ready]]
+[[!template id=gitbranch branch=smcv/ready/autoindex author=smcv
+  browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/autoindex]]
+[[!template id=gitbranch branch=smcv/ready/autoindex-more-often author=smcv
+  browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/autoindex-more-often]]
 
 > To have a starting point to (maybe) change this, my `ready/autoindex`
 > branch adds a regression test for the current behaviour, both with
@@ -29,3 +31,44 @@ Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-te
 > git repositories any more? My `autoindex-more` branch changes
 > the logic so it will do what you want in the `autoindex_commit => 0`
 > case, and amends the appropriate regression test. --[[smcv]]
+
+>> the autoindex-more-often branch looks good to me in general.
+>>
+>> i do have doubts about the 3ba2ef1a patch ("remove unnecessary special case
+>> for transient underlay"): now that we consider the complete transient
+>> directory as well, the sequence in which the refresh hooks are called starts
+>> to matter, and pages created by other plugins in a similar fashion as by
+>> autoindex will only be included the next time refresh gets called.
+>>
+>> *addendum:* i just found where i discussed the issue of fighting transient
+>> pages last, it was on [[todo/alias directive]]. the example cited there
+>> (conflicts with autotag) would probably work here as well. (imagine a
+>> `tags/project/completed` and a `tags/project/inprogress` exist, and a page
+>> is tagge `tags/project`. will that be an autoindex or an autotag?)
+>>
+>> --[[chrysn]]
+
+>>> That's a fair point. I think what happens is down to commit vs. refresh
+>>> timing.
+>>>
+>>> If pages tagged t/p/c, t/p/i and t/p are all created between one
+>>> refresh and the next, with none of those tag pages existing, I think the
+>>> answer is that they would all be autotags, because until t/p/c and
+>>> t/p/i are created, there's no reason to need t/p as an autoindex.
+>>>
+>>> If there were already pages tagged t/p/c and t/p/i at the previous
+>>> refresh, then t/p would already be an autoindex, and that's a
+>>> valid page, so autotagging wouldn't touch it.
+>>>
+>>> I can't see much reason to prefer one over the other; the ideal answer
+>>> is probably to have a tag-cloud *and* a list of child pages, but this
+>>> seems a weird enough thing to do that I'd be OK with a wiki user
+>>> having to disambiguate it themselves. "Whichever automatic process
+>>> happens first, happens" is at least easy to explain, and I consider
+>>> both autoindices and autotags to be time-saving conveniences rather
+>>> than something fundamental. --s
+
+>>>> i think a behavior that does the right thing when there is a right thing
+>>>> and *something* when there is ambiguity is ok for now; especially, it's
+>>>> not up to the autoindex branch to come up with a solution to the general
+>>>> problem. --[[chrysn]]
index 4d1b495c6a22c562ae1fe063f35100d80c1dd12a..376f81b8baa1aea797541d5cc7e794400381926b 100644 (file)
@@ -48,6 +48,8 @@ gnomes will convert them to css files..)
   templates.
   [[!meta stylesheet="bma"]]
 
+* ** http://blog.lastlog.de/, contributed by joachim schiele; please feel free to copy.
+
 * **[blankoblues.css][1]**, contributed by [[Blanko]]. Can be seen on [Blankoblues Demo][2]. Local.css and templates available [here][3].
 
 * **[contraste.css][4]**, contributed by [[Blanko]]. Can be seen on [Contraste Demo][5]. Local.css and templates available [here][6].
diff --git a/doc/forum/Right-to-left_support.mdwn b/doc/forum/Right-to-left_support.mdwn
new file mode 100644 (file)
index 0000000..7ca4f9a
--- /dev/null
@@ -0,0 +1,15 @@
+Does ikiwiki support RTL languages? I read somewhere it does, but I don't see
+any mention of that here (or anywhere else... that info may be wrong).
+
+I'd like to add RTL support to my wiki, for text direction and maybe for the
+page layout too. Before I edit my CSS, page.tmpl and possibly Perl for
+automatic direction setting - does ikiwiki support this in any way?
+
+On my wiki (ikiwiki version from Debian 7 stable) everything is aligned to
+the left, and unicode RTL characters cannot change that - the .tmpl and
+css files would need to be changed, it seems.
+
+I will happily share my insights and code, if I manage to get anything
+useful to work :-)
+
+--[[fr33domlover]]
diff --git a/doc/forum/Right-to-left_support/comment_1_5b2bf4d037ae8db940296e6f58884927._comment b/doc/forum/Right-to-left_support/comment_1_5b2bf4d037ae8db940296e6f58884927._comment
new file mode 100644 (file)
index 0000000..1e9558f
--- /dev/null
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmfcr1X7TXwuCju7vCBG6vii455SX1Qxro"
+ nickname="Mesar"
+ subject="comment 1"
+ date="2014-08-30T17:53:53Z"
+ content="""
+Hi,
+
+You need ikiwiki 3.20140227 or newer, which includes the patch to expose the language code/direction see [[todo/expose_html_language_and_direction/]]
+After which you need to modify the templates to make use of the tags.
+
+I'm currently running this on http://addons.nvda-project.org
+The config/templates can be [found here](https://bitbucket.org/nvdaaddonteam/ikiwiki-ctl)
+
+I haven't investigated how this functions when the po plugin is disabled, but I am guessing that you can simply enable the po plugin, define your master language, and miss out any slave languages.
+
+I would be intrested to hear feedback/what you got to work, as we are a bunch of blind people running the project above, so the correct markup was the goal in our case, I haven't had any feedback on its visual appearance.
+
+
+--[[mhameed]]
+"""]]
diff --git a/doc/forum/Spaces_in_URLs.mdwn b/doc/forum/Spaces_in_URLs.mdwn
new file mode 100644 (file)
index 0000000..4749f4d
--- /dev/null
@@ -0,0 +1,14 @@
+There is one file on my site that had a space in the name;
+on my old site, this link worked:
+[http://dada.pink/scarsdale/Statement 20140527.pdf](http://dada.pink/scarsdale/Statement 20140527.pdf)
+
+Now that I've moved to Ikiwiki, that doesn't work. So I moved the file here:
+[http://dada.pink/scarsdale/Statement_20140527.pdf](http://dada.pink/scarsdale/Statement_20140527.pdf)
+
+Is there a better approach to maintaining this link than setting an alias in Apache?
+
+> You can add the space character to the `wiki_file_chars` argument in your setup file. -- [[Jon]]
+
+>> a space character is not allowed in a url; user agents that read one usually represent it in percent encoded form (`%20`). if you use that, things also work for direct links, which i assume caused the problem (for both the links in the original description render correctly): `\[[http://dada.pink/scarsdale/Statement%2020140527.pdf]]` renders [[http://dada.pink/scarsdale/Statement%2020140527.pdf]].
+>>
+>> spaces are allowed in internal pages because wiki page names are not urls per se but converted using conversion rules -- this allows people to not think about url rules and just link to pages, but when you're linking outside ikiwiki, some strings just aren't valid urls. --[[chrysn]]
diff --git a/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
new file mode 100644 (file)
index 0000000..decaaa1
--- /dev/null
@@ -0,0 +1,47 @@
+I'm using the trail plugin with the actiontabs theme, and the prev/next links
+seem to appear in a strange way on the page.
+
+I use modified CSS, but it changes just the colors and some font sizes.
+Nothing related to positions and trails.
+
+Here's an example - the top prev/next links appear above the action tabs.
+Is this normal? I'm using the ikiwiki version from Debian 7 stable.
+
+- If you use OpenNIC: <http://www.partager.null/tools/systems/admin-guides/ssl/Preparing_the_Tools/>
+- If you don't (will work only until the IP changes): <http://85.65.55.38/tools/systems/admin-guides/ssl/Preparing_the_Tools/>
+
+I can look at the CSS and try to figure this out, but I don't know much CSS or
+how the trail plugin works. If anyone uses trails, especially with actiontabs, and
+can help me - it will be great.
+
+Thanks in advance!
+
+--[[fr33domlover]]
+
+> I looked at the file *page.tmpl* and it seems I may be able to change
+> the trail link location if I edit that file. Would it be a good/possible solution to
+> edit it and put it in the git repo to be used instead of the default one?
+>
+> --[[fr33domlover]]
+
+>> That's how I intended trails to look with actiontabs:
+>> <http://actiontabs.hosted.pseudorandom.co.uk/posts/second_post/> is
+>> another example.
+>>
+>> With the way the actiontabs theme works, if you want to move the
+>> trail bits down into the content area (white background in the
+>> unedited theme) you might have to alter both `page.tmpl`
+>> and the actiontabs CSS. You'll see that the actiontabs CSS
+>> has a special case for trails, because the tabs and the trail
+>> links would overlap otherwise - you might have to remove
+>> that special case. --[[smcv]]
+
+>>> Thanks, I'll try that. But I've been using those trails in the last
+>>> several hours and I'm beginning to get used to the current
+>>> layout. Maybe I'll just keep it :-)
+>>>
+>>> (Anyway the way trail links look on my wiki is valid, it's exactly
+>>> like on your link, only with different colors. I suppose it's
+>>> just a cosmetic issue then)
+>>>
+>>> --[[fr33domlover]]
diff --git a/doc/forum/Using_reverse_proxy__59___base_URL_is_http_instead_of_https/comment_5_674f56100c0682eba36cc5327fbdae4a._comment b/doc/forum/Using_reverse_proxy__59___base_URL_is_http_instead_of_https/comment_5_674f56100c0682eba36cc5327fbdae4a._comment
new file mode 100644 (file)
index 0000000..1546c67
--- /dev/null
@@ -0,0 +1,61 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk6z7Jsfi_XWfzFJNZIjYUcjgrthg4aPUU"
+ nickname="Alejandro"
+ subject="Same Trick in Apache"
+ date="2014-09-10T18:58:24Z"
+ content="""
+I got it working with Apache 2.4 and Virtual Hosts on both HTTP 1.1 and HTTPS (SNI). The procedure is somewhat analogous to the nginx procedure above. So here is my set-up in the hopes will help other avoid this pain.
+
+## Set-up
+
+    CLIENT <---- HTTPS ----> REVERSE PROXY <---- HTTP ----> IKIWIKI
+
+
+## The HTTP to HTTPS Redirect
+
+To assure that all your HTTP requests are being redirected to HTTPS I chose to use mod_rewrite because simple Redirect does not pass query parameters. You will want an HTTP VHost that will redirect with something like the one below (notice the subtle ? before query string). **Note: This will NOT re-write ikiwiki's http:// URLs (base tag, etc.)**. For that I use a content filter like you will see below. This HTTP to HTTPS redirect is required though for both security and for the /foo/?updated URI form in this set-up.
+
+<pre>
+
+&lt;VirtualHost *:80&gt;
+    ServerName imass.name
+    RewriteEngine On
+    RewriteCond %{HTTPS} off
+    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}?%{QUERY_STRING}
+    ErrorLog /var/log/imass.name-error.log
+    LogLevel warn
+    CustomLog /var/log/imass.name-access.log combined
+&lt;/VirtualHost&gt;
+
+</pre>
+
+## The SSL Virtual Host
+
+This part is a bit more tricky. First I am using SNI as I don't care for non-SNI user agents. Second, you need to use a filter that replaces all http:// to https:// before the response is set. Note that this alone won't deal with ?update so you will need the HTTP to HTTPS set-up above anyway. Third, I use HTTP Auth so I don't know if this will work with your particular Auth set-up (although it should IMHO), YMMV:
+
+<pre>
+
+&lt;VirtualHost *:443&gt;
+    ServerName imass.name
+    ProxyHTMLEnable On
+    ProxyHTMLExtended On
+    SSLEngine on
+    SSLCertificateFile XXX
+    SSLCertificateKeyFile XXX
+    SSLCertificateChainFile XXX
+    SSLOptions +StdEnvVars
+    ProxyPreserveHost On
+    ProxyHTMLURLMap http:// https://
+    ProxyPass / http://192.168.101.101/
+    ProxyPassReverse / http://192.168.101.101/
+    LogLevel warn
+    ErrorLog /var/log/imass.name-ssl-error.log
+    TransferLog \"/var/log/imass.name-ssl-access.log\"
+    CustomLog \"/var/log/imass.name-ssl-request.log\" \"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \\"%r\\" %b\"
+&lt;/VirtualHost&gt;
+
+</pre>
+
+
+
+"""]]
index 8f922596822edd1183e814f1c7a35318079ebe80..c5a91be06c7403fdec2393478034e5d2fb48b0cd 100644 (file)
@@ -18,3 +18,6 @@ Can anyone shed any light on this problem and guide me what I need to do to fix
 Regards,
 
 -- [Shlomi Fish](http://www.shlomifish.org/)
+
+> [[Merged anarcat's fix for
+this|bugs/garbled non-ascii characters in body in web interface]] --[[smcv]]
diff --git a/doc/forum/__34__Error:_cannot_decode_string_with_wide_characters__34___on_Mageia_Linux_x86-64_Cauldron/comment_1_abf7ec7c378ab0908685d72d159e9fd2._comment b/doc/forum/__34__Error:_cannot_decode_string_with_wide_characters__34___on_Mageia_Linux_x86-64_Cauldron/comment_1_abf7ec7c378ab0908685d72d159e9fd2._comment
new file mode 100644 (file)
index 0000000..8b066b3
--- /dev/null
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ ip="72.0.72.144"
+ subject="comment 1"
+ date="2014-09-10T03:00:22Z"
+ content="""
+i had a similar issue, reported in [[bugs/garbled_non-ascii_characters_in_body_in_web_interface]]. 
+"""]]
diff --git a/doc/forum/how_to_have_a_plugin_delete_a_file.mdwn b/doc/forum/how_to_have_a_plugin_delete_a_file.mdwn
new file mode 100644 (file)
index 0000000..ea29555
--- /dev/null
@@ -0,0 +1,18 @@
+[[!meta title="How to have a plugin delete a file?"]]
+
+When using the [[plugins/contrib/jscalendar]] plugin,  it creates in the
+[[plugins/transient]] directory some files (a bit like the
+[[plugins/recentchanges]] plugin does). When the calendar that triggered
+creation of this file is removed, I would like to remove the corresponding
+page as well, but I cannot, because I get the following error.
+
+    internal error: jscalendar/90cde8dfad6413813b324a15ae2d1d95041aedd69e7be36c02b0cd4a58c4af73.jscalendar cannot be found in <path of wiki> or underlay
+
+My guess is that:
+
+* the page is stored, internally, in some list of pages to render (as it depends on the page containing the calendar that was just deleted);
+* my plugin delete this page (using `IkiWiki::prune()` or `unlink()`, in the `rendered()` or `needsbuild()` hook);
+* IkiWiki tries to render the page, but cannot (since I just deleted it), and throws the error.
+
+My question is: How can I tell IkiWiki that I *deleted* this page, and that it is no longer necessary to render it? Is there a hook in which I can safely do this?
+
diff --git a/doc/forum/how_to_have_a_plugin_delete_a_file/comment_1_061c8bca174f7155d4065dd200c0c8db._comment b/doc/forum/how_to_have_a_plugin_delete_a_file/comment_1_061c8bca174f7155d4065dd200c0c8db._comment
new file mode 100644 (file)
index 0000000..439b074
--- /dev/null
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="81.100.115.242"
+ subject="comment 1"
+ date="2014-07-21T20:15:13Z"
+ content="""
+Without actually checking the source code, I think the answer is:
+if you refrain from saying that page *x* `will_render` a file *f* that
+was previously rendered by *x*, IkiWiki will notice the difference,
+and delete *f* automatically.
+"""]]
diff --git a/doc/forum/how_to_have_a_plugin_delete_a_file/comment_2_864a20147885642ad3bbcf8400d8ee46._comment b/doc/forum/how_to_have_a_plugin_delete_a_file/comment_2_864a20147885642ad3bbcf8400d8ee46._comment
new file mode 100644 (file)
index 0000000..f22a607
--- /dev/null
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="smcv"
+ ip="81.100.115.242"
+ subject="comment 2"
+ date="2014-07-21T20:16:16Z"
+ content="""
+... and in that situation, you need to put *x* in the output of
+`needsbuild`, if it did not already have a reason to be built.
+"""]]
diff --git a/doc/ikiwiki/markdown/discussion.mdwn b/doc/ikiwiki/markdown/discussion.mdwn
new file mode 100644 (file)
index 0000000..7c0d758
--- /dev/null
@@ -0,0 +1,48 @@
+There is an ongoing [effort to standardise Markdown][sm]; I think it would be nice to check whether this implementation is compliant with it.
+
+[sm]: http://standardmarkdown.com/
+
+http://standardmarkdown.com/
+
+> IkiWiki's [[plugins/mdwn]] plugin does not contain an implementation
+> of Markdown: it relies on external libraries. It can currently use
+> any of these, most-preferred first:
+>
+> * [[!cpan Text::MultiMarkdown]], only if explicitly requested via
+>   `$config{multimarkdown}`
+> * [[!cpan Text::Markdown::Discount]], if not explicitly disabled
+>   via `$config{nodiscount}`
+> * [[!cpan Text::Markdown]]
+> * [[!cpan Markdown]]
+> * `/usr/bin/markdown`
+>
+> In practice, Discount is the implementation pulled in by the
+> Debian package dependencies, and (I suspect) the most
+> commonly used with IkiWiki.
+>
+> If the selected external library (whatever it happens to be)
+> complies with a particular interpretation of Markdown, then
+> IkiWiki will too. If not, it won't. The only influence
+> IkiWiki has over its level of compliance with a particular
+> interpretation is in how we choose which external library
+> we prefer.
+>
+> As such, if you want IkiWiki to change its interpretation of
+> Markdown, the way to do that is to either change Discount's
+> interpretation of Markdown, or contribute a patch to make
+> `mdwn.pm` prefer a different (and presumably "more compliant")
+> Markdown implementation.
+>
+> IkiWiki has one syntax extension beyond Markdown, which is
+> that text enclosed in double-square-brackets is an IkiWiki
+> [[ikiwiki/wikilink]] or [[ikiwiki/directive]]. This applies
+> to any markup language used with IkiWiki, not just Markdown.
+>
+> (There also doesn't seem to be any consensus that labelling
+> any particular fork of Markdown as "standard" can make it the 
+> truth, or that this particular fork is the Correct™ fork and not
+> just <https://xkcd.com/927/>; but that's between the authors of
+> Markdown implementations and those who want to standardize
+> Markdown, and it isn't IkiWiki's job to police that.)
+>
+> --[[smcv]]
index 34d5bb777cc89a8379ab7c2f7b1464fb4a201709..c158ec3f98a46c1574205d949430239f2796e6db 100644 (file)
@@ -10,4 +10,4 @@ log back in, try out the OpenID signup process if you don't already have an
 OpenID, and see how OpenID works for you. And let me know your feelings about
 making such a switch. --[[Joey]]
 
-[[!poll 75 "Accept only OpenID for logins" 21 "Accept only password logins" 49 "Accept both"]]
+[[!poll 76 "Accept only OpenID for logins" 21 "Accept only password logins" 49 "Accept both"]]
diff --git a/doc/news/version_3.20130904.1.mdwn b/doc/news/version_3.20130904.1.mdwn
deleted file mode 100644 (file)
index a248295..0000000
+++ /dev/null
@@ -1,3 +0,0 @@
-ikiwiki 3.20130904.1 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Fix cookiejar default setting."""]]
\ No newline at end of file
diff --git a/doc/news/version_3.20140102.mdwn b/doc/news/version_3.20140102.mdwn
deleted file mode 100644 (file)
index e101646..0000000
+++ /dev/null
@@ -1,24 +0,0 @@
-ikiwiki 3.20140102 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * aggregate: Improve display of post author.
-   * poll: Fix behavior of poll buttons when inlined.
-   * Fixed unncessary tight loop hash copy in saveindex where a pointer
-     can be used instead. Can speed up refreshes by nearly 50% in some
-     circumstances.
-   * Optimized loadindex by caching the page name in the index.
-   * Added only\_committed\_changes config setting, which speeds up wiki
-     refresh by querying git to find the files that were changed, rather
-     than looking at the work tree. Not enabled by default as it can
-     break some setups where not all files get committed to git.
-   * comments: Write pending moderation comments to the transient underlay
-     to avoid conflict with only\_committed\_changes.
-   * search: Added google\_search option, which makes it search google
-     rather than using the internal xapain database.
-     (googlesearch plugin is too hard to turn on when xapain databases
-     corrupt themselves, which happens all too frequently).
-   * osm: Remove invalid use of charset on embedded javascript tags.
-     Closes: #[731197](http://bugs.debian.org/731197)
-   * style.css: Add compatibility definitions for more block-level
-     html5 elements. Closes: #[731199](http://bugs.debian.org/731199)
-   * aggregrate: Fix several bugs in handling of empty and colliding
-     titles when generating filenames."""]]
\ No newline at end of file
diff --git a/doc/news/version_3.20140815.mdwn b/doc/news/version_3.20140815.mdwn
new file mode 100644 (file)
index 0000000..6ec3c73
--- /dev/null
@@ -0,0 +1,10 @@
+ikiwiki 3.20140815 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Add google back to openid selector. Apparently this has gotten a stay
+     of execution until April 2015. (It may continue to work until 2017.)
+   * highlight: Add compatibility with highlight 3.18, while still supporting
+     3.9+. Closes: #[757679](http://bugs.debian.org/757679)
+     Thanks, David Bremner
+   * highlight: Add support for multiple language definition directories
+     Closes: #[757680](http://bugs.debian.org/757680)
+     Thanks, David Bremner"""]]
\ No newline at end of file
diff --git a/doc/news/version_3.20140831.mdwn b/doc/news/version_3.20140831.mdwn
new file mode 100644 (file)
index 0000000..c8ea1a2
--- /dev/null
@@ -0,0 +1,3 @@
+ikiwiki 3.20140831 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * Make --no-gettime work in initial build. Closes: #[755075](http://bugs.debian.org/755075)"""]]
\ No newline at end of file
index ed57202d838390d449f9ad70d19457172e8d6bbc..5b9461d28fa3006c5a7f8ed35132882be5a8ec24 100644 (file)
@@ -1,3 +1,4 @@
+[[!meta author="spalax"]]
 [[!template id=plugin name=addtag author="[[Louis|spalax]]"]]
 [[!tag type/widget]]
 
index c2f991d5a9bb25768083a9bdd39b94fa0f537681..9fac111647a1ac6b7ef8164c8590ad4a8317dab2 100644 (file)
@@ -47,6 +47,10 @@ is to provide a direct link to the image.)
 Updated, June 2014: integrated changes from [[KathrynAndersen]],
 Lukas Lipavsky and kjs
 
+An `album6` branch is also available, but is less suitable
+for manual installation since it needs core IkiWiki changes
+(until [[bugs/trails depend on everything]] is fixed).
+
 ### Manual installation
 
 First, you need a version of ikiwiki with the [[trail]] plugin merged in
index 58c0e640fde5b0afc25f97273fe0f295dfc5f630..23ff9017d366b3d407ce6788c9bf05856bbf91e6 100644 (file)
@@ -62,6 +62,11 @@ i'm new to ikiwiki, apologies if this is dealt with elsewhere.  -brush
 
 ## design feedback from joeyh on an earlier version
 
+Not entirely relevant any more.
+[[!toggle id="old-design-feedback" text="show"]]
+[[!toggleable id="old-design-feedback" text="""
+[[!toggle id="old-design-feedback" text="hide"]]
+
 You had wanted my feedback on the design of this. I have not looked at the
 code or tried it yet, but here goes. --[[Joey]]        
 
@@ -260,6 +265,7 @@ code or tried it yet, but here goes. --[[Joey]]
 >> changed, and only update those viewers where it has. But the dependency
 >> type stuff is still very new, and not plugin friendly .. so only just
 >> possible, --[[Joey]] 
+"""]]
 
 ----
 
@@ -268,6 +274,10 @@ code or tried it yet, but here goes. --[[Joey]]
 '''I think the "special extension" design is a dead-end, but here's what
 happened when I tried to work out how it would work. --[[smcv]]'''
 
+[[!toggle id="special-extension-sketch" text="show"]]
+[[!toggleable id="special-extension-sketch" text="""
+[[!toggle id="special-extension-sketch" text="hide"]]
+
 Suppose that each viewer is a JPEG-or-GIF-or-something, with extension
 ".albumimage". We have a gallery "memes" with three images, badger,
 mushroom and snake.
@@ -408,10 +418,17 @@ Things that would be nice, and are probably possible:
 * some way to deep-link to memes/badger.jpg with a wikilink, without knowing a
   priori that it's secretly a JPEG (probably harder than it looks - you'd
   have to make a directive for it and it's probably not worth it)
+"""]]
 
 ----
 
-## bug: unable to vary thumbnail size
+## resolved bug reports
+
+[[!toggle id="fixed-bugs" text="show"]]
+[[!toggleable id="fixed-bugs" text="""
+[[!toggle id="fixed-bugs" text="hide"]]
+
+### bug: unable to vary thumbnail size
 
 Hi smcv, great plugin. I am an ikiwiki newbie but so far I've had success using your plugin.
 I've integrated the jquery masonry plugin into the albumitem template and it works great.
@@ -419,11 +436,11 @@ But is there a way to create thumnails of different sizes? I've passed thumnails
 and value to album directive and while it does create the new thumbnail sizes it doesn't use them,
 The 96x96 thumbnails still appear on the page no matter what I do. - jaime
 
-> [[KathrynAndersen]] fixed this, see below. --[[smcv]]
+> Fixed in album5 branch, thanks to [[KathrynAndersen]]. --[[smcv]]
 
 ----
 
-## failed installation
+### failed installation
 
 Hi, the plugin looks great, but I am probably too dumb to use it ;( here is what I did:
 created page gal.mdwn with just \[\[!album\]\] directive (no arguments) and subdirectory gal/ with images in form img_1234.jpg
@@ -471,7 +488,7 @@ Thanks Lukas
 
 ----
 
-## bug + patch: not all images shown on album page
+### bug + patch: not all images shown on album page
 
 Hi smcv, we spoke on irc the other day. Passed `show => "0"` on line 126 in album.pm to remove the limit on the thumbnails shown on the album page. Setting it on the album directive didn't work.
 
@@ -480,54 +497,25 @@ Hi smcv, we spoke on irc the other day. Passed `show => "0"` on line 126 in albu
 > That sounds like a correct solution. I'll fix that in my branch when I work on
 > this again. --[[smcv]]
 
+>> Fixed in `album5` branch --s
+
 ----
 
-## bug: thumbnailsize doesn't work
+### bug: thumbnailsize doesn't work
 
 As mentioned above by Jaime setting the thumbnailsize doesn't catch either. Or rather if I git push after changing the album directive the generated thumbnails (the image files) are the correct size as set in the directive. The html however uses the default thumbnailsize as hardcoded in album.pm and has broken thumbnails as it links to a file with the default size in the filename.
 
 > [[KathrynAndersen]] fixed this, see below. --[[smcv]]
 
+>> Fixed in `album5` branch --s
+
 Issuing `ikiwiki --rebuild` knocks the system into another gear where the thumbnails show up correctly but this is only due to the html being the same as above (linking to hardcoded thumbnailsize) but the generated thumbnail images are now matching the hardcoded size ignoring the thumbnailsize attribute on the album directive.
 
 For me this behaviour is way beyond my skills to sort out (I'm no coder). The albumplugin ikiwiki combo is very attractive to me and the plugin i soo close to working!
 
 --kjs
 
-----
-
-## wishlist + patch: make clicking on the large image go to the next
-
-I've changed the behavior of the "slideshow" to show the next image when clicking the large image as downloading a full resolution image is a rare use case in a gallery of this type imho. The large clicktarget means you are likely to unnecessarily download large files otherwise. I can't quite follow the template, album.pm flow so I can't figure out how to put a "download full resolution" link on the viewer page which would be my next step. To achieve the next link i added ` link => ($nextpage or $album),` around line 454 in `my $img`
-
---kjs
-
-> That seems reasonable. I'll consider that when I work on this
-> plugin again next. --[[smcv]]
-
-----
-
-## wishlist from kjs
-
-My wishlist for the plugin would include:
-
-- Reading exif info from the imagefile
-- ~~Keeping the full resolution image files out of version control~~ Solved this by simply creating a underlay for the images. Works out of the box for my non cgi workflow.
-- Being able to create new albums by tag or by manually picking images from other albums. Could be a simple comma separated list of viewer names, or even full urls, in the album directive.
-- A counter showing **current image/total number of images in album**. This would mean that you know how many images you have left to click through before you have seen all images in an album. This gives you enought info to decide weather to click through or go back/leave.
-
---kjs
-
-> I want the first two of those too, perhaps one day I'll get round to
-> implementing them.
->
-> For the third, you can get the same practical effect using an inline
-> as documented in the main page. --[[smcv]]
->> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image. --kjs
-
-----
-
-## suggested fix for thumbnail size bug
+### suggested fix for thumbnail size bug
 
 I've tracked down the "always showing the 96x96 thumbnails" bug!
 
@@ -578,9 +566,11 @@ Here's a context-diff of my fix:
 >
 > --[[smcv]]
 
+>> Fixed in `album5` --s
+
 ----
 
-## bug: inability to show more than 10 items
+### bug: inability to show more than 10 items
 
 I've found another bug. The album plugin doesn't allow one to have more than 10 items in an album section. This is because it uses "inline" to display album sections, and the default for inline is to show only 10 items. So it only shows 10 items.
 
@@ -596,7 +586,222 @@ What would be good is if the album directive could have a "show" parameter which
 > although I don't know how useful it would be; if it isn't passed, the
 > default should be 0 (unlimited). --[[smcv]]
 
-## cbaines' branch
+>> Fixed in `album5` --s
+
+----
+
+### cbaines' commit to change default thumbnail size
+
+Regarding commit `Change the default thumbnail size`: as far as I
+understand it, `size => 96x96` is meant to set the image size to
+be as large as possible given these constraints: width ≤ 96px,
+height ≤ 96px, and the original aspect ratio is preserved. So I
+would hope that 96x96 doesn't distort the thumbnails. What distortion
+are you seeing, and which versions of Imagemagick and Perlmagick
+are you using?
+
+--[[smcv]]
+
+> I rebuilt the examples using both your album4 and album5 branches, and I only
+> see this in the album4 branch. So this is probably ok to ignore.
+> --[[cbaines]]
+>
+>> OK, I'll assume that was a duplicate of an earlier patch, probably the
+>> one from KathrynAndersen. --s
+
+"""]]
+
+----
+
+## wishlist + patch: make clicking on the large image go to the next
+
+I've changed the behavior of the "slideshow" to show the next image when clicking the large image as downloading a full resolution image is a rare use case in a gallery of this type imho. The large clicktarget means you are likely to unnecessarily download large files otherwise. I can't quite follow the template, album.pm flow so I can't figure out how to put a "download full resolution" link on the viewer page which would be my next step. To achieve the next link i added ` link => ($nextpage or $album),` around line 454 in `my $img`
+
+--kjs
+
+> That seems reasonable. I'll consider that when I work on this
+> plugin again next. --[[smcv]]
+
+----
+
+## wishlist from kjs
+
+My wishlist for the plugin would include:
+
+- Reading exif info from the imagefile
+- ~~Keeping the full resolution image files out of version control~~ Solved this by simply creating a underlay for the images. Works out of the box for my non cgi workflow.
+- Being able to create new albums by tag or by manually picking images from other albums. Could be a simple comma separated list of viewer names, or even full urls, in the album directive.
+- A counter showing **current image/total number of images in album**. This would mean that you know how many images you have left to click through before you have seen all images in an album. This gives you enought info to decide weather to click through or go back/leave.
+
+--kjs
+
+> I want the first two of those too, perhaps one day I'll get round to
+> implementing them.
+>
+> For the third, you can get the same practical effect using an inline
+> as documented in the main page. --[[smcv]]
+>> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image. --kjs
+>>
+>>> Hmm, OK. That breaks the "one picture : one page" mental model,
+>>> unfortunately. The pictures themselves can't be first-class wiki pages (see
+>>> lengthy design discussions with Joey above) because they aren't something
+>>> that produces HTML, and don't have human-readable text source code.
+>>> In the current (album5) design, the viewer pages that are automatically
+>>> created to go alongside the pictures are basically stand-ins for the
+>>> pictures, as far as metadata, wikilinks, tags and other "first-class
+>>> wiki page" things are concerned. --s
+
+>>>> I can see why it's important to keep these models simple and have figured out
+>>>> that the viewer pages are stand-ins for the image. Just as a tought though. If 
+>>>> this relationship was made more explicit ie. the viewer pages *are the content*
+>>>> just initially generated from the image metadata with a link to the image. Then 
+>>>> the mental model would stay intact and more in line with how html and the 
+>>>> implementation works.
+>>>>
+>>>> One thing to point out is that last time I tried pages can be members of 
+>>>> arbitrary numbers of trails/albums. You just get multiple rows of navigation, one
+>>>> for each trail. This doesn't quite work as it's hard to know which one to click.
+>>>>
+>>>> --k
+
+>>>>> Pages can be part of arbitrarily many trails, yes - that's a consequence of
+>>>>> how trails are created. If you can think of a better way to present a page
+>>>>> that's in more than one trail, I'd welcome ideas... I did originally have an
+>>>>> implementation where only one trail would generate links, but when I tried
+>>>>> it on some (rather artificial) overlapping trails, the result was more
+>>>>> confusing. --s
+
+>>> If there are to be viewer pages elsewhere in the wiki, I don't think
+>>> inheriting the picture's metadata is desired. Suppose you have a
+>>> picture of Alice and Bob in the album "holiday in Exampleton, 2010",
+>>> and it is tagged people/alice, people/bob and places/exampleton; the
+>>> other contexts it appears in might include "pictures of Alice" and
+>>> "pictures near Exampleton". If you look at the tag page for
+>>> places/exampleton, I doubt you want to see that photo listed three
+>>> times - once is enough, there's only one actual photo after all. So
+>>> I think the "main" viewer page should be the only one that has
+>>> the taglinks for people/alice, people/bob, places/exampleton.
+>>> --s
+
+>>>> The problem exposed by the tag page issue is very tricky. As you'd
+>>>> probably want the exif info, captions and titles to transfer. Just not 
+>>>> necessarily the tags.
+>>>> --k
+
+>>> My next question is, should the viewer page representing that
+>>> particular picture in its context of "pictures near Exampleton"
+>>> (i.e. its "next" and "previous" links go to the next and
+>>> previous picture near Exampleton, regardless of whether it was
+>>> on an earlier or later visit) be a first-class wiki page
+>>> at all?
+>>> --s
+
+>>> * Does it make any sense to comment on "this picture in this
+>>>   context", if your wiki has comments, or should the only
+>>>   place you can comment on it be its "main" viewer page?
+>>> * Is there any need for it to be possible to make a wikilink
+>>>   to that particular picture in that particular context,
+>>>   or does it only need wikilinks "to the picture" (which,
+>>>   as an implementation detail, really go to its "main" viewer
+>>>   page)?
+>>> * Can the picture in that particular context have tags
+>>>   that are orthogonal to the tags its "main" viewer page has?
+>>> * ... and so on for various wiki features
+>>>
+>>> It sound as though the answer might ideally be that this secondary
+>>> viewer page doesn't need to be a first-class wiki page at all,
+>>> only a HTML output... except that the trail plugin works in terms
+>>> of next and previous first-class wiki pages, not next and
+>>> previous HTML outputs, and the HTML-generation pipeline
+>>> is really aimed towards real pages.
+>>>
+>>> Perhaps the secondary viewer page should end up looking
+>>> something like this:
+>>>
+>>>     \[[!albumviewer original=holiday-in-exampleton-2010/img1234
+>>>       comment="To edit picture metadata, edit the original page instead"]]
+>>>
+>>> and one of the side-effects of the albumviewer directive should be to
+>>> replace [[plugins/comments]] with a link to the original? --s
+
+>>>> One thing to consider is the built in difference between the original and 
+>>>> the secondary inferred by the fact that the first is an `album` the second
+>>>> an `inline` --k
+
+>>>>> I had assumed that both the "original" album (the one where the picture
+>>>>> is physically located), and any other places you wanted to display it,
+>>>>> would be some other directive whose implementation includes a call to
+>>>>> `preprocess_inline`. `inline` on its own is not enough to create
+>>>>> viewer pages to display the pictures, regardless of whether you
+>>>>> want them to be one-per-picture or many-per-picture, and I'm not
+>>>>> going to wedge yet more functionality into that plugin :-)
+>>>>>
+>>>>> It might be a good idea for the thing that displays pictures not
+>>>>> physically located below that point to be a different directive, yes.
+>>>>> --s
+
+>>>> ### Single viewer 
+>>>> For my own usecase what you describe makes sense. I see the content of an inline object
+>>>> (struggling a bit with what terms to user here) as a particular composition of
+>>>> viewers. Perhaps comments should only be possible on the page with the inline rather 
+>>>> than the secondary viewer pages as the inline page not the image viewer is 
+>>>> the first-class page in this scenario? The inline page would also be the page you tag 
+>>>> etc. to make it show up in various contexts such as the tag page.
+>>>>
+>>>> With the thinking outlined above I'd say that the secondary viewer should be a 
+>>>> non editable clone of the original viewer without any source. Just html output with 
+>>>> backlinks to the original page. This means that there are limitations to how these 
+>>>> secondary viewers can be used as the title, caption etc might fit some contexts 
+>>>> better than others. Personally this is fine as I see these inline based albums as 
+>>>> compositions or views on existing content.
+>>>> --k
+>>>>
+>>>>> This is basically what I thought at first, but I realised while
+>>>>> writing my earlier comments that it would be necessary
+>>>>> to hack up [[plugins/trail]] fairly seriously to make it produce
+>>>>> a trail through things that are not first-class wiki pages, and
+>>>>> I'm not sure how much it would be necessary to subvert the
+>>>>> rendering pipeline to get the right parentlinks and so on. --s
+>>>>
+>>>> ###Multiple viewers alternative
+>>>> The alternative is having a page say in `/story/album.mdwn` with the following directive
+>>>> \[[!inline  pages="/01/IMGP6494 or /02/IMGP6601 or /04/IMGP6922" sort="title"  show="0" template="albumitem"]]
+>>>> that creates new fully fledged editable viewers for each image in `/story/album/'
+>>>> without tags being auto populated but backlinks to the original album viewer.
+>>>> --k
+>>>>
+>>>>> It can't *only* be an inline, because an inline wouldn't generate the
+>>>>> viewer pages, but I see what you mean. --s
+>>>>>
+>>>>>> That's actually excellent as the inline is a very useful feature
+>>>>>> the way it works now. I started writing about this yesterday but
+>>>>>> got interrupted. My indexes of albums use the inline in it's current
+>>>>>> form. --k
+>>>>  
+>>>> This would make the viewers completely independent allowing for unique titles, captions and comments
+>>>> depending on context. Very useful when creating powerpoint like slideshows where you might need 
+>>>> different captions depending on the context. In your example wiki with photos from gigs this would allow 
+>>>> a page with an album inline about stage lighting with a selections of images and captions that highlight
+>>>> relevant things in the image as well as a separate inline album page, with some of the same images, 
+>>>> about drumming styles and posture/grip of drummers.
+>>>>
+>>>> I started writing all this supporting your single page case but looking at it now from my limited
+>>>> understanding of how ikiwiki works it seems the multiple viewers option is conceptually cleaner 
+>>>> and more flexible. It relies on three things:
+
+>>>> * A mental model where the viewer page is the content not the image
+>>>> * That tags aren't automatically transferred from the original context. This doesn't seem that critical however.
+>>>> * Backlinks to the other places the image is used.
+>>>>
+>>>> --[[kjs]]
+
+I've added "--k" to some of your comments so other readers (possibly including
+my future self) can keep track of our conversation, I hope you don't mind :-)
+--s
+
+----
+
+## cbaines' CSS changes
 
 Regarding the CSS changes: I'll try to have a look soon, work out
 what actually changed (since you re-ordered the CSS, so it isn't
@@ -612,14 +817,73 @@ theme's style.css unless you actually want an actiontabs album and
 a blueview album to be styled differently, because the IkiWiki Makefile
 concatenates them: for instance, `/usr/share/ikiwiki/themes/actiontabs/style.css`
 is the output of `cat doc/style.css themes/actiontabs/style.css`. So adding it
-to `doc/style.css` should be enough?
-
-Regarding commit `Change the default thumbnail size`: as far as I
-understand it, `size => 96x96` is meant to set the image size to
-be as large as possible given these constraints: width ≤ 96px,
-height ≤ 96px, and the original aspect ratio is preserved. So I
-would hope that 96x96 doesn't distort the thumbnails. What distortion
-are you seeing, and which versions of Imagemagick and Perlmagick
-are you using?
+to `doc/style.css` should be enough? --[[smcv]]
 
---[[smcv]]
+> I don't think this is the case? Or at least, looking at the generated
+> stylesheet for the examples built using my branch, I would expect there to be
+> two copies of the album rules in the stylesheet [1], but there does not
+> appear to be. This could quite easily be a result of some mistake in my part
+> in not isolating the build though. --[[cbaines]]
+>
+> 1: <http://cbaines.net/projects/ikiwiki/album/dest/basic-actiontabs/style.css>
+>
+>> I searched for `/* relevant to the index page */` and found it twice,
+>> so I stand by what I said :-) --s
+>>
+>>> And right you are, unsure how I missed that. My album branch is now rebased
+>>> on your album5 branch (with the two now useless commits removed).
+>>> --[[cbaines]]
+
+cbaines, would you mind publishing an album with more realistic pixel-sizes
+of images using your modified CSS? It's difficult to get an idea of how it
+will degrade under conditions like "image size > browser window" with
+images as small as the ones you used. You might find
+<http://git.pseudorandom.co.uk/smcv/ikiwiki-demos/ikialbum.git>
+(`git clone git://git.pseudorandom.co.uk/git/smcv/ikiwiki-demos/ikialbum.git`),
+or the same techniques, useful: it contains images with a realistic pixel
+count, but very very lossy JPEG compression, to keep the size in bytes low.
+
+> I have now created a large (images) example, you can find all the examples
+> here [1]. I have also built all the examples with the album5 branch, you can
+> find the results here [2].
+>
+> 1: <http://cbaines.net/projects/ikiwiki/album/dest/>
+> 2: <http://cbaines.net/projects/ikiwiki/album/dest-album5/>
+
+It's much, much easier to review changes if you use separate commits for
+cosmetic changes like "separate index CSS from viewer CSS" and "more
+consistent indentation", and functional changes like turning the prev/next
+links from absolutely-positioned to floating. I'd be happy to apply
+the cosmetic changes if they were in commits that were literally only
+cosmetic changes, with no functional effect.
+
+> I have now rewritten the CSS changes to get a smaller diff. The only big
+> functional change is from the previous patch is the max-width stuff to cope
+> better with large images.
+
+For the functional bits: I think I'd have used floating boxes instead of the
+absolutely-positioned boxes that are currently used if they provided the effect
+I wanted. I can't remember exactly why I didn't do that now, but
+it might have been because if the browser window shrinks below the image width,
+floats have weird behaviour (they push the actual image out of the way), or because
+I wanted the entire left/right margin of the image to be clickable to have
+a large click-target for scrolling through the album.
+
+If there's something specific that you think is wrong with the CSS in my
+branch, could you please explain it, and perhaps we can come up with something
+that matches both our requirements?
+
+--smcv
+
+> I don't think that something specific is wrong with CSS in the album5 branch,
+> but it does not display large [3], or small [4] images very well. It might be
+> possible to resolve the image size issues without changing from absolute
+> positioning, but I felt (for no particular reason) that I would do it using
+> floats.
+>
+> The clickable region on the margin seems the most likely reason to me to go
+> with absolute positioning, as an initial look at doing this with floats
+> suggests that it is non-trivial.
+>
+> 3: <http://cbaines.net/projects/ikiwiki/album/dest-album5/large-goldtype/album/3/>
+> 4: <http://cbaines.net/projects/ikiwiki/album/dest-album5/basic-blueview/album/ikiwiki_old/>
index 09d2d52fcc98b4be68f85ebb1b0118f47d915d9c..95793e12a6140f0d18672e72c157014b163bed0c 100644 (file)
@@ -1,3 +1,4 @@
+[[!meta author="spalax"]]
 [[!template id=plugin name="created_in_future (deprecated)" author="[[Louis|spalax]]"]]
 
 # Created_in_future
index 7508e0b21f92283fbe70234f35c491bef59bf21b..ba35b37c60b23363e20890630d2b7376f4d8fef1 100644 (file)
@@ -1,3 +1,4 @@
+[[!meta author="spalax"]]
 [[!template id=plugin name=datetime_cmp author="[[Louis|spalax]]"]]
 [[!tag type/pagespec]]
 
@@ -36,7 +37,7 @@ where:
     * `page`: other page (given in argument);
     * `now`: date or time of compilation;
     * `today`: same meaning as `now`.
-  * `(|_delta)`: used to add a time delta (to use comparisons such as *created at least two day after `some_page`*):
+  * `(|_delta)`: used to add a time delta (to use comparisons such as *created at least two days after `some_page`*):
     * *empty*: no delta;
     * `_delta`: delta (given in argument).
 
index 794e4bd9c5a6a7ad0e923710777d5f6629705282..8123b313243cb3657d878c3985767c31e088b547 100644 (file)
@@ -1,3 +1,4 @@
+[[!meta author="spalax"]]
 [[!template id=plugin name=jscalendar author="[[Louis|spalax]]"]]
 
 # Jscalendar
@@ -12,33 +13,37 @@ Here are some differences compared to this latter plugin.
   * No need to rebuild the page containing the calendar each time day changes, or
     a page (indexed by the calendar) is added, changed or deleted. This is
     particularly useful if you want to have this calendar in the sidebar.
-  * Handles the case where several pages appear the same day: a popup appear to let user choose the day he wants.
   * Smooth navigation among months.
-* Neutral
-  * Most of options are defined in Ikiwiki's setup files instead of the options
-    of the directive.
 * Cons
-  * As a consequence, every calendar of the wiki must index the same set of pages.
   * Javascript :( .
 
 ## Usage
 
-### Directive
+### Examples of directive
 
     \[[!jscalendar type="month" ]]
 
+    \[[!jscalendar type="month" archivebase="calendar"]]
+
+    \[[!jscalendar type="month" year=2014 month=08 pages="posts/* and !posts/*"]]
+
+    \[[!jscalendar type="month" year=-1 month=08]]
+
 ### Setup file
 
-It being javascript rather than markdown, most of the configuration must be done in the IkiWiki configuration file rather than in the directive
+This plugin uses the options used by the [[plugins/calendar]] plugin:
 
-    'archivebase' => "evenements/calendrier",
-    'archive_pagespec' => "evenements/liste/* and ! evenements/liste/*/*",
+    'archivebase' => "archive",
+    'archive_pagespec' => "posts/* and ! posts/*/*",
     'week_start_day' => 1,
     'month_link' => 1,
 
+The `archivebase` and `archive_pagespec` can be overloaded by the very same
+options of the directive.
+
 ## Example
 
-You can see this plugin in action on [[our website|http://www.gresille.org]]. To see what happens when several pages happens on the same day, check the 15th of March 2012.
+You can see this plugin in action on [[our website|http://www.gresille.org]].
 
 Code and documentation can be found here : [[https://atelier.gresille.org/projects/gresille-ikiwiki/wiki/Jscalendar]]
 
index 4944f3a8f82d1545c823aafb39eeef05c3eafacb..c21be0abe29966dd36b8e51398bb4464c8effa62 100644 (file)
@@ -1,9 +1,12 @@
+[[!meta author="spalax"]]
 [[!template id=plugin name=monthcalendar author="[[Louis|spalax]]"]]
 
 # Monthcalendar
 
 This plugin displays a calendar, containing in each of its day the list of links of pages published on this day. It can be used, for example, to display archives of blog posts, or to announce events.
 
+The difference between this plugin and the [[plugins/calendar]] plugin is that the calendar displayed by this plugin is a big one, containing the full title of every page indexed in it.
+
 ## Usage
 
 ### Directive
@@ -16,6 +19,109 @@ By using the following line in template `calendarmonth.tmpl`, you can have `ikiw
 
     \[[!monthcalendar type="month" year="<TMPL_VAR YEAR>" month="<TMPL_VAR MONTH>" pages="<TMPL_VAR PAGESPEC>"]]
 
+## CSS
+
+Here is an example of CSS properly rendering the calendar produced by this
+plugin.
+[[!toggle id=css text="CSS"]]
+[[!toggleable id=css text="""
+    /* Calendar */
+    .monthcalendar
+    {
+        color:#aaa;
+        /* font-size:18pt; */
+        margin-top:1em;
+        margin-bottom:1em;
+               width: 100%;
+    }
+    
+    .monthcalendar table,
+    .monthcalendar td,
+    .monthcalendar th
+    {
+       border: 1px solid #ccc;
+    }
+    
+    #content .monthcalendar td
+    {
+        padding: 0;
+        position: relative;
+    }
+    
+    .monthcalendar td div
+    {
+        min-height: 10ex;
+        height: 100%;
+        position: relative;
+    }
+    
+    .monthcalendar th
+    {
+       vertical-align: middle;
+    }
+    
+    .monthcalendar td ul
+    {
+        padding-left: 0.5em;
+        list-style: dot;
+        list-style-position: inside;
+        text-align: left;
+        font-size: 8pt;
+        position: relative;
+        z-index: 10;
+        font-weight: bold;
+    }
+    
+    table.monthcalendar
+    {
+       table-layout: fixed;
+    }
+    
+    .monthcalendar .selflink
+    {
+        color:#444444;
+    }
+    
+    .monthcalendar-day-head {
+       text-transform:capitalize;
+    }
+    
+    .monthcalendar-head {
+       text-transform:capitalize;
+    }
+    
+    .monthcalendar-daynumber
+    {
+        float: left;
+        position: absolute;
+        display: block;
+        font-size: 7ex;
+        color: #ccc;
+        line-height: 100%;
+        z-index: 5;
+        padding-top: 0.3ex;
+        text-align: right;
+        width: 1.8em;
+    }
+    
+    /* List of pages */
+    
+    .monthcalendar-pagelist {
+      display: flex;
+      flex-direction: column;
+    }
+    
+    .monthcalendar-item {
+      opacity: 0;
+      height: 0;
+    }
+    
+    .monthcalendar-item:target {
+      opacity: 1;
+      height: initial;
+    }
+"""]]
+
 ## Code
 
 Code and documentation can be found here : [[https://atelier.gresille.org/projects/gresille-ikiwiki/wiki/Monthcalendar]].
index f1c15c6e02ca410ab2ca12ef6a6228c78b170ed9..9de66f7877341e484203e2e0bd54b96eca2ddab5 100644 (file)
@@ -38,3 +38,6 @@ If you are interested in this, drop me a line tobi at oetiker dot ch
 
 
 In the meanwhile, I ([[MartinQuinson]]) have hacked this a bit to make it fit my needs. The result is [[here|http://www.loria.fr/~quinson/Hacking/ikiwiki/]]
+
+In the meanwhile I too have hacked this for my needs and fixed a few bugs in Martin's version.
+The result (and source / instructions) can be found [[here|http://wiki.math.cmu.edu/iki/wiki/tips/20140720-ikiwiki-navbar.html]]. (It is not mobile ready yet, but might be soon...)
index d3bede79705f508b500bcf1e12bb6a24ead69652..5dc01c7c559096a675941c9b78b9a1ff8bc3e711 100644 (file)
@@ -1,3 +1,4 @@
+[[!meta author="spalax"]]
 [[!template id=plugin name=parenttag author="[[Louis|spalax]]"]]
 [[!tag type/tags]]
 
diff --git a/doc/plugins/contrib/poetry.mdwn b/doc/plugins/contrib/poetry.mdwn
new file mode 100644 (file)
index 0000000..aed2e42
--- /dev/null
@@ -0,0 +1,107 @@
+[[!meta author="spalax"]]
+[[!template id=plugin name=poetry author="[[Louis|spalax]]"]]
+
+# Poetry
+
+The poetry plugin provides the [[ikiwiki/directive/poetry]] directive, used to
+render poetry (or songs).
+
+## Why?
+
+### Typography
+
+In regular text, there are two different meaning of a new line: a break between
+two paragraphs, and the line wrap.
+
+When rendering poetry, we need a third one: the carriage return between two
+verse lines. This one should be different from the line wrap carriage return,
+otherwise one will not be able to tell apart these two: is a word displayed at
+the begenning of its line a new verse line, or the previous verse line,
+continuing on a new line because it is too long?
+
+Generally, wrapped text is indented, whereas verse lines are not.
+
+### Markdown
+
+One could use carriage return (two white spaces at the end of a line) between
+verse lines, and paragraph break between stanzas, but:
+
+* adding white spaces at the end of lines is painful;
+* there is no easy way to render chorus (in a different way from verses).
+
+## Usage
+
+The directive takes only one argument `content`, containing the poetry to
+render. Carriage returns are respected.
+
+Chorus are lines with `> ` as a starting character.
+
+Lines starting with `) ` are consored/outdated/crossed out verses.
+
+[[!toggle id=example text="View example"]]
+[[!toggleable id=example text='''
+    \[[!poetry content="""
+    This is a verse
+    Made of several lines
+
+    > And here is the chorus
+    > La la la!
+    > A beautiful chorus
+
+    Another verse
+    A bit longer
+    Than the previous one
+
+    ) This one is deleted
+    ) Because I did not like it
+    """]]
+''']]
+
+
+## CSS
+
+This plugin is useless without some corresponding CSS. An example is given
+below.
+
+[[!toggle id=css text="CSS"]]
+[[!toggleable id=css text="""
+    .poetry {
+      padding-left: 1em;
+      border-left: 0.1em solid lightgray;
+      border-radius: 0.5em;
+    }
+    
+    .poetry .stanza {
+      padding-left: 1em;
+    }
+    
+    .poetry .paren {
+      font-style: italic;
+      font-size: smaller;
+      text-decoration: line-through;
+    }
+    
+    .poetry .paren:hover {
+      text-decoration: initial;
+    }
+    
+    .poetry .chorus {
+      margin-left: 0.1em;
+      padding-left: 2em;
+      border-left: 0.3em solid slategray;
+    }
+    
+    .poetry .line {
+      display: block;
+      text-indent: -1em;
+    }
+"""]]
+
+## Example
+
+This plugin is used to render songs on [this choir's
+website](http://barricades.int.eu.org/repertoire/bread_and_roses/).
+
+## Code
+
+Code and documentation can be found here : [[https://atelier.gresille.org/projects/gresille-ikiwiki/wiki/Poetry]].
index 574bdeaab11f8e936495dbf69f97ed710211501d..5c169bfd49f4f132860dee56f69c4a423d2ed7b5 100644 (file)
@@ -1,9 +1,10 @@
+[[!meta author="spalax"]]
 [[!template id=plugin name=sidebar2 author="[[Louis|spalax]]"]]
 [[!tag type/chrome]]
 
 *Claim:* The [[sidebar|plugins/sidebar]] plugin has nothing
 to do with sidebars. This plugin renders some page (which happens to be named
-`sidebar`) and put the result in template variable `SIDEBAR`, in template
+`sidebar`) and put the result in template variable `SIDEBAR` of template
 `page.tmpl`. But the fact that it is a sidebar, i.e. a bar appearing on the
 side on the screen, is done by CSS.
 
@@ -40,7 +41,7 @@ The default, which gives the behaviour of the sidebar plugin, is
 
 # Improvements over sidebar plugin
 
-* You can add several "sidebars" to your wiki. For example, to have a sidebar, a submeno that appear only in pages documentations, and a footer, your `global_sidebars` would be:
+* You can add several "sidebars" to your wiki. For example, to have a sidebar, a submenu that appears only in documentation pages (`doc/*`), and a footer, your `global_sidebars` would be:
 
       global_sidebars => [
         "sidebar", "sidebar", "*",
index 38c2a10c4869ce68955a7993996f6a79687670f5..377c9ed394641b03ece036fa5f72003b7b096acf 100644 (file)
@@ -1,3 +1,4 @@
+[[!meta author="spalax"]]
 [[!template id=plugin name=taskreport author="[[Louis|spalax]]"]]
 
 # Taskreport
index 040d175ca21843de5bcff4e0cd9136a7596c24af..a2455a4be07c606e934d8c77bfb311eb287895bd 100644 (file)
@@ -1,10 +1,10 @@
 [[!template id=plugin name=osm author="Blars Blarson, Antoine Beaupré"]]
 [[!tag type/special-purpose todo/geotagging]]
 
-## Openstreetmap/Openlayers support for ikiwiki
+## OpenStreetMap/OpenLayers support for ikiwiki
 
-This plugin provides simple Openstreetmap/Openlayers support for ikiwiki.
-It can embed Openstreetmap viewports within a page or link to a bigger map
+This plugin provides simple OpenStreetMap/OpenLayers support for ikiwiki.
+It can embed OpenStreetMap viewports within a page or link to a bigger map
 that will have multiple markers, generated with a KML (or CSV, or GeoJSON)
 datafile of markers based on the different calling pages. Multiple distinct
 maps on a single wiki are supported.
@@ -15,6 +15,22 @@ if the [[!cpan JSON]] perl module is installed.
 
 This provides the [[ikiwiki/directive/waypoint]] and [[ikiwiki/directive/osm]] directives.
 
+### Examples
+
+A [[basic set of examples|http://cbaines.net/osm-examples]] is available
+([[repository|http://git.cbaines.net/?p=ikiwiki/osm-examples.git;a=summary]]).
+Note that none of these will work without patching the plugin. With the
+following patches, most of the examples will work (while each patch is
+seperate, the branch includes all previous patches in the list, so the
+cbaines/osm-icon-fixes branch includes all patches).
+
+ - [[bugs/osm plugin error TypeError: mapProjection is null]]
+ - [[todo/osm plugin GeoJSON popup patch]]
+ - [[todo/osm plugin icon patch]]
+
+Even with these patches, the CSV examples do not work, and there are cosmetic
+issues with a few of the other examples.
+
 ---
 
 The plugin was originally written by
index 731b8c7909db4ff7dfd5fb925677c81aa08b1ea6..6b1b58bd8172a30c86ed7ee544822f78dcb33c3e 100644 (file)
@@ -170,3 +170,16 @@ I have removed a similar comment from the album discussion.
 
 >> Let me know if you need anything else. Would be great to hear it works
 >> as expected for everyone else ;) --[[kjs]]
+
+>>> Hmm. Investigating the indexdb:
+>>>
+>>>     perl -le 'use Storable; my $index = Storable::retrieve("stockholm/.ikiwiki/indexdb"); use Data::Dumper; print Dumper $index' |less
+>>>
+>>> indicates that `20130504` depends on `internal(*)` and so does `20130505`.
+>>>
+>>> After adding some `Carp::cluck` calls to the bits of IkiWiki.pm that add
+>>> dependencies, this turns out to be two similar issues, in `album` and
+>>> `trail`: they each use `pagespec_match_list` with the pagespec
+>>> `internal(*)` in order to apply a trivial filter (accept everything)
+>>> to an existing list for its side-effect of sorting that list.
+>>> Bug filed as [[bugs/trails depend on everything]] --smcv
index d0bb8c517dd5d190199449025d60e300b1eb44d7..f9fa321b3b96baa49c0b79ce32ce03a8553d38c6 100644 (file)
@@ -1,3 +1,4 @@
+
 This is the [[SandBox]], a page anyone can edit to try out ikiwiki
 (version [[!version  ]]).
 
@@ -5,7 +6,11 @@ What about [[this page]]?
 
 hello world (right back at ya)
 
-test, is it being saved?
+test, is it being saved? Probably. I will check. This seems really straightforward.
+
+~~~
+pre formated text?
+~~~
 
 > This is a blockquote.
 >
@@ -96,7 +101,7 @@ This is an email link:
 Send Mail</a>
 </p>
 
-This is some preformatted text.  Each line is proceeded by four spaces.
+What follows is some preformatted text.  Each line is proceeded by four spaces.
 
     Test
 
diff --git a/doc/sandbox/discussion.mdwn b/doc/sandbox/discussion.mdwn
new file mode 100644 (file)
index 0000000..ec651a5
--- /dev/null
@@ -0,0 +1,7 @@
+Whilst discussing Ikiwiki on IRC, someone pointed out that "This is the SandBox, a page anyone can edit to try out ikiwiki" is not strictly true, or is debatably so, since they must log in to edit. This proved to be enough of a barrier that said person didn't consider ikiwiki any further. -- [[Jon]]
+
+> I personally think we'd be better off with a separate demo wiki
+> (sandbox.ikiwiki.info?) that has its own git repo and
+> `nofollow` configuration, so edits to that wiki aren't archived
+> in ikiwiki's git history forever; perhaps with a cron job to
+> reset the sandbox every few days? --[[smcv]]
index b4f6d8ef47b4fb0ec1a067743c8732c6eb6f7d24..ca529c296b64e9eb34f884c5a1595365ea41cca6 100644 (file)
@@ -27,7 +27,7 @@ This page controls what shortcut links the wiki supports.
 * [[!shortcut name=debrt url="https://rt.debian.org/Ticket/Display.html?id=%s"]]
 * [[!shortcut name=debss url="http://snapshot.debian.org/package/%s/"]]
   * Usage: `\[[!debss package]]` or `\[[!debss package/version]]`.  See <http://snapshot.debian.org/> for details.
-* [[!shortcut name=debwiki url="https://wiki.debian.org/%s"]]
+* [[!shortcut name=debwiki url="https://wiki.debian.org/%S"]]
 * [[!shortcut name=fdobug url="https://bugs.freedesktop.org/show_bug.cgi?id=%s" desc="freedesktop.org bug #%s"]]
 * [[!shortcut name=fdolist url="http://lists.freedesktop.org/mailman/listinfo/%s" desc="%s@lists.freedesktop.org"]]
 * [[!shortcut name=gnomebug url="https://bugzilla.gnome.org/show_bug.cgi?id=%s" desc="GNOME bug #%s"]]
@@ -55,7 +55,7 @@ This page controls what shortcut links the wiki supports.
 * [[!shortcut name=whois url="http://reports.internic.net/cgi/whois?whois_nic=%s&type=domain"]]
 * [[!shortcut name=cve url="https://cve.mitre.org/cgi-bin/cvename.cgi?name=%s"]]
 * [[!shortcut name=flickr url="https://secure.flickr.com/photos/%s"]]
-* [[!shortcut name=man url="http://linux.die.net/man/%s"]]
+* [[!shortcut name=man url="http://manpages.debian.org/%s"]]
 * [[!shortcut name=ohloh url="https://www.ohloh.net/p/%s"]]
 * [[!shortcut name=cpanrt url="https://rt.cpan.org/Ticket/Display.html?id=%s" desc="CPAN RT#%s"]]
 * [[!shortcut name=novellbug url="https://bugzilla.novell.com/show_bug.cgi?id=%s" desc="bug %s"]]
index 6e04dcf8f40ee4a060cefbce7ab7ce4f591ae580..712eb074085d6b13b85f632855a02f135ce505df 100644 (file)
@@ -30,4 +30,6 @@ cba01c2 | 2013/09/15 | spain1001 | 80.187.106.136
 702a3e5 | 2014/01/02 | Toni      | 124.105.173.121
 c2924ce | 2014/01/02 | domtheo9110 | 182.253.51.174
 cd81b9f | 2014/01/03 | domtheo9110 | ?
+e3376ce | 2014/08/19 | Nng_L (OpenID) | 58.186.127.104
+104c606 | 2014/08/19 | tlevine (OpenID) | 82.153.13.48
 """]]
index 6bbaf3e6e818e2e286c0cf9d357c9b03f649e146..e6277d3384861a9bda93ed09b1c67399a1ea60e2 100644 (file)
@@ -38,6 +38,8 @@ it on a remote machine, and tell Ikiwiki to use it instead of its local one. We
 will also ensure that the wiki is rendered whenever a commit is done to the git
 repository.
 
+[[!img separate-web-git-servers.svg size=400x]]
+
 # Conventions
 
 - We are building a wiki called *SITE*.
diff --git a/doc/tips/Hosting_Ikiwiki_and_master_git_repository_on_different_machines/separate-web-git-servers.svg b/doc/tips/Hosting_Ikiwiki_and_master_git_repository_on_different_machines/separate-web-git-servers.svg
new file mode 100644 (file)
index 0000000..b6095a2
--- /dev/null
@@ -0,0 +1,783 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="493.26132"
+   height="546.48431"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.48.4 r9939"
+   sodipodi:docname="separate-web-git-servers.svg">
+  <defs
+     id="defs4">
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lend"
+       style="overflow:visible">
+      <path
+         id="path3914"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lend"
+       style="overflow:visible">
+      <path
+         id="path3896"
+         d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Lstart"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lstart"
+       style="overflow:visible">
+      <path
+         id="path3893"
+         d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
+         style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
+         transform="matrix(0.8,0,0,0.8,10,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <linearGradient
+       id="linearGradient3767">
+      <stop
+         style="stop-color:#efbc00;stop-opacity:1;"
+         offset="0"
+         id="stop3769" />
+      <stop
+         id="stop3775"
+         offset="0.93150687"
+         style="stop-color:#ffcb10;stop-opacity:1;" />
+      <stop
+         style="stop-color:#ffffff;stop-opacity:1;"
+         offset="1"
+         id="stop3771" />
+    </linearGradient>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lend-4"
+       style="overflow:visible">
+      <path
+         inkscape:connector-curvature="0"
+         id="path3914-9"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5456"
+       style="overflow:visible">
+      <path
+         inkscape:connector-curvature="0"
+         id="path5458"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lend-3"
+       style="overflow:visible">
+      <path
+         inkscape:connector-curvature="0"
+         id="path3914-6"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5456-4"
+       style="overflow:visible">
+      <path
+         inkscape:connector-curvature="0"
+         id="path5458-7"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lend-5"
+       style="overflow:visible">
+      <path
+         inkscape:connector-curvature="0"
+         id="path3914-92"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5456-3"
+       style="overflow:visible">
+      <path
+         inkscape:connector-curvature="0"
+         id="path5458-78"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lend-36"
+       style="overflow:visible">
+      <path
+         inkscape:connector-curvature="0"
+         id="path3914-5"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5532"
+       style="overflow:visible">
+      <path
+         inkscape:connector-curvature="0"
+         id="path5534"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lend-9"
+       style="overflow:visible">
+      <path
+         id="path3914-62"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker3131"
+       style="overflow:visible">
+      <path
+         id="path3133"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5532-3"
+       style="overflow:visible">
+      <path
+         inkscape:connector-curvature="0"
+         id="path5534-1"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker5532-1"
+       style="overflow:visible">
+      <path
+         inkscape:connector-curvature="0"
+         id="path5534-12"
+         style="font-size:12px;fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)" />
+    </marker>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="1.0885159"
+     inkscape:cx="285.18022"
+     inkscape:cy="314.69374"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     showguides="true"
+     inkscape:guide-bbox="true"
+     inkscape:snap-global="true"
+     inkscape:window-width="1440"
+     inkscape:window-height="834"
+     inkscape:window-x="0"
+     inkscape:window-y="27"
+     inkscape:window-maximized="1"
+     fit-margin-top="25"
+     fit-margin-left="25"
+     fit-margin-right="25"
+     fit-margin-bottom="25">
+    <inkscape:grid
+       type="xygrid"
+       id="grid2985"
+       empspacing="5"
+       visible="true"
+       enabled="true"
+       snapvisiblegridlinesonly="true"
+       originx="0.24219388px"
+       originy="26px" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-159.41406,-135.03802)">
+    <rect
+       style="fill:none;stroke:#000000;stroke-width:0.44862616;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
+       id="rect3866"
+       width="442.58115"
+       height="91.284172"
+       x="184.86992"
+       y="415.3576"
+       ry="4.005312"
+       rx="10.005878" />
+    <path
+       style="fill:#ffcb14;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 355,222.36218 55,0 0,-45 -25,0 -5,-5 -20,0 -5,5 z"
+       id="path2989"
+       inkscape:connector-curvature="0" />
+    <text
+       xml:space="preserve"
+       style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="368.57144"
+       y="251.21931"
+       id="text2995"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan2997"
+         x="368.57144"
+         y="251.21931" /></text>
+    <path
+       style="fill:#ffcb14;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 355,348.36218 55,0 0,-45 -25,0 -5,-5 -20,0 -5,5 z"
+       id="path2989-4"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:#ffcb14;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 355,483.36218 55,0 0,-45 -25,0 -5,-5 -20,0 -5,5 z"
+       id="path2989-1"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:#ffcb14;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 355,623.36218 55,0 0,-45 -25,0 -5,-5 -20,0 -5,5 z"
+       id="path2989-5"
+       inkscape:connector-curvature="0" />
+    <path
+       style="opacity:0.48800001;fill:#ffcb14;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 475,623.36218 55,0 0,-45 -25,0 -5,-5 -20,0 -5,5 z"
+       id="path2989-2"
+       inkscape:connector-curvature="0" />
+    <path
+       style="opacity:0.5;fill:#ffcb14;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 235,623.36218 55,0 0,-45 -25,0 -5,-5 -20,0 -5,5 z"
+       id="path2989-8"
+       inkscape:connector-curvature="0" />
+    <text
+       xml:space="preserve"
+       style="font-size:40px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="386.06738"
+       y="652.36218"
+       id="text3868"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan3870"
+         x="386.06738"
+         y="652.36218"
+         style="font-size:20px;text-align:center;text-anchor:middle">working clones</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:18px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="524.37988"
+       y="463.36218"
+       id="text3874"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan3876"
+         x="524.37988"
+         y="463.36218"
+         style="font-size:20px;text-align:center;text-anchor:middle">repository</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="525.35156"
+       y="330.36218"
+       id="text3878"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan3880"
+         x="525.35156"
+         y="330.36218"
+         style="font-size:20px;text-align:center;text-anchor:middle">srcdir</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="525.1543"
+       y="201.36218"
+       id="text3882"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan3884"
+         x="525.1543"
+         y="201.36218"
+         style="font-size:20px;text-align:center;text-anchor:middle">destdir</tspan></text>
+    <g
+       id="g5440"
+       transform="translate(5,51.000003)">
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path3886"
+         d="m 370,512.36218 c -5,-24.99999 -5,-44.99999 0,-70"
+         style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:none;marker-mid:none;marker-end:url(#Arrow2Lend)" />
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path3888"
+         d="m 390,442.36218 c 5,25 5,45 0,70"
+         style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)" />
+    </g>
+    <g
+       transform="translate(5,-84)"
+       id="g5440-4" />
+    <g
+       transform="matrix(0.71872744,0.69529193,-0.69529193,0.71872744,353.78964,-78.94206)"
+       id="g5440-47">
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path3886-3"
+         d="m 370,512.36218 c -5,-24.99999 -0.0778,-66.9912 7.34379,-88.08431"
+         style="opacity:0.5;fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:none;marker-mid:none;marker-end:url(#Arrow2Lend)" />
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path3888-6"
+         d="m 391.48399,424.51223 c 5,25 6.0155,63.74804 -1.48399,87.84995"
+         style="opacity:0.5;fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)" />
+    </g>
+    <g
+       transform="matrix(-0.71872744,0.69529193,0.69529193,0.71872744,421.21036,-78.94206)"
+       id="g5440-47-9"
+       style="opacity:0.5">
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path3886-3-3"
+         d="m 370,512.36218 c -5,-24.99999 -0.0778,-66.9912 7.34379,-88.08431"
+         style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:none;marker-mid:none;marker-end:url(#Arrow2Lend)" />
+      <path
+         sodipodi:nodetypes="cc"
+         inkscape:connector-curvature="0"
+         id="path3888-6-3"
+         d="m 391.48399,424.51223 c 5,25 6.0155,63.74804 -1.48399,87.84995"
+         style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)" />
+    </g>
+    <path
+       style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker5532)"
+       d="m 380,288.36218 0,-60"
+       id="path5558"
+       inkscape:connector-curvature="0" />
+    <g
+       id="g5810"
+       transform="translate(0,17)">
+      <g
+         transform="translate(-230,-4.9999974)"
+         id="g3784-7">
+        <g
+           id="g3779-37">
+          <path
+             inkscape:connector-curvature="0"
+             id="path2993-5"
+             d="m 440,177.36218 10,0 0,-10"
+             style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+          <path
+             sodipodi:nodetypes="cccccc"
+             inkscape:connector-curvature="0"
+             id="path2991-3"
+             d="m 440,177.36218 0,40 35,0 0,-50 -25,0 z"
+             style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+          <path
+             inkscape:connector-curvature="0"
+             id="path3777-8"
+             d="m 440,177.36218 10,0 0,-10"
+             style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+        </g>
+      </g>
+      <g
+         transform="translate(-235,-9.9999974)"
+         id="g3784">
+        <g
+           id="g3779">
+          <path
+             inkscape:connector-curvature="0"
+             id="path2993"
+             d="m 440,177.36218 10,0 0,-10"
+             style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+          <path
+             sodipodi:nodetypes="cccccc"
+             inkscape:connector-curvature="0"
+             id="path2991"
+             d="m 440,177.36218 0,40 35,0 0,-50 -25,0 z"
+             style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+          <path
+             inkscape:connector-curvature="0"
+             id="path3777"
+             d="m 440,177.36218 10,0 0,-10"
+             style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+        </g>
+      </g>
+      <text
+         sodipodi:linespacing="125%"
+         id="text5762"
+         y="176.55017"
+         x="206.62401"
+         style="font-size:16px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+         xml:space="preserve"><tspan
+           style="font-size:8px"
+           y="176.55017"
+           x="206.62401"
+           id="tspan5764"
+           sodipodi:role="line">&lt;html&gt;</tspan></text>
+    </g>
+    <g
+       id="g5824"
+       transform="translate(0,17)">
+      <g
+         transform="translate(-165,-9.9999974)"
+         id="g3784-0">
+        <g
+           id="g3779-3">
+          <path
+             inkscape:connector-curvature="0"
+             id="path2993-2"
+             d="m 440,177.36218 10,0 0,-10"
+             style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+          <path
+             sodipodi:nodetypes="cccccc"
+             inkscape:connector-curvature="0"
+             id="path2991-8"
+             d="m 440,177.36218 0,40 35,0 0,-50 -25,0 z"
+             style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+          <path
+             inkscape:connector-curvature="0"
+             id="path3777-7"
+             d="m 440,177.36218 10,0 0,-10"
+             style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
+        </g>
+      </g>
+      <g
+         transform="matrix(0.74161576,0,0,0.74161576,75.250882,53.354937)"
+         id="g5772">
+        <path
+           sodipodi:type="star"
+           style="fill:#939393;fill-opacity:1;stroke:#939393;stroke-width:0.70866144;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
+           id="path5768"
+           sodipodi:sides="13"
+           sodipodi:cx="295"
+           sodipodi:cy="187.36218"
+           sodipodi:r1="10.889445"
+           sodipodi:r2="14.142136"
+           sodipodi:arg1="-2.3561945"
+           sodipodi:arg2="-2.1145335"
+           inkscape:flatsided="false"
+           inkscape:rounded="0.36"
+           inkscape:randomized="0"
+           d="m 287.3,179.66218 c 1.12496,-1.12496 -0.97775,-3.57952 0.38374,-4.40257 1.36149,-0.82305 2.55772,2.1795 4.07662,1.70619 1.5189,-0.47331 0.79773,-3.62389 2.38576,-3.71995 1.58803,-0.0961 1.25188,3.11848 2.81676,3.40526 1.56487,0.28677 2.39046,-2.83808 3.84123,-2.18514 1.45078,0.65294 -0.34074,3.34306 0.91162,4.32422 1.25235,0.98116 3.43557,-1.40209 4.41673,-0.14973 0.98116,1.25236 -1.85532,2.80178 -1.20238,4.25255 0.65294,1.45078 3.69363,0.35511 3.98041,1.91998 0.28677,1.56488 -2.94485,1.61865 -3.04091,3.20668 -0.0961,1.58803 3.10552,2.03094 2.63221,3.54984 -0.47331,1.5189 -3.35976,0.0647 -4.18281,1.42619 -0.82305,1.3615 1.80598,3.24152 0.68102,4.36648 -1.12496,1.12496 -3.00498,-1.50407 -4.36648,-0.68101 -1.36149,0.82305 0.0927,3.7095 -1.42619,4.1828 -1.5189,0.47331 -1.96181,-2.72827 -3.54984,-2.63221 -1.58803,0.0961 -1.64181,3.32768 -3.20668,3.04091 -1.56488,-0.28678 -0.4692,-3.32746 -1.91998,-3.9804 -1.45077,-0.65294 -3.00019,2.18353 -4.25255,1.20237 -1.25236,-0.98116 1.13089,-3.16437 0.14973,-4.41673 -0.98116,-1.25236 -3.67128,0.53916 -4.32422,-0.91161 -0.65294,-1.45078 2.47191,-2.27636 2.18513,-3.84124 -0.28677,-1.56488 -3.50131,-1.22873 -3.40525,-2.81676 0.096,-1.58803 3.24664,-0.86686 3.71995,-2.38576 0.47331,-1.5189 -2.52925,-2.71513 -1.70619,-4.07662 0.82305,-1.36149 3.27761,0.74122 4.40257,-0.38374 z"
+           inkscape:transform-center-x="-0.68364368"
+           inkscape:transform-center-y="0.68364368"
+           transform="translate(-2,0)" />
+        <path
+           sodipodi:type="arc"
+           style="fill:#ffffff;fill-opacity:1;stroke:#939393;stroke-width:0.70866144;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
+           id="path5770"
+           sodipodi:cx="295"
+           sodipodi:cy="187.36218"
+           sodipodi:rx="5"
+           sodipodi:ry="5"
+           d="m 300,187.36218 c 0,2.76143 -2.23858,5 -5,5 -2.76142,0 -5,-2.23857 -5,-5 0,-2.76142 2.23858,-5 5,-5 2.76142,0 5,2.23858 5,5 z"
+           transform="matrix(1.4,0,0,1.4,-120,-74.944873)" />
+      </g>
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="265"
+       y="237.36218"
+       id="text5806"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan5808"
+         x="265"
+         y="237.36218"
+         style="font-size:12px">ikiwiki.cgi</tspan></text>
+    <path
+       style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker5532)"
+       d="m 295,243.36218 c -33.17806,71.23519 20.40659,76.94287 53.16264,84.08132"
+       id="path5834"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;text-align:end;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:end;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="303.54837"
+       y="447.15784"
+       id="text6240"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6242"
+         x="303.54837"
+         y="447.15784"
+         style="font-size:14px;text-align:end;writing-mode:lr-tb;text-anchor:end">post-update</tspan><tspan
+         sodipodi:role="line"
+         x="303.54837"
+         y="464.65784"
+         style="font-size:14px;text-align:end;writing-mode:lr-tb;text-anchor:end"
+         id="tspan6244">hook</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="400.70767"
+       y="387.44351"
+       id="text6246"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6248"
+         x="400.70767"
+         y="387.44351"
+         style="font-size:14px">ikiwiki.cgi</tspan><tspan
+         sodipodi:role="line"
+         x="400.70767"
+         y="404.94351"
+         id="tspan6250"
+         style="font-size:14px">push</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="382"
+       y="342.36218"
+       id="text6252"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6254"
+         x="382"
+         y="342.36218">.git</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="383"
+       y="618.36218"
+       id="text6252-3"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6254-1"
+         x="383"
+         y="618.36218">.git</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;opacity:0.3;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="502"
+       y="617.36218"
+       id="text6252-3-1"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6254-1-0"
+         x="502"
+         y="617.36218">.git</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;opacity:0.3;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="263"
+       y="618.36218"
+       id="text6252-3-6"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6254-1-1"
+         x="263"
+         y="618.36218">.git</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="411"
+       y="482.36218"
+       id="text6252-3-0"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6254-1-2"
+         x="411"
+         y="482.36218">.git</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;text-align:end;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:end;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="353.28357"
+       y="277.33801"
+       id="text6372"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6374"
+         x="353.28357"
+         y="277.33801"
+         style="font-size:14px">web-side</tspan><tspan
+         sodipodi:role="line"
+         x="353.28357"
+         y="294.83801"
+         id="tspan6376"
+         style="font-size:14px">edit</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="410"
+       y="258.36218"
+       id="text6378"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6380"
+         x="410"
+         y="258.36218"
+         style="font-size:14px">automatic</tspan><tspan
+         sodipodi:role="line"
+         x="410"
+         y="275.86218"
+         id="tspan6382"
+         style="font-size:14px">rebuild</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="406.75635"
+       y="527.15295"
+       id="text6384"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6386"
+         x="406.75635"
+         y="527.15295"
+         style="font-size:14px">git</tspan><tspan
+         sodipodi:role="line"
+         x="406.75635"
+         y="544.65295"
+         id="tspan6388"
+         style="font-size:14px">pull</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;text-align:end;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:end;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="363.62955"
+       y="530.39691"
+       id="text6390"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan6392"
+         x="363.62955"
+         y="530.39691"
+         style="font-size:14px;text-align:end;text-anchor:end">git</tspan><tspan
+         sodipodi:role="line"
+         x="363.62955"
+         y="547.89691"
+         id="tspan6394"
+         style="font-size:14px;text-align:end;text-anchor:end">push</tspan></text>
+    <rect
+       style="fill:none;stroke:#000000;stroke-width:1.11616147;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
+       id="rect3866-3"
+       width="441.9136"
+       height="210.04529"
+       x="184.97214"
+       y="160.5961"
+       ry="24.83"
+       rx="9.9907875" />
+    <text
+       xml:space="preserve"
+       style="font-size:16px;font-style:normal;font-weight:normal;text-align:end;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:end;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
+       x="246.14922"
+       y="257.2352"
+       id="text6240-9"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         x="246.14922"
+         y="257.2352"
+         style="font-size:14px;text-align:end;writing-mode:lr-tb;text-anchor:end"
+         id="tspan6244-2">pingee</tspan></text>
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.96974897px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker5532)"
+       d="m 381.75266,355.47259 0,66.86071"
+       id="path5558-7"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker5532)"
+       d="M 342.2494,449.19328 C 188.8295,356.40638 236.60096,296.40639 265.99879,248.63492"
+       id="path5558-1"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+  </g>
+</svg>
diff --git a/doc/tips/Right-to-left___40__RTL__41___page_text.mdwn b/doc/tips/Right-to-left___40__RTL__41___page_text.mdwn
new file mode 100644 (file)
index 0000000..2b176c8
--- /dev/null
@@ -0,0 +1,49 @@
+Here's a simple way to create pages in which the page body (or a part of it) goes right-to-left.
+This includes things you insert into the page, such as polls and blockquotes and
+lists and a progress bar and so on. Some things don't work perfectly, but if
+you want to have some RTL pages in your wiki, this will probably do.
+
+It does not modify the things around the body, such as the page header and the
+footer. Only what is rendered from the mdwn file is affected.
+
+# 1 Add an RTL Template
+
+Create a new template page *templates/rtl.mdwn* with the following content:
+
+    <div class="rtl">
+    <TMPL_VAR text>
+    </div>
+    <TMPL_UNLESS text>
+    Use this template to insert RTL text into a page. 
+    This template has one parameter:
+    <ul>
+    <li>`text` - the text to display in RTL
+    </ul>
+    </TMPL_UNLESS>
+
+# 2 Add an RTL class to the CSS
+
+In your *local.css* add the following:
+
+[[!format css """
+/* rtl template */
+.rtl {
+    direction: rtl;
+}
+"""]]
+
+# 3 Use the Template
+
+To make a page or part of it RTL, use the [[ikiwiki/directive/template]] directive:
+
+    \[[!template id="rtl" text="""
+    
+    This text will be aligned to the right. You can write here in Hebrew, Arabic, etc. You can
+    put here anything you want to put on the page. As said above, some elements may not
+    align perfectly, but:
+
+    1. It can be solved per case
+    2. It's not critical, everything works quite well and is readable. If you have any comments,
+        suggestions, improvements, bugs, etc - please share here :-)
+    
+    """]]
index 1d8a8f5a91bddb9167f5495ca148cac64a9b483b..2547a2e9fe510bdbb8ab22a06f847d1a47aaac47 100644 (file)
@@ -37,6 +37,8 @@ the git server.
 
 ### Separate webserver and git repository, the git srcdir being hosted on the webserver
 
+[[!img Hosting_Ikiwiki_and_master_git_repository_on_different_machines/separate-web-git-servers.svg size=400x]]
+
 This is the configuration described in
 [[tips/Hosting_Ikiwiki_and_master_git_repository_on_different_machines]]. One server hosts the web server (and the [[Ikiwiki cgi|cgi]]) and the git source dir; a second server hosts the git bare repository. This can be used when you have very limited access to the git server.
 
index a4d38f8f93db1ab32e047a6a94da0e5f02c2e438..b36bb6a0312c206f2d52edf8ceb84a2eed6da44d 100644 (file)
@@ -14,7 +14,7 @@ The easiest way of installing an up-to-date ikiwiki on any version of Mac OS X i
 
 7. [install binary packages (OSX)](http://www.pkgsrc.org/#index1h1)
 
-{OK} As of 2014/03/19, the [version of ikiwiki in pkgsrc](http://pkgsrc.se/www/ikiwiki) is 3.20140227.
+{OK} As of 2014/08/24, the [version of ikiwiki in pkgsrc](http://pkgsrc.se/www/ikiwiki) is 3.20140815.
 
 -----
 
@@ -39,7 +39,7 @@ enjoy
 
 Enrique Castilla
 
-[!] As of 2014/03/19, the [version of ikiwiki in MacPorts](http://www.macports.org/ports.php?by=name&substr=Ikiwiki) is 3.20110608.
+[!] As of 2014/08/24, the [version of ikiwiki in MacPorts](http://www.macports.org/ports.php?by=name&substr=Ikiwiki) is 3.20110608.
 
 -----
 
index 0dbda8a3ae56f5d73e42571cef69935bb46196c2..1fa710f8f8f184a4e75ff98b4a34c544d1631bbd 100644 (file)
@@ -39,3 +39,25 @@ I've written a new plugin, sectiontemplate, available in the `page_tmpl` branch
 >>>>> --[[KathrynAndersen]]
 
 Just a quick note that Kathryn's branch is ready.[[!template id=gitbranch branch=rubykat/pagetemplate author="[[KathrynAndersen]]"]][[!tag patch]] --[[Will]]
+
+> Review:
+>
+> The indentation seems odd. IkiWiki is mostly indented with hard tabs;
+> this seems to be a mixture of tabs and spaces, assuming 4 spaces per tab.
+>
+> [[!format perl """
+sub checkconfig () {
+...
+               ! defined IkiWiki::template_file($tmpl))
+"""]]
+>
+> I think `checkconfig` is too soon to rely on `template_file`
+> producing correct results? It looks in `%pagesources` which has not
+> yet been updated.
+>
+> If we had a "just before building" hook, that would be a good time
+> to emit warnings; or doing it once per run, on-demand, triggered
+> by the first call to the `templatefile` hook could work. Or the
+> hook could just silently ignore bad pagespecs?
+>
+> --[[smcv]]
diff --git a/doc/todo/add_remove_to_actionlist.mdwn b/doc/todo/add_remove_to_actionlist.mdwn
new file mode 100644 (file)
index 0000000..b50fe88
--- /dev/null
@@ -0,0 +1,20 @@
+[[!template id=gitbranch branch=jon/remove_action author="[[Jon]]"]]
+
+The "remove" plugin allows one to remove pages via the web, but you first have
+to click on 'edit' to get to the 'remove' button. This is a bit
+counter-intuitive, and ikiwiki has an action list, so it would be good if
+"remove" (and also "rename" for that plugin) added items to the action list.
+
+First cut series of patches in the indicated branch.  A bit more review is
+needed, in my tests removals work and are committed to the vcs but
+recentchanges isn't regenerated for some reason (probably the constructed `<a>`
+link needs to add/adjust the parameters to emulate a formbuilder form
+submission more carefully).
+
+I haven't begun on the 'rename' plugin. -- [[Jon]]
+
+[[!tag wishlist patch]]
+
+> I accidentally pushed an incomplete patch to that branch that starts the
+> work of doing the same for rename, but it's not working yet, to merge one
+> would need to cherry-pick the other patches for now. Sorry. -- [[Jon]]
index 6cb15df47955d0a2fc18c09707f1c4f73d1f1f51..2a7350b79ef3656ac4f334d3415f6a8fdf4d378b 100644 (file)
@@ -14,3 +14,212 @@ won't be offended if you correct stuff you consider awkward):
 [[!template  id=gitbranch branch=spalax/calendar-autocreate browse="https://github.com/paternal/ikiwiki/tree/calendar-autocreate" author="[[Louis|spalax]]"]]
 
 --[[Louis|spalax]]
+
+> An attempt at a review (although note that I don't have commit access,
+> so my opinion is not final):
+>
+> Should `calendar_autocreate_commit` really default to 1? I would personally
+> expect that any new features that synthesize new pages should not commit
+> them by default - I'd prefer to avoid cluttering git history with generated
+> pages. (Indeed, should the option even exist?)
+>
+> > I copied those options from the [[plugins/tag]] plugin: the
+> > `tag_autocreate_commit` option exists and default to 1.
+> >
+> > It should definitely exists: suppose a calendar page is created and not
+> > commited, and later, someone tries to push some changes where a page with
+> > the same name has been created. This would result in a conflict. The
+> > `calendar_autocreate_commit` prevents this.
+>
+> > > `tag_autocreate_commit` exists because when tag autocreation
+> > > was introduced, they were always in the `$srcdir` and committed.
+> > > I changed it so that it was possible to put them in the [[plugins/transient]]
+> > > underlay and not commit them. It defaults to 1 to preserve existing
+> > > functionality.
+> > >
+> > > When automatic tag pages (or autoindex pages) are not committed, they
+> > > go in the transient underlay, which means they can't cause conflicts:
+> > > independent page creation will simply mask them (a page in the
+> > > `$srcdir` hides a page of the same name in an underlay). I thought
+> > > this implementation did the same when not committing? --[[smcv]]
+>
+> > > > I did not realize how easy it was to use the [[plugins/transient]]
+> > > > plugin! I [[took it into
+> > > > account|https://github.com/paternal/ikiwiki/commit/492a22ac75f8b41a427a98c44525b01a6fd181b5]].
+> > > > -- [[Louis|spalax]]
+>
+> I'd personally do the conditional in gencalendaryear more like:
+>
+> [[!format perl """
+return unless $config{calendar_autocreate};
+"""]]
+>
+> to reduce the indentation depth of the more interesting code.
+>
+> > [[I agree|https://github.com/paternal/ikiwiki/commit/7f18c1ce48630507b744fa56b83999e8ca684606]]
+>
+> The recursion to generate missing years:
+>
+> [[!format perl """
+if (not exists $wikistate{calendar}{minyear}) {
+        $wikistate{calendar}{minyear} = $year;
+} elsif ($wikistate{calendar}{minyear} > $year) {
+        gencalendaryear($year + 1);
+        $wikistate{calendar}{minyear} -= 1;
+}
+"""]]
+>
+> does seem to be correct on closer examination, but it took me a while
+> to work out that it would actually do the right thing by recursing:
+>
+> * generate 2005
+>   * recurse to generate 2006
+>     * recurse to generate 2007
+>       * recurse to generate 2008
+>         * recurse to generate 2009
+>           * recurse to try to generate 2010 (no effect)
+>         * minyear = minyear - 1 = 2010 - 1 = 2009
+>       * minyear = minyear - 1 = 2009 - 1 = 2008
+>     * minyear = minyear - 1 = 2008 - 1 = 2007
+>   * minyear = minyear - 1 = 2007 - 1 = 2006
+> * minyear = minyear - 1 = 2006 - 1 = 2005
+>
+> I think it might be clearer (as well as less
+> recursion-happy) to use iteration:
+>
+> * generate 2005
+>   * recurse to generate 2006
+>   * ...
+>   * recurse to generate 2009
+> * minyear = 2005
+>
+> something like this:
+>
+> [[!format perl """
+sub gencalendaryear {
+        my $year = shift;
+        my %params = @_;
+        ...
+        # generate this year
+        ...
+        # Filling potential gaps in years [...] years 2006 to 2009.
+        return if $params{norecurse};
+        if (not exists $wikistate{calendar}{minyear}) {
+                $wikistate{calendar}{minyear} = $year;
+        } elsif ($wikistate{calendar}{minyear} > $year) {
+                foreach my $other ($year + 1 .. $wikistate{calendar}{minyear} - 1) {
+                        gencalendar($year, norecurse => 1);
+                }
+                $wikistate{calendar}{minyear} = $year;
+        }
+        # ... and the opposite for maxyear
+}
+"""]]
+>
+>
+> > [[I agree|https://github.com/paternal/ikiwiki/commit/7f18c1ce48630507b744fa56b83999e8ca684606]]
+>
+> I'm not sure about generating missing years at all, though: if the
+> generation is entirely dynamic, and there were no posts at all during
+> a particular year (or month for that matter), shouldn't we just skip
+> the year/month? That seems to be what e.g. Wordpress does.
+>
+> > [[Done|https://github.com/paternal/ikiwiki/commit/59b46942e01b32138d056381249effbbaf773892]].
+> > I added an option `calendar_fill_gaps` to chose between the two
+> > alternatives (since skipping empty months and years would change the
+> > default behaviour of this plugin).
+> >
+> > I think the code is a bit ugly at some places. Perl is not one the the
+> > programming languages I am fluent into. Sorry.
+> >
+> > PS: Good idea, thought. I now have to implement a similar thing for
+> > [[plugins/contrib/jscalendar]].
+>
+> This piece of ikiwiki-calendar functionality is lost:
+>
+> [[!format diff """
+- ... It also refreshes the wiki, updating the calendars to
+-highlight the current day. This command is typically run at midnight from
+-cron.
+"""]]
+>
+> If I understand correctly, the highlight will be on the day at which
+> the wiki was last refreshed, which seems arbitrary and confusing.
+> If ikiwiki-calendar is not used, I'd say there should just not be a
+> highlight for today (although I'm not sure how best to implement that -
+> perhaps a config option representing "I am going to use ikiwiki-calendar").
+>
+> > This is not lost. What ikiwiki-calendar do is simply: build the missing
+> > `archive/year/month` pages, and run `ikiwiki -refresh`. With my patch, the
+> > `ikiwiki -refresh` includes:
+> >
+> > - the build of missing `archive/year/month` pages;
+> > - highlighting the current day (this was already the case).
+> >
+> > So one can simply drop the `ikiwiki-calendar ...` for `ikiwiki --refresh
+> > ...` in cron to get the same result.
+> >
+> > I
+> > [[tried|https://github.com/paternal/ikiwiki/commit/7a92444e56fe023cea3b074dc5e6b5c4acdb6114]]
+> > to make the documentation clearer.
+>
+> [[!format diff """
+-\[[!template id=plugin name=calendar author="\[[ManojSrivastava]]"]]
+-\[[!tag type/widget]]
+"""]]
+>
+> Why did you remove that? It's useful information about the plugin
+> which I think ought to stay.
+>
+> > Oops! It was a mistake.
+> > [[Corrected|https://github.com/paternal/ikiwiki/commit/de9842ecc8914e11e73148dae78cd6909b535262]].
+>
+> --[[smcv]]
+>
+> > Thank you for this review. -- [[Louis|spalax]]
+
+---
+
+[[smcv]], can you please go on reviewing this?
+
+> I don't think I'm really the reviewer you want, since I don't have commit
+> access (as you might be able to tell from the number of pending branches
+> I have)... but nobody with commit access seems to be available to do
+> reviews at the moment, so I'm probably the best you're going to get.
+>
+>     +    0 0 * * * ikiwiki ~/ikiwiki.setup --refresh
+>
+> I think that should be `ikiwiki --setup ~/ikiwiki.setup --refresh`
+>
+> The indentation of some of the new code in `IkiWiki/Plugin/calendar.pm`
+> is weird. Please use one hard tab (U+0009) per indent step: you seem
+> to have used a mixture of one hard tab per indent or two spaces
+> per indent, which looks bizarre for anyone whose tab size is not
+> 2 spaces.
+>
+>     +        return unless $config{calendar_autocreate};
+>
+> This is checked in `gencalendaryear` but not in `gencalendarmonth`.
+> Shouldn't `gencalendarmonth` do it too? Alternatively, do the check
+> in `scan`, which calls `gencalendarmonth` directly.
+>
+>     +                my $year  = $date[5] + 1900;
+>
+> You calculate this, but you don't seem to do anything with it?
+>
+>     +  if (not exists $changed{$params{year}}) {
+>     +    $changed{$params{year}} = ();
+>     +  }
+>     +  $changed{$params{year}}{$params{month}} = 1;
+>
+> `$changed{$params{year}}` is a scalar (you can tell because it starts with the
+> `$` sigil) but `()` is a list. I think you want `{}`
+> (a scalar that is a reference to an empty anonymous hash).
+>
+> However, that whole `if` block can be omitted, and you can just use
+> `$changed{$params{year}}{$params{month}} = 1;`, because Perl will automatically
+> create `$changed{$params{year}}` as a reference to an empty hash if necessary,
+> in order to put the pair `$params{month} => 1` in it (the term to look
+> up if you're curious is "autovivification").
+>
+> --[[smcv]]
index 4059d8e2ac83d092bb5210549159082a581ef0f3..50720fed04d06cd69a260323d373cea2852526b6 100644 (file)
@@ -30,6 +30,35 @@ Discussion
 > > 
 > > Originally, I named that parameter `backwards_links`, but then it wouldn't make sense in the long term, and isn't exactly neutral: it assume the current way is backwards! Your suggestion is interesting however, but I don't think the rtl/ltr nomenclature is problematic, with proper documentation of course... --[[anarcat]]
 
+> > > I still don't think `rtl`/`ltr` is the right terminology here. I think
+> > > the "API" should say what you mean: the distinction being made is
+> > > "text first" vs. "link first", so, say that.
+> > >
+> > > As far as I understand it, RTL languages like Arabic typically write
+> > > text files "in logical order" (i.e. reading/writing order - first
+> > > letter is first in the bytestream) and only apply RTL rendering on
+> > > display. IkiWiki is UTF-8-only, and Unicode specifies that all
+> > > Unicode text should be in logical order. The opposite of logical
+> > > order is is "display order", which is how you would have to mangle
+> > > the file for it to appear correctly on a naive terminal that expects
+> > > LTR; that can only work correctly for hard-wrapped text, I think.
+> > >
+> > > IkiWiki will parse files
+> > > in logical order too; so if a link's text and destination are both
+> > > written in Arabic, in text-before-link order in the source code, an
+> > > Arabic reader starting from the right would still see the text
+> > > before the link. Similarly, in your proposed link-before-text
+> > > order, an Arabic reader would still see the link before the text
+> > > (which in their case means further to the right). So I don't think
+> > > it would make sense to suggest that
+> > > one order was more appropriate for RTL languages than the other: if
+> > > it's "more correct" (for whatever opinion of "correct") in English, then
+> > > it's "more correct" in Arabic too.
+> > >
+> > > (If the destination is written in Latin then it gets
+> > > more complicated, because the destination will be rendered LTR within an
+> > > otherwise RTL document. I think the order still works though.) --[[smcv]]
+
 There's a caveat: we can't have a per-wiki backwards_links option, because of the underlay, common to all wikis, which needs to be converted. So the option doesn't make much sense. Not sure how to deal with this... Maybe this needs to be at the package level? --[[anarcat]]
 
 > I've thought about adding a direction-neutral `\[[!link]]` directive -
@@ -80,6 +109,7 @@ I think we can approach this rationnally:
 
  1. left to right (text then link) can be considered more natural, and should therefore be supported
  2. it is supported in markdown using regular markdown links. in the proposed branch, the underlay wikilinks are converted to use regular markdown links
+    > Joey explicitly rejected this for a valid reason (it breaks inlining). See above. --[[smcv]]
  3. ikiwiki links break other markup plugins, like mediawiki and creole, as those work right to left.
  4. those are recognized "standards" used by other popular sites, like Wikipedia, or any wiki supporting the Creole markup, which is [most wikis](http://www.wikicreole.org/wiki/Engines)
 
index 18afb3df26b4656f432b0ebb1f231ee199e76a3d..4dfbb1486cddf2427ddf35fe9a2f445673d5e528 100644 (file)
@@ -1,6 +1,6 @@
 [[!template id=gitbranch branch=smcv/ready/document-success-reason author="[[smcv]]"
 browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/document-success-reason]]
-[[!tag patch]]
+[[!tag patch users/smcv/ready]]
 
 Whenever I look at dependency calculation, for instance to solve
 [[bugs/editing gitbranch template is really slow]], it takes me a while to
@@ -20,3 +20,9 @@ should count as static or dynamic, perhaps analogous to
 and linked from the `match_foo` section of [[plugins/write]]. I haven't
 written this myself because I'm somewhat stuck on the subtlety of what
 "indirectly influenced" means... --[[smcv]]
+
+>> the documentation looks correct to me, as far as i understand dependencies.
+>> the documentation on `influences_static` could add a "Static influences are
+>> what make `pagespec_match_list` more efficient than repeated
+>> `pagespec_match_list`." to give an idea of why it is there in the first
+>> place. --[[chrysn]]
index b85f3298b4565e9e99c1b75d729132ccb9c48c9a..e5a8d0ab9eaf8a480a0aa35eeac856d8732a6e25 100644 (file)
@@ -47,10 +47,10 @@ Changes to the structure of `$pagestate{$registering_page}{edittemplate}{$pagesp
 >> better way based on that, maybe global configuration in `$config`.
 >> --[[smcv]]
 
->>> [[!template id=gitbranch branch=smcv/ready/edittemplate
-  browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/edittemplate
+>>> [[!template id=gitbranch branch=smcv/ready/edittemplate2
+  browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/edittemplate2
   author="Jonathon Anderson, [[smcv]]"]]
->>> Here is a version of that branch that I would merge if I could.
+>>> Here is a version of that branch that I [[would merge|users/smcv/ready]] if I could.
 >>> Changes since Jonathon's version:
 >>>
 >>> * only generate a UUID if needed
@@ -70,3 +70,16 @@ Changes to the structure of `$pagestate{$registering_page}{edittemplate}{$pagesp
 >>> timestamp variables/objects, so I left the naming as it was.
 >>>
 >>> --[[smcv]]
+
+>>>> the ready/edittemplate branch looks good to me too. `formatted_time` and
+>>>> `html_time` probably don't hurt, but personally i'd not add either and
+>>>> instead expose displaytime as a directive, for otherwise migrating to
+>>>> html5 would leave old evaluations of displaytime around in the repository.
+>>>> (example template: `\[[!meta date="<TMPL_VAR time>"]]I wrote this post at
+>>>> \[[!displaytime "<TMPL_VAR time>"]]`). --[[chrysn]]
+
+>>>>> That's a very good point; and Joey added `\[[!date "<TMPL_VAR time">]]`,
+>>>>> which does the same thing as your hypothetical `\[[!displaytime]]`,
+>>>>> almost 5 years ago. Branch replaced by `smcv/ready/edittemplate2`
+>>>>> which drops `formatted_time` and `html_time`, and adds a suggestion
+>>>>> to use `\[[!date]]`. --[[smcv]]
index f321e4f5299bddab3e2649bb84246326710c068f..65032fabfa36d8f0f801d45d87a148264a1b0b10 100644 (file)
@@ -9,7 +9,7 @@ This means:
 
 The [[patch]] is currently being used on http://addons.nvda-project.org and seems to work well. --[[mhameed]]
 
-> I don't have commit access, but it [[seems reasonable|/users/smcv/yesplease]].
+> I don't have commit access, but it [[seems reasonable|/users/smcv/ready]].
 > --[[smcv]]
 
 >> [[done]]] --[[Joey]]
index cb1ff2b1d38fe7a1895ab96ee688cc9433a91256..e09e03e9ee2c5c2d9cb313d7cc5c764104a99dac 100644 (file)
@@ -109,6 +109,8 @@ details
   >> the [[matching different kinds of links]] discussion, but it was removed
   >> in favor of per-type matchers. --[[chrysn]]
 
+  >>> note to self: should use the ``inject`` function to avoid `no strict refs`. --[[chrysn]]
+
 * configuration location
 
   i aimed for static configuration of the `block_names` in the setup file. this
index 4120b8432a7609c53183987412c5cefbe7970f0f..5449c0543edb3d3c292fa15d01dfa6ada9df6ccb 100644 (file)
@@ -1,4 +1,7 @@
 ikiwiki could support manpages (or general groff input files) and convert them
 to HTML. --[[JoshTriplett]]
 
+> I wrote [[plugins/contrib/mandoc]] a while back. Just noticed
+> this wishlist item. --[[Schmonz]]
+
 [[wishlist]]
diff --git a/doc/todo/pagespec__95__match__95__list_can_result_in_excessive_dependencies.mdwn b/doc/todo/pagespec__95__match__95__list_can_result_in_excessive_dependencies.mdwn
new file mode 100644 (file)
index 0000000..9781f75
--- /dev/null
@@ -0,0 +1,41 @@
+If you say
+
+    pagespec_match_list($page, $spec, list => \@pages)
+
+with a small list `@pages` and a vague pagespec `$spec`, `$page` ends
+up depending on (every page that matches) `$spec`. For instance, if you
+already have a list of subpages of the sandbox, and you want to filter it
+to only the discussion pages, you can do that like
+
+    pagespec_match_list("sandbox", "*/discussion",
+        list => ["sandbox/discussion", "sandbox/things", "sandbox/stuff"])
+
+but then a change to *any* discussion page will refresh the sandbox.
+
+The [[bugs/trails depend on everything]] bug was a particularly bad
+case of this, with the widest possible pagespec `internal(*)`
+matched against a small list (the trail).
+
+In principle it would be nice if `pagespec_match_list` could detect
+this situation and make sandbox depend on only those subpages instead.
+
+Perhaps if the `list` parameter is given, `p_m_l` should add a
+by-name (simple) dependency on each page in that list, instead
+of a dependency on the pagespec? Or perhaps it should be documented
+that plugins can pass `deptype => 0` to take responsibility for
+their own dependency handling, and then do whatever they need?
+
+Uses of `pagespec_match_list` with a non-trivial list, in-tree,
+after [[bugs/trails depend on everything]] is fixed:
+
+* brokenlinks: really does need to depend on the whole pagespec,
+  but that could be done separately
+
+* inline: the inliner already depends on the inlined pages
+  so no extra dependency is needed
+
+* pagestats: same as brokenlinks
+
+My album plugin is in the same situation as inline.
+
+--[[smcv]]
diff --git a/doc/todo/per-page_comment_control.mdwn b/doc/todo/per-page_comment_control.mdwn
new file mode 100644 (file)
index 0000000..69937d7
--- /dev/null
@@ -0,0 +1,31 @@
+It might be nice to be able to control [[plugins/comments]] by inserting
+directives in individual pages:
+
+* disable comments where they would normally be enabled, e.g. for a blog
+  post you know is going to cause flamey responses (`\[[!closecomments]]`
+  to reject new comments but display old ones, `\[[!nocomments]]` to
+  hide comments too?)
+
+* direct comments to a different wiki page or an off-site URL,
+  e.g. if you have mentioned/posted something in two places
+  and you want to collect all the comments together
+  (maybe `\[[!commenton page=other/page]]`,
+  `\[[!commenton url="http://newsblog.example.com/the-next-big-thing"]]`?)
+
+* (maybe) enable comments where they would not normally be enabled?
+  (I'm unsure about this one, it would need to be under some level of
+  admin control - maybe a new pagespec for pages where comments are
+  disabled by default but may be enabled by directives)
+
+The use that got me thinking about this is that if the
+[[plugins/contrib/album]] plugin evolves to be able to have the same
+picture appear in more than one trail as kjs requested, all except the
+"original" (defined as the page to which the picture was attached) should
+probably either disable comments, or direct comments to the "original".
+
+I don't plan to work on this myself unless I find that I need it
+(for album or otherwise).
+
+--[[smcv]]
+
+[[!tag wishlist]]
index a454d7da5d6565fa4e475fca5cef8af1ff5e0c49..5a55fcce5b8977612b3e3f360cf6a59dbc8179ba 100644 (file)
@@ -5,7 +5,7 @@ I hope it's a bug, not a feature and you fix it soon :) --[[Paweł|ptecza]]
 
 > ikiwiki only allows a very limited set of characters raw in page names,
 > this is done as a deny-by-default security thing. All other characters
-> need to be encoded in __code__ format, where "code" is the character
+> need to be encoded in `__code__` format, where "code" is the character
 > number. This is normally done for you, but if you're adding a page
 > manually, you need to handle it yourself. --[[Joey]]
 
@@ -48,6 +48,11 @@ I hope it's a bug, not a feature and you fix it soon :) --[[Paweł|ptecza]]
 >>>>>> What's your locale? I have both pl\_PL (ISO-8859-2) and pl\_PL.UTF-8,
 >>>>>> but I use pl\_PL. Is it wrong? --[[Paweł|ptecza]]
 
+>>>>>>> IkiWiki assumes UTF-8 throughout, so escaped filename characters
+>>>>>>> should be `__x____y____z__` where x, y, z are the bytes of the
+>>>>>>> UTF-8 encoding of the character. I don't know how to achieve that
+>>>>>>> from a non-UTF-8 locale. --[[smcv]]
+
 >>>> Now, as to UTF7, in retrospect, using a standard encoding might be a
 >>>> better idea than coming up with my own encoding for filenames. Can 
 >>>> you provide a pointer to a description to modified-UTF7? --[[Joey]]
@@ -58,4 +63,38 @@ I hope it's a bug, not a feature and you fix it soon :) --[[Paweł|ptecza]]
 >>>>> There is a Perl [Unicode::IMAPUtf7](http://search.cpan.org/~fabpot/Unicode-IMAPUtf7-2.01/lib/Unicode/IMAPUtf7.pm)
 >>>>> module at the CPAN, but probably it hasn't been debianized yet :( --[[Paweł|ptecza]]
 
+> Note: [libencode-imaputf7-perl][1] has made it into debian.
+>
+>> "IMAP UTF-7" uses & as an escape character, which seems like a recipe
+>> for shell injection vulnerabilities... so I would not recommend it
+>> for this particular use. --[[smcv]]
+
+> I would value some clarification, in the ikiwiki setup file I have
+>
+>     wiki_file_chars: -[:alnum:][\p{Arabic}()]+/.:_
+>
+> Ikiwiki doesn't seem to produce any errors on the commandline for this, but
+> when I attempt to create a new post with Arabic characters from the web I get the following error :
+>
+>     Error: Cannot decode string with wide characters at /usr/lib/x86_64-linux-gnu/perl/5.20/Encode.pm line 215. 
+>
+> Should the modified regexp not be sufficient?
+> Ikiwiki 3.20140815.
+> --[[mhameed]]
+
+>> This seems like a bug: in principle non-ASCII in `wiki_file_chars` should work,
+>> in practice it does not. I would suggest either using the default
+>> `wiki_file_chars`, or digging into the code to find what is wrong.
+>> Solving this sort of bug usually requires having a clear picture of
+>> which "strings" are bytestrings, and which "strings" are Unicode. --[[smcv]]
+
+>>> mhameed confirmed on IRC that anarcat's [[patch]] from
+>>> [[bugs/garbled_non-ascii_characters_in_body_in_web_interface]] fixes this.
+>>> --[[smcv]]
+
+>>>> Merged that patch. Not marking this page as done, because the todo
+>>>> about using a standard encoding still stands (although I'm not at
+>>>> all sure there's an encoding that would be better). --[[smcv]]
+
 [[wishlist]]
+[1]: https://packages.debian.org/search?suite=all&section=all&arch=any&searchon=names&keywords=libencode-imaputf7-perl
index ab6172ad1dc8a40fd95c56e718f57ab75376ade3..ae7d23ce9058e20ad5495a414fbf75d7f913eed0 100644 (file)
@@ -36,7 +36,7 @@ the substitution of `\[[file]]` in `diffurl` and `historyurl`?
 >>>> \[[file_less_escaped]], and I can't think of one.
 >>>>
 >>>> I don't have commit access to ikiwiki.info, but if I did,
->>>> [[I'd merge this|/users/smcv/yesplease]]. --[[smcv]]
+>>>> [[I'd merge this|/users/smcv/ready]]. --[[smcv]]
 
 >>>>> [[merged|done]] --[[Joey]]
 
diff --git a/doc/todo/support_multi-row_table_headers.mdwn b/doc/todo/support_multi-row_table_headers.mdwn
new file mode 100644 (file)
index 0000000..6f13bbb
--- /dev/null
@@ -0,0 +1,79 @@
+[[!template id=gitbranch branch=jon/table_headerblock author="[[Jon]]"]]
+It would be great if it were possible to support multi-row table headers in the [[plugins/table]] plugin, so you could do e.g.
+
+        \[[!table header="""
+        Name | Platform ||
+        | Windows | Mac | Linux
+        """ data="""
+        ikiwiki | ‧ | ✓ | ✓
+        """]]
+
+-- [[Jon]]
+
+[[!tag wishlist patch]]
+
+> This seems like weird overloading of the header parameter - it's
+> table data, except when it isn't.
+
+> > My first cut (now rebased out of existence I think) introduced a
+> > new "headerblock" parameter, but trying to clearly document the
+> > interaction of data/headerblock/header parameters was too awkward. -- [[Jon]]
+
+> Perhaps
+> something like this would be easier to use in practice?
+> (and also more featureful :-) )
+>
+>     \[[!table header="2 rows 1 column" data="""
+>     Name | Platform ||
+>     | Windows | Mac | Linux
+>     ikiwiki | no | yes | yes
+>     Starcraft | yes | yes | via Wine
+>     """]]
+
+> > Thanks for your prompt feedback!
+> > 
+> > This would probably be good, yes, and having mixed row/column headers is
+> > definitely a nice-to-have. I don't relish the prospect of writing the parser
+> > but I see you've made a stab already...
+> > 
+> > One thing you'd lose, but it's debatable whether this is valuable, would be
+> > to have the header defined in the directive, and the remaining table data
+> > declared in an external CSV. -- [[Jon]]
+
+> intended to be rendered like
+>
+> <table>
+> <tr><th>Name</th><th colspan=2>Platform</th>
+> <tr><th></th><th>Windows</th><th>Mac</th><th>Linux</th></tr>
+> <tr><th>ikiwiki</th><td>no</td><td>yes</td><td>yes</td></tr>
+> <tr><th>Starcraft</th><td>yes</td><td>yes</td><td>via Wine</td></tr>
+> </table>
+>
+> (Deliberately switching to plain-text to make it more obvious
+> what's a `<th>` and what's `<td>`.)
+>
+> Vague pseudocode for parsing `headers`
+> (possibly even valid Perl, I'm not sure):
+>
+>     my ($header_rows, $header_cols);
+>     while ($header =~ s/(\d*)\W*(\w+)//) {
+>         my $n = ($1 or 0);
+>         my $what = $2;
+>         if ($what =~ m/rows?/) {
+>             $header_rows = $n;
+>         }
+>         elif ($what =~ m/col(?:umn)?s?/) {
+>             $header_cols = $n;
+>         }
+>     }
+>
+> and it would even be fairly easy to extend to support
+> `(first|last|)\W*(\d*)\W*(\w+)` later, e.g.
+> `header="1 row, first 2 cols, last column"`.
+>
+> --[[smcv]]
+
+> > To be clear I think your suggestion is a good one, but my hack has
+> > addressed my immediate need so it's the one I'm deploying at $ork for the
+> > time being. I'm unlikely to have time to implement this solution in the
+> > near future. -- [[Jon]]
index 52034c21bf9e283b16eeea686a64b13b35188de3..d8dd65921505b63a8f06f358a7de3e6110c7a410 100644 (file)
@@ -8,3 +8,13 @@ Unfortunately, Github shows [[raw code|https://github.com/paternal/ikiwiki/blob/
 
 --[[Louis|spalax]]
 
+> Unfortunately SVG can contain embedded JavaScript, so anyone who can
+> upload arbitrary SVG to this wiki can execute JavaScript in its security
+> context, leading to stealing login cookies and other badness. GitHub
+> won't display arbitrary user-supplied SVG for the same reasons.
+>
+> I've seen various attempts to sanitize SVG via a whitelist, but it's
+> just too large a specification to be confident that you're right, IMO.
+>
+> This particular SVG [[looks good to me|users/smcv/ready]] and I've
+> mirrored it in my own git repo. --[[smcv]]
index cfe13c6851fa2dc16b68cf946911b357e523181e..d65b663c81000fb9e91f013ec7e83e2e9f197bf8 100644 (file)
@@ -5,4 +5,7 @@ Websites using ikiwiki:
 * <http://img.kalleswork.net>
 * <http://stockholm.kalleswork.net>
 
-Mostly using ikiwiki with the [[/plugins/contrib/album/]] and [[plugins/osm]] plugins.
+
+Mostly using ikiwiki with the [[/plugins/contrib/album/]] and [[plugins/osm]] plugins. My git repo with tweaks including the simplebw theme and changes to the [[plugins/contrib/album]] templates can be cloned via http at:
+
+* <http://src.kalleswork.net/ikiwiki.git>
index b92145ce43c755de373242e78ddf98ab0a67e67e..7b450f4c648c0e0c8277738646dbbc0ab14aa1d2 100644 (file)
@@ -1 +1 @@
-Running ikiwiki on [homepage](http://mesarhameed.info/) also responsible for <http://addons.nvda-project.org>.
+Running ikiwiki on [personal site](http://mesarhameed.info/) also responsible for <http://addons.nvda-project.org> and <http://liblouis.org>.
index a4eb564cefd9108174b258b7db31a05e3997ba28..9835049c32dd0e8b24a1be696a7eb72629159801 100644 (file)
@@ -7,4 +7,4 @@ My repository containing ikiwiki branches:
 * gitweb: http://git.pseudorandom.co.uk/smcv/ikiwiki.git
 * anongit: git://git.pseudorandom.co.uk/git/smcv/ikiwiki.git
 
-Recently tried to [[help with the review backlog|yesplease]].
+Recently tried to [[help with the review backlog|users/smcv/ready]].
similarity index 51%
rename from doc/users/smcv/yesplease.mdwn
rename to doc/users/smcv/ready.mdwn
index b100b374ee96b024580b56a7aabba9f1bafab9d0..ed8aa2618523bbcc33c9e37d6dad3720e1cfaf77 100644 (file)
@@ -1,7 +1,10 @@
 A tag for patches that I would merge if I had commit access to ikiwiki,
 in the hope that it's a useful shortlist for committers to look at.
-They're mirrored in my git repository under the `ready/*` namespace.
+Two categories:
+
+* my own branches, in my git repository under the `ready/*` namespace
+* other people's branches, mirrored in my git repo in the same namespace
 
 [[!inline pages="(todo/* or bugs/*) and link(patch) and !link(bugs/done) and
-   !link(todo/done) and link(users/smcv/yesplease) and !*/Discussion"
+   !link(todo/done) and link(users/smcv/ready) and !*/Discussion"
    archive="yes"]]
index 0727276a19b6194faf6ca660b35189321e63df9c..d5867ca9e7e0f98b25f9d8fde3a88b02748388d6 100644 (file)
@@ -6,15 +6,14 @@ User of IkiWiki.
 
 I wrote and maintain a few plugins, which are available here: [[https://atelier.gresille.org/projects/gresille-ikiwiki]].
 
-[[!map pages="plugins/contrib/* and ! plugins/contrib/*/* and link(.)"]]
+[[!map pages="plugins/contrib/* and ! plugins/contrib/*/* and author(spalax)"]]
 
 # Wishlist
 
 I have a few things in mind. Their status is something between *I will implement it someday* to *maybe someone could need this* or *I will need it if I implement this killer website I have in mind*.
 
-* [[plugins/contrib/jssearchtag]]: Create a page where user can tick or untick any combination of tag (s)he want, and dynamically sees an inline of the matching pages. I have to see to what extent the [[plugins/contrib/jssearchfield|jssearchfield]] plugin already does the same thing (not tested yet).
 * [[plugins/contrib/htaccessmanager]]: Create a cgi page to manage a htaccess file.
-* Automatically add calendar pages (see the [[ikiwiki-calendar discussion|ikiwiki-calendar/discussion]]).
+* Automatically add calendar pages (WIP: see the [[ikiwiki-calendar discussion|ikiwiki-calendar/discussion]]).
 
 
 # Contact
index 74f6419dbbe4832a1a0f58675b598205d41cf585..83c110321b9ea9bafc8e7976eb2645ee973dda44 100644 (file)
@@ -1,5 +1,5 @@
 Name:           ikiwiki
-Version: 3.20140613
+Version: 3.20140831
 Release:        1%{?dist}
 Summary:        A wiki compiler
 
index d70a967a5b706845202121b0be77352c47924036..b61eb466c8d47ef839fc24e5d0ba54be3a9b23fa 100755 (executable)
@@ -158,15 +158,24 @@ class _IkiWikiExtPluginXMLRPCHandler(object):
     def send_rpc(self, cmd, in_fd, out_fd, *args, **kwargs):
         xml = _xmlrpc_client.dumps(sum(kwargs.items(), args), cmd)
         self._debug_fn(
-            "calling ikiwiki procedure `{0}': [{1}]".format(cmd, xml))
-        _IkiWikiExtPluginXMLRPCHandler._write(out_fd, xml.encode('utf8'))
+            "calling ikiwiki procedure `{0}': [{1}]".format(cmd, repr(xml)))
+        # ensure that encoded is a str (bytestring in Python 2, Unicode in 3)
+        if str is bytes and not isinstance(xml, str):
+            encoded = xml.encode('utf8')
+        else:
+            encoded = xml
+        _IkiWikiExtPluginXMLRPCHandler._write(out_fd, encoded)
 
         self._debug_fn('reading response from ikiwiki...')
 
-        xml = _IkiWikiExtPluginXMLRPCHandler._read(in_fd).decode('utf8')
+        response = _IkiWikiExtPluginXMLRPCHandler._read(in_fd)
+        if str is bytes and not isinstance(response, str):
+            xml = response.encode('utf8')
+        else:
+            xml = response
         self._debug_fn(
             'read response to procedure {0} from ikiwiki: [{1}]'.format(
-                cmd, xml))
+                cmd, repr(xml)))
         if xml is None:
             # ikiwiki is going down
             self._debug_fn('ikiwiki is going down, and so are we...')
index fb0d1bde5c6df985f60b168dc1b01965f1bcb096..1dbd77f7a8bc0ee145b7b2b8d771aaadc8e30b9c 100644 (file)
@@ -8,7 +8,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2014-01-25 16:44-0400\n"
+"POT-Creation-Date: 2014-08-31 14:18-0700\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"
@@ -28,7 +28,7 @@ msgstr ""
 msgid "login failed, perhaps you need to turn on cookies?"
 msgstr ""
 
-#: ../IkiWiki/CGI.pm:222 ../IkiWiki/CGI.pm:373
+#: ../IkiWiki/CGI.pm:222 ../IkiWiki/CGI.pm:374
 msgid "Your login session has expired."
 msgstr ""
 
@@ -52,7 +52,7 @@ msgstr ""
 msgid "You are banned."
 msgstr ""
 
-#: ../IkiWiki/CGI.pm:464 ../IkiWiki/CGI.pm:465 ../IkiWiki.pm:1515
+#: ../IkiWiki/CGI.pm:465 ../IkiWiki/CGI.pm:466 ../IkiWiki.pm:1533
 msgid "Error"
 msgstr ""
 
@@ -120,16 +120,16 @@ msgstr ""
 msgid "(feed entities escaped)"
 msgstr ""
 
-#: ../IkiWiki/Plugin/aggregate.pm:556
+#: ../IkiWiki/Plugin/aggregate.pm:558
 msgid "feed crashed XML::Feed!"
 msgstr ""
 
-#: ../IkiWiki/Plugin/aggregate.pm:650
+#: ../IkiWiki/Plugin/aggregate.pm:652
 #, perl-format
 msgid "creating new page %s"
 msgstr ""
 
-#: ../IkiWiki/Plugin/aggregate.pm:678 ../IkiWiki/Plugin/edittemplate.pm:135
+#: ../IkiWiki/Plugin/aggregate.pm:682 ../IkiWiki/Plugin/edittemplate.pm:137
 msgid "failed to process template:"
 msgstr ""
 
@@ -171,15 +171,15 @@ msgstr ""
 msgid "bad attachment filename"
 msgstr ""
 
-#: ../IkiWiki/Plugin/attachment.pm:296
+#: ../IkiWiki/Plugin/attachment.pm:298
 msgid "attachment upload"
 msgstr ""
 
-#: ../IkiWiki/Plugin/attachment.pm:347
+#: ../IkiWiki/Plugin/attachment.pm:349
 msgid "this attachment is not yet saved"
 msgstr ""
 
-#: ../IkiWiki/Plugin/attachment.pm:365
+#: ../IkiWiki/Plugin/attachment.pm:367
 msgid "just uploaded"
 msgstr ""
 
@@ -333,8 +333,8 @@ msgid "creating %s"
 msgstr ""
 
 #: ../IkiWiki/Plugin/editpage.pm:337 ../IkiWiki/Plugin/editpage.pm:356
-#: ../IkiWiki/Plugin/editpage.pm:367 ../IkiWiki/Plugin/editpage.pm:412
-#: ../IkiWiki/Plugin/editpage.pm:454
+#: ../IkiWiki/Plugin/editpage.pm:367 ../IkiWiki/Plugin/editpage.pm:414
+#: ../IkiWiki/Plugin/editpage.pm:456
 #, perl-format
 msgid "editing %s"
 msgstr ""
@@ -378,26 +378,26 @@ msgstr ""
 msgid "%s is an attachment, not a page."
 msgstr ""
 
-#: ../IkiWiki/Plugin/git.pm:828 ../IkiWiki/Plugin/git.pm:891
-#: ../IkiWiki.pm:1735
+#: ../IkiWiki/Plugin/git.pm:839 ../IkiWiki/Plugin/git.pm:902
+#: ../IkiWiki.pm:1753
 #, perl-format
 msgid "you are not allowed to change %s"
 msgstr ""
 
-#: ../IkiWiki/Plugin/git.pm:850
+#: ../IkiWiki/Plugin/git.pm:861
 #, perl-format
 msgid "you cannot act on a file with mode %s"
 msgstr ""
 
-#: ../IkiWiki/Plugin/git.pm:854
+#: ../IkiWiki/Plugin/git.pm:865
 msgid "you are not allowed to change file modes"
 msgstr ""
 
-#: ../IkiWiki/Plugin/git.pm:924
+#: ../IkiWiki/Plugin/git.pm:935
 msgid "you are not allowed to revert a merge"
 msgstr ""
 
-#: ../IkiWiki/Plugin/git.pm:941
+#: ../IkiWiki/Plugin/git.pm:952
 #, perl-format
 msgid "Failed to revert commit %s"
 msgstr ""
@@ -415,17 +415,17 @@ msgstr ""
 msgid "prog not a valid graphviz program"
 msgstr ""
 
-#: ../IkiWiki/Plugin/highlight.pm:83
+#: ../IkiWiki/Plugin/highlight.pm:91
 #, perl-format
 msgid "tohighlight contains unknown file type '%s'"
 msgstr ""
 
-#: ../IkiWiki/Plugin/highlight.pm:94
+#: ../IkiWiki/Plugin/highlight.pm:102
 #, perl-format
 msgid "Source code: %s"
 msgstr ""
 
-#: ../IkiWiki/Plugin/highlight.pm:180
+#: ../IkiWiki/Plugin/highlight.pm:198
 msgid ""
 "warning: highlight perl module not available; falling back to pass through"
 msgstr ""
@@ -489,12 +489,12 @@ msgstr ""
 msgid "Add a new post titled:"
 msgstr ""
 
-#: ../IkiWiki/Plugin/inline.pm:394 ../IkiWiki/Plugin/template.pm:44
+#: ../IkiWiki/Plugin/inline.pm:396 ../IkiWiki/Plugin/template.pm:46
 #, perl-format
 msgid "failed to process template %s"
 msgstr ""
 
-#: ../IkiWiki/Plugin/inline.pm:733
+#: ../IkiWiki/Plugin/inline.pm:735
 msgid "RPC::XML::Client not found, not pinging"
 msgstr ""
 
@@ -516,7 +516,7 @@ msgstr ""
 msgid "multimarkdown is enabled, but Text::MultiMarkdown is not installed"
 msgstr ""
 
-#: ../IkiWiki/Plugin/mdwn.pm:96
+#: ../IkiWiki/Plugin/mdwn.pm:97
 #, perl-format
 msgid "failed to load Markdown.pm perl module (%s) or /usr/bin/markdown (%s)"
 msgstr ""
@@ -673,70 +673,70 @@ msgid ""
 "po_link_to=default"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:467
+#: ../IkiWiki/Plugin/po.pm:473
 msgid "updated PO files"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:490
+#: ../IkiWiki/Plugin/po.pm:496
 msgid ""
 "Can not remove a translation. If the master page is removed, however, its "
 "translations will be removed as well."
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:510
+#: ../IkiWiki/Plugin/po.pm:516
 msgid ""
 "Can not rename a translation. If the master page is renamed, however, its "
 "translations will be renamed as well."
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:956
+#: ../IkiWiki/Plugin/po.pm:975
 #, perl-format
 msgid "POT file (%s) does not exist"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:970
+#: ../IkiWiki/Plugin/po.pm:989
 #, perl-format
 msgid "failed to copy underlay PO file to %s"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:979
+#: ../IkiWiki/Plugin/po.pm:998
 #, perl-format
 msgid "failed to update %s"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:985
+#: ../IkiWiki/Plugin/po.pm:1004
 #, perl-format
 msgid "failed to copy the POT file to %s"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:1021
+#: ../IkiWiki/Plugin/po.pm:1040
 msgid "N/A"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:1032
+#: ../IkiWiki/Plugin/po.pm:1051
 #, perl-format
 msgid "failed to translate %s"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:1111
+#: ../IkiWiki/Plugin/po.pm:1134
 msgid "removed obsolete PO files"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:1168 ../IkiWiki/Plugin/po.pm:1180
-#: ../IkiWiki/Plugin/po.pm:1219
+#: ../IkiWiki/Plugin/po.pm:1191 ../IkiWiki/Plugin/po.pm:1203
+#: ../IkiWiki/Plugin/po.pm:1242
 #, perl-format
 msgid "failed to write %s"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:1178
+#: ../IkiWiki/Plugin/po.pm:1201
 msgid "failed to translate"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:1231
+#: ../IkiWiki/Plugin/po.pm:1254
 msgid "invalid gettext data, go back to previous page to continue edit"
 msgstr ""
 
-#: ../IkiWiki/Plugin/po.pm:1274
+#: ../IkiWiki/Plugin/po.pm:1297
 #, perl-format
 msgid "%s has invalid syntax: must use CODE|NAME"
 msgstr ""
@@ -1274,54 +1274,54 @@ msgstr ""
 msgid "Discussion"
 msgstr ""
 
-#: ../IkiWiki.pm:587
+#: ../IkiWiki.pm:595
 msgid "Must specify url to wiki with --url when using --cgi"
 msgstr ""
 
-#: ../IkiWiki.pm:635
+#: ../IkiWiki.pm:643
 #, perl-format
 msgid "unsupported umask setting %s"
 msgstr ""
 
-#: ../IkiWiki.pm:675
+#: ../IkiWiki.pm:683
 msgid "cannot use multiple rcs plugins"
 msgstr ""
 
-#: ../IkiWiki.pm:705
+#: ../IkiWiki.pm:713
 #, perl-format
 msgid "failed to load external plugin needed for %s plugin: %s"
 msgstr ""
 
-#: ../IkiWiki.pm:1497
+#: ../IkiWiki.pm:1515
 #, perl-format
 msgid "preprocessing loop detected on %s at depth %i"
 msgstr ""
 
-#: ../IkiWiki.pm:1691
+#: ../IkiWiki.pm:1709
 #, perl-format
 msgid "bad file name %s"
 msgstr ""
 
-#: ../IkiWiki.pm:2000
+#: ../IkiWiki.pm:2019
 #, perl-format
 msgid "template %s not found"
 msgstr ""
 
-#: ../IkiWiki.pm:2250
+#: ../IkiWiki.pm:2269
 msgid "yes"
 msgstr ""
 
-#: ../IkiWiki.pm:2334
+#: ../IkiWiki.pm:2354
 #, perl-format
 msgid "invalid sort type %s"
 msgstr ""
 
-#: ../IkiWiki.pm:2355
+#: ../IkiWiki.pm:2375
 #, perl-format
 msgid "unknown sort type %s"
 msgstr ""
 
-#: ../IkiWiki.pm:2491
+#: ../IkiWiki.pm:2511
 #, perl-format
 msgid "cannot match pages: %s"
 msgstr ""