Adding "overflow: visible;" (or removing "overflow: auto" from style.css) makes the sidebar appear above (as in printed over the top of, not higher up the page) the recentchanges (similar to the third screen shot above). Unfortunately because ".recentchanges .pagelinks" uses "float: right;" it looks strange in other ways. For this reason I use the "clear:both;" as well.
-- [[users/Will]]
+
+>> Looks like [[Joey]] has added `clear:both;` to style.css, so this is [[bugs/done]]. -- [[Will]]
> Well, it's been done by Josh, but I do wonder if there wasn't value to
> being able to look at the top of the page for new plugins? --[[Joey]]
+
+>> I agree, which is why I brought it up here rather than just changing it.
+>> On balance I think the alphabetical list is better. You could have a
+>> "recently changed" list with the 10 most recently changed plugins
+>> at the top. That would allow what you suggested, but still allow
+>> the main list to be alphabetical. -- [[Will]]
> I sorta take your point about bug numbers. It can be a pain to refer to
> 'using_a_wiki_for_issue_tracking' as a bug name in a place like a
> changelog.
->
+
+>> Would a modified [[plugins/inline]] plugin that allowed new pages, but without a title field, be ok?
+>> When you hit the edit button it just chooses a new number and makes a page with that
+>> name.
+
+>> The only issue I can see with this is if you're using a distributed wiki for
+>> distributed bug tracking. In that case you're going to have to make sure that you
+>> don't get conflicting bug ids.
+>> Maybe there should be two options - consecutive numbering, and uuid numbering
+>> which uses a random (128 bit, base64 encoded = 22 chars) name. -- [[Will]]
+
> OTOH, I don't see a need for specially formatted commit messages to be
> used to close bugs. Instead, if your BTS is kept in an ikiwiki wiki in
> an RCS along with your project, you can do like I do here, and just edit a
>> Mh.. well. I know this problem, too. I leave the Discussion sites open for no registrations, so that visitors can easily write a comment to this specific blog entry without the need for registration. (This would be the same behaviour, as many blogging engines are using). Maybe it is possible to wrote a plugin that would scan the text which is submitted via spamassassin or something similar. (Using this combined with known spam URLs would maybe reduce the load of the server if there are many webpages which are getting editted by someone). If you like this idea Joey I might be interested to write such a plugin after my exams this and the next month. :) -- [[Winnie]]
You might look at the Wikipedia page on "Spam\_in\_blogs" for more ideas. In particular, would it be possible to force a subset of the pages (by regex, but you'd choose the regex to match those pages which are publicly writable) to use rel="nofollow" in all links.
+
+> I just wanted to leave a link here to the [[todo/require_CAPTCHA_to_edit]] plugin patch. Unfortunately that plugin currently interacts badly with the openid plugin. -- [[Will]]
> One question, why the 2px padding for span.color? --[[Joey]]
+>> Sorry for a long silence, but I had Internet free summer holiday :)
+>> I did that, because backgrounded text without any padding seems
+>> strange for me ;) You can remove it if you don't like that padding.
+>> --[[Paweł|ptecza]]
+
--- /dev/null 2008-06-21 02:02:15.000000000 +0200
+++ color.pm 2008-07-27 14:58:12.000000000 +0200
@@ -0,0 +1,69 @@
padding around done strip.
Any comments? --[[Paweł|ptecza]]
+
+> This looks like a nice idea. If I could add one further suggestion: Allow your
+> ratio to be a pair of pagespecs. Then you could have something like:
+
+ \[[!progress totalpages="bugs/* and backlink(milestoneB)" donepages="bugs/* and backlink(milestoneB) and !link(bugs/done)"]]
+
+> to have a progress bar marking how many bugs were compete for a
+> particular milestone. -- [[Will]]
+
+>> Thanks a lot for your comment, Will! It seems very interesting for me.
+>> I need to think more about improving that plugin. --[[Paweł|ptecza]]
+
+>> Attached is a [[patch]] (well, source) for this. You also need to add the proposed CSS above to `style.css`.
+>> At the moment this plugin interacts poorly with the [[plugins/htmlscrubber]] plugin.
+>> HTMLScrubber plugin removes the `style` attribute from the `progress-done` `div` tag, and so it defaults
+>> to a width of 100%. -- [[Will]]
+
+>>> Thank you for the code! I know how to fix that problem, because I had
+>>> the same issue while writing [[todo/color_plugin]] :) --[[Paweł|ptecza]]
+
+ #!/usr/bin/perl
+ package IkiWiki::Plugin::progress;
+
+ use warnings;
+ use strict;
+ use IkiWiki 2.00;
+
+ my $percentage_pattern = qr/[0-9]+\%/; # pattern to validate percentages
+
+ sub import { #{{{
+ hook(type => "getsetup", id => "progress", call => \&getsetup);
+ hook(type => "preprocess", id => "progress", call => \&preprocess);
+ } # }}}
+
+ sub getsetup () { #{{{
+ return
+ plugin => {
+ safe => 1,
+ rebuild => undef,
+ },
+ } #}}}
+
+ sub preprocess (@) { #{{{
+ my %params=@_;
+
+ my $fill;
+
+ if (defined $params{percent}) {
+ $fill = $params{percent};
+ ($fill) = $fill =~ m/($percentage_pattern)/; # fill is untainted now
+ }
+ elsif (defined $params{totalpages} and defined $params{donepages}) {
+ add_depends($params{page}, $params{totalpages});
+ add_depends($params{page}, $params{donepages});
+
+ my @pages=keys %pagesources;
+ my $totalcount=0;
+ my $donecount=0;
+ foreach my $page (@pages) {
+ $totalcount++ if pagespec_match($page, $params{totalpages}, location => $params{page});
+ $donecount++ if pagespec_match($page, $params{donepages}, location => $params{page});
+ }
+
+ if ($totalcount == 0) {
+ $fill = "100%";
+ } else {
+ my $number = $donecount/$totalcount*100;
+ $fill = sprintf("%u%%", $number);
+ }
+ }
+ else {
+ error("Missing parameters to progress plugin. Need either `percent` or `totalpages` and `donepages` parameters.");
+ }
+
+ return <<EODIV
+ <div class="progress">
+ <div class="progress-done" style="width: $fill">$fill</div>
+ </div>
+ EODIV
+
+ } # }}}
+
+ 1
I started using Ikiwiki as a way to replace [Trac](http://trac.edgewall.org/) when using [Monotone](http://monotone.ca/). Version control has been an interest of mine for a while and I wrote most of the ikiwiki [[rcs/monotone]] plugin.
-Lately I've been using Ikiwiki for other things and seem to scratching a few itches here and there. :)
+Lately I've been using Ikiwiki for other things and seem to be scratching a few itches here and there. :)
I generally use my [[ikiwiki/openid]] login when editing here: <http://www.cse.unsw.edu.au/~willu/>
### Open ToDos:
-[[!inline pages="link(users/Will) and todo/* and !todo/done and !todo/discussion and !link(patch) and !link(bugs/done) and !bugs/*/*" archive="yes" feeds="no" ]]
+[[!inline pages="link(users/Will) and todo/* and !todo/done and !todo/discussion and !link(patch) and !link(todo/done) and !bugs/*/*" archive="yes" feeds="no" ]]
### Unapplied Patches:
-[[!inline pages="link(users/Will) and (todo/* or bugs/*) and !bugs/done and !bugs/discussion and !todo/done and !todo/discussion and link(patch) and !link(bugs/done) and !bugs/*/*" archive="yes" feeds="no" ]]
+[[!inline pages="link(users/Will) and (todo/* or bugs/*) and !bugs/done and !bugs/discussion and !todo/done and !todo/discussion and link(patch) and !link(bugs/done) and !link(todo/done) and !bugs/*/*" archive="yes" feeds="no" ]]