ikiwiki/ bugs/ done

recently fixed bugs

tbasewiki_brokenlinks.t broken

t/basewiki_brokenlinks.t was failing with the following error:

t/basewiki_brokenlinks.....Can't locate IkiWiki.pm in @INC (@INC contains: /etc/perl /usr/lib/perl5/vendor_perl/5.8.8/i686-linux
/usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib/perl5/site_perl/5.8.8/i686-linux /usr/lib/perl5/site_perl/5.8.8
/usr/lib/perl5/site_perl /usr/lib/perl5/5.8.8/i686-linux /usr/lib/perl5/5.8.8 /usr/local/lib/site_perl) at ./ikiwiki.out line 9.

When ikiwiki.out is executed the 'blib/lib' directory isn't inherited by the child process. I can add "use lib 'blib/lib'" to ikiwiki.out easily enough, but I can't figure out how to add it to ikiwiki.in so that pm_filter doesn't strip it out.

Anyway, once the 'use lib' is added I get the following error:

t/basewiki_brokenlinks.....ok 1/3Can't locate object method "new" via package "HTML::Template" at blib/lib/IkiWiki.pm line 858.

After some digging I found that HTML::Template is being required after the new statement, again, easily fixed:

Index: IkiWiki.pm
===================================================================
--- IkiWiki.pm  (revision 3724)
+++ IkiWiki.pm  (working copy)
@@ -842,7 +842,6 @@
                return "";
        }

-       require HTML::Template;
        my @ret=(
                filter => sub {
                        my $text_ref = shift;
@@ -857,6 +856,7 @@
 } #}}}

 sub template ($;@) { #{{{
+       require HTML::Template;
        HTML::Template->new(template_params(@_));
 } #}}}

That gave me:

t/basewiki_brokenlinks.....ok 1/3HTML::Template->new called with multiple (or no) template sources specified!  A valid call to new() has exactly one filename => 'file' OR exactly one scalarref => \$scalar OR exactly one arrayref => \@array OR exactly one filehandle => *FH at blib/lib/IkiWiki.pm line 858

After some step through I figured out that the template directory was invalid, again easily fixed:

Index: t/basewiki_brokenlinks.t
===================================================================
--- t/basewiki_brokenlinks.t    (revision 3724)
+++ t/basewiki_brokenlinks.t    (working copy)
@@ -4,6 +4,6 @@
 use Test::More tests => 3;

 ok(! system("make ikiwiki.out"));
-ok(! system("PERL5LIB=. ./ikiwiki.out -plugin brokenlinks -rebuild -underlaydir=basewiki t/basewiki_brokenlinks t/basewiki_brokenlinks/out"));
+ok(! system("PERL5LIB=. ./ikiwiki.out -plugin brokenlinks -rebuild -underlaydir=basewiki -templatedir=templates t/basewiki_brokenlinks t/basewiki_brokenlinks/out"));
 ok(`grep 'no broken links' t/basewiki_brokenlinks/out/index.html`);
 system("rm -rf t/basewiki_brokenlinks/out t/basewiki_brokenlinks/.ikiwiki");

Other than ikiwiki.in, am I missing something here?

I think this is bug #425891. I have sent there a patch that incorporates the original author's two diffs but has a more correct solution to the first problem described above. -- Thomas, 2007-06-26

done

Posted Fri Jun 29 22:32:52 2007
img plugin should pass through class attribute

I wanted to make images float left or right, so I thought it would be nice to be able to pass a class attribute through the img plugin to the final img tag.

An example of the feature in use can be seen here (notice class="floatleft" and class="floatright"):

    http://www.cworth.org/

And here's a patch to implement it. Will this survive markdown munging? It seems quite unlikely... How does one protect a block like this? Oh well, we'll see what happens.

thanks, done --Joey

-Carl

From 405c29ba2ef97a514bade33ef826e71fe825962b Mon Sep 17 00:00:00 2001
From: Carl Worth <cworth@cworth.org>
Date: Wed, 23 May 2007 15:27:51 +0200
Subject: [PATCH] img plugin: Pass a class attribute through to the final img tag.

This is particularly useful for allowing the image to float.
For example, in my usage I use class=floatleft and then
in the css do .floatleft { float: left; }.
---
 Plugin/img.pm |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/Plugin/img.pm b/Plugin/img.pm
index 7226231..3eb1ae7 100644
--- a/Plugin/img.pm
+++ b/Plugin/img.pm
@@ -93,9 +93,15 @@ sub preprocess (@) { #{{{
                $imgurl="$config{url}/$imglink";
        }

-       return '<a href="'.$fileurl.'"><img src="'.$imgurl.
-               '" alt="'.$alt.'" width="'.$im->Get("width").
-               '" height="'.$im->Get("height").'" /></a>';
+        my $result = '<a href="'.$fileurl.'"><img src="'.$imgurl.
+            '" alt="'.$alt.'" width="'.$im->Get("width").
+            '" height="'.$im->Get("height").'" ';
+        if (exists $params{class}) {
+            $result .= ' class="'.$params{class}.'"';
+        }
+        $result .= '/></a>';
+
+        return $result;
 } #}}}

 1
-- 
1.5.1.gee969
Posted Mon May 28 19:07:22 2007
wiki formatting does not work between toc and an inline

Wiki formatting between [[toc ]] and an inline fails to render. The problem does not seem to trigger if the inline uses the titlepage template, or if it doesn't match any pages. See example below; also reproducible with a single-file wiki containing the text below, rendered via ikiwiki --plugin toc.

This is bug #421843, and I suspect it affects certian other plugins that also use empty divs as placeholders. It's fixed in markdown 1.0.2 b7 (available in debian experimental). So I'll close this as it's not really an ikiwiki bug. --Joey

**not bold** `not fixed-pitch` # heading not rendered [not a link](http://ikiwiki.info)
version 2.2

ikiwiki 2.2 released with these changes

  • Change the aggregate plugin's locking strategy. Now it defers loading state until the wiki is building and already locked, unless it's aggregating. When aggregating, it does not wait for the lock if it cannot get it, and instead exits, to prevent aggregating processes from piling up.
  • Updated Spanish translation from Victor Moral.
  • Correct bug in the img plugin that caused dependencies on images to not always be tracked correctly.
  • Deal better with rebuilds that involve moving files; track and clean up the old files.
  • Change where the img plugin puts scaled images. It's better to make the scaled images subpages of the page that embeds them, rather than putting them alongside the original image, since if two pages scale the same image the same way, this prevents complications in dealing with two pages creating the same file. The move will be handled transparently, though you might want to rebuild your wiki to make it occur in one step.
  • Fix FTBFS in test suite introduced in last version. Closes: #425891
  • Apply a patch from Carl Worth allowing a class attribute to be passed through the img plugin. Also allow the id attribute to be passed through.
  • More consistent encoding of titles in rss and atom feeds. Don't use ESCAPE=HTML for titles in the templates for these feeds, and instead escape the title going in to the template. Previously, the title was sometimes double-escaped in a feed (if set via meta title), and sometimes not (if set from the page filename).
  • In the meta plugin, when a title is set, encode the html entities in it numerically. This works better in the current landscape of a rss spec that doesn't specify encoding, and variously broken feed consumers, according to <http://www.rssboard.org/rss-profile#data-types-characterdata>.
  • Correct some issues with display of unhandled preprocessor directives.
  • Apply a patch from Carl Worth adding support for using globs in link() in a PageSpec.
  • Explode some of the more insane regexps.
  • Add test suite for preprocessor directive parsing.
  • Fix wrapper generator and untaint code's handling of strings contining newlines.
  • Make the url absolution code for feeds significantly more robust.
  • Add typographyattributes configuration setting to typography plugin.
Posted Mon Jun 18 20:29:11 2007

bold

fixed-pitch

heading rendered

a link

Posted Mon May 28 18:09:29 2007

Account-creation password

passwordauth could support an "account creation password", as a simplistic anti-spam measure. (Some wikis edited by a particular group use an account creation password as an "ask an existing member to get an account" system.) --JoshTriplett

done --JoshTriplett

Posted Thu May 24 18:12:25 2007
password deletion

I have just deleted my password, accidentally (which is not a crisis, but it shouldn't really happen).

I logged in to tweak my page subscriptions, did so, and clicked 'save preferences' - unfortunately, the password boxes are cleared when you arrive at the preferences page and if you don't fill them in again then the new password (which is blank) gets saved. I'm sure I'm not the first one to notice this - I'm just writing here because I've not yet found anywhere where this inconvenience is documented.

-- KarlMW

fixed --Joey

Posted Thu May 17 08:05:25 2007
pagestats plugin broken

Since at least version 2.0 (and certainly a few version before), it seems that the pagestats plugin is broken : each matched page has a count of 2. This is also (of course) producing flat tag cloud.

My perl knowledge is very limited, but the call :

my @bl = IkiWiki::backlinks($page);
$counts{$page} = scalar(@bl);

return allways 2, which seems to me "obvious", because the backlinks() function is returning two array of links...

Patch is :

--- /usr/share/perl5/IkiWiki/Plugin/pagestats.pm        2007-04-27 04:33:43.000000000 +0200
+++ ./pagestats.pm      2007-05-12 16:47:14.000000000 +0200
@@ -36,7 +36,7 @@
                if (pagespec_match($page, $params{pages}, location => $params{page})) {
                        use IkiWiki::Render;
                        my @bl = IkiWiki::backlinks($page);
-                       $counts{$page} = scalar(@bl);
+                       $counts{$page} = scalar(@{$bl[0]})+scalar(@{$bl[1]});
                        $max = $counts{$page} if $counts{$page} > $max;
                }
        }

--hb

thanks, done --Joey

Posted Sat May 12 17:56:48 2007
Add a footer div on all pages to improve theming

The following patch adds a footer div on all pages to ease CSS themeing. Indeed, the misc.tmpl, recentchanges.tmpl and editpage.tmpl templates lack such a div.

So, the problem with this is that the default css inserts a horizontal line at the top of the footer div, and putting an empty footer on these other pages looks a bit weird. Any idea how to get around that? --Joey

Sorry I didn't see that. It definitely looks weird. We could add text
in all footers or change the CSS stylesheet, but it's not clean IMHO.

The idea was about to ease themeing by giving all the pages the same structure. The current structure is the following one:

div header - div actions ... div content - div footer (sometimes)

So we could add some new divs in all templates. By default, they will
be empty and no CSS will be defined for them. This way ikiwiki standard appearance is not changed but themeing will be eased. The new page structure could be:

  • div banner (to show up a logo for example)

  • div content-wrap containing div header, div actions, ... div content and div footer

  • div realfooter (to put credits, "Powered by ikiwiki", "Valid XHTML"...)

From my tests, it works: Just adding the divs, without touching the stylesheet, doesn't change ikiwiki appearance. And themeing is eased :-)

I can update the patch, if you want to follow and test this idea. --Fred

Sure, go ahead --Joey

Here is an updated patch against current svn. --Fred

Index: templates/recentchanges.tmpl
===================================================================
--- templates/recentchanges.tmpl        (révision 3575)
+++ templates/recentchanges.tmpl        (copie de travail)
@@ -12,7 +12,11 @@
 </TMPL_IF>
 </head>
 <body>
+<div id="banner">
+</div>

+<div id="content-wrap">
+
 <div class="header">
 <span>
 <TMPL_VAR INDEXLINK>/ <TMPL_VAR TITLE>
@@ -65,5 +69,10 @@

 <!-- from <TMPL_VAR NAME=WIKINAME> -->

+</div>
+
+<div id="realfooter">
+</div>
+
 </body>
 </html>
Index: templates/page.tmpl
===================================================================
--- templates/page.tmpl (révision 3575)
+++ templates/page.tmpl (copie de travail)
@@ -13,7 +13,11 @@
 <TMPL_IF NAME="META"><TMPL_VAR META></TMPL_IF>
 </head>
 <body>
+<div id="banner">
+</div>

+<div id="content-wrap">
+
 <div class="header">
 <span>
 <TMPL_LOOP NAME="PARENTLINKS">
@@ -95,5 +99,10 @@
 <TMPL_IF EXTRAFOOTER><TMPL_VAR EXTRAFOOTER></TMPL_IF>
 </div>

+</div>
+
+<div id="realfooter">
+</div>
+
 </body>
 </html>
Index: templates/editpage.tmpl
===================================================================
--- templates/editpage.tmpl     (révision 3575)
+++ templates/editpage.tmpl     (copie de travail)
@@ -12,6 +12,11 @@
 </TMPL_IF>
 </head>
 <body>
+<div id="banner">
+</div>
+
+<div id="content-wrap">
+
 <TMPL_IF NAME="PAGE_CONFLICT">
 <p>
 <b>Your changes conflict with other changes made to the page.</b>
@@ -86,5 +91,11 @@
 <TMPL_VAR PAGE_PREVIEW>
 </div>
 </TMPL_IF>
+
+</div>
+
+<div id="realfooter">
+</div>
+
 </body>
 </html>
Index: templates/misc.tmpl
===================================================================
--- templates/misc.tmpl (révision 3575)
+++ templates/misc.tmpl (copie de travail)
@@ -12,7 +12,11 @@
 </TMPL_IF>
 </head>
 <body>
+<div id="banner">
+</div>

+<div id="content-wrap">
+
 <div class="header">
 <span>
 <TMPL_VAR INDEXLINK>/ <TMPL_VAR TITLE>
@@ -23,5 +27,10 @@
 <TMPL_VAR PAGEBODY>
 </div>

+</div>
+
+<div id="realfooter">
+</div>
+
 </body>
 </html>

I took a more intrusive approach to avoid ugly names like "realfooter". done --Joey

Posted Fri May 11 20:09:46 2007
find: invalid predicate `-L'

Hi,

I have a problem with building ikiwiki 2.00 backport for Debian sarge, because it seems that my find doesn't support -L option. I had to patch Makefile.PL file to work around it:

--- Makefile.PL-orig        2007-05-10 15:18:04.000000000 +0200
+++ Makefile.PL     2007-05-10 15:18:41.000000000 +0200
@@ -47,9 +47,9 @@

 extra_install:
    install -d $(DESTDIR)$(PREFIX)/share/ikiwiki
-   for dir in `find -L basewiki templates -type d ! -regex '.*\.svn.*'`; do \
+   for dir in `find basewiki templates -follow -type d ! -regex '.*\.svn.*'`; do \     
            install -d $(DESTDIR)$(PREFIX)/share/ikiwiki/$$dir; \
-           for file in `find -L $$dir -maxdepth 1 -type f`; do \
+           for file in `find $$dir -follow -maxdepth 1 -type f`; do \
                    install -m 644 $$file $(DESTDIR)$(PREFIX)/share/ikiwiki/$$dir; \
            done; \
    done

-- Pawel

applied, thanks --Joey

Thank you! :) --Pawel

Posted Fri May 11 20:09:20 2007
login page non-obvious with openid

I just setup my first OpenID account and tried to login to ikiwiki.info. It all works but being relatively unfamiliar with OpenID, when I was presented with the login page it wasn't at all clear which bits needed to be filled in.

At the moment it looks like this:

Name:
Password:   
OpenID:

[Login] [Register] [Mail Password]

Really this form is presenting two entirely separate ways to login. The "normal" user/pass OR OpenID. Also (I assume) the [Register] and [Mail Password] actions are only relevant to user/pass form.

I would suggest that the form be split into two parts, something like this:

Login (or register) with a username and password:

Name:
Password:   

[Login] [Register] [Mail Password]

**OR**

Login with OpenID:

OpenID URL:

[Login]

As an example, the first time I went to login I filled in all three fields (user, pass, openid) and then clicked [Register] because from the layout I assumed I still had to instantiate an account with ikiwiki ... and to make it even more confusing, it worked! Of course it worked by creating me an account based on the username password and ignoring the OpenID URL.

If you want to keep it as one form, then perhaps using some javascript to disable the other pieces of the form as soon as you fill in one part would help? Eg. If you put in an OpenID URL then Name/Password/Register/Mail Password gets greyed out. If you enter a username then the OpenID URL gets greyed out. -- Adam.

It's one form for architectural reasons -- the OpenID plugin uses a hook that allows modifying that form, but does not allow creating a separate form. The best way to make it obvious how to use it currently is to just disable password auth, then it's nice and simple. :-) Javascript is an interesting idea. It's also possible to write a custom [[signin.tmpl wikitemplates]] that is displayed instead of the regular signin form, and it should be possible to use that to manually lay it out better than FormBuilder manages with its automatic layout. --Joey

I've improved the form, I think it's more obvious now that the openid stuff is separate. Good enough to call this done. I think. --Joey

Looks good, thanks! :-) -- AdamShand

Posted Tue May 8 17:51:49 2007
clearing email in prefs

If a user has an email address in their prefs, and they try to clear it, the prefs seem to save ok, and the email seems to be gone, but reloading the prefs page will reveal the old email address.

Also affected subscriptions.. done

Posted Mon Apr 30 22:03:35 2007