recently fixed TODO items
There could be a better way of setting the title and description of the rss feeds. Perhaps through the meta plugin, or extra options to the inline plugin.
At the moment The description is the same for all feeds from a single wiki it seems, and the title is forced to be one word, though I don't think it needs to be.
A few pointers and I might be able to implement this myself. -- JamesWestby
I don't see any problem with the title, it's the same as the title of the wiki page that the rss feed comes from, which can be set using the meta plugin. There are no restrictions to one word or anything like that. Just made ikiwiki emit the following in a test feed:
billy bob's news
Now, the description field currently defaults to the wiki name, and that could indeed stand to be made configurable. Since the current (svn) version of ikiwiki supports long, word-wrapped blocks of text as parameters to PreProcessorDirectives, seems to me the best way would be to simple modify inline.pm to make the descripion configurable by such parameter, with a fallback to the wiki name. You'll need to modify rsspage.tmpl to use whatever new template variable you define, that should be all.
--Joey
Apologies for the title thing. I tried it yesterday, and it onlt used the first word. I must have done something wrong. I'll have a look at implementing the description. Thanks. -- JamesWestby
My patch can be found at http://jameswestby.net/scratch/blog-desc.diff -- JamesWestby
Posted Sun Aug 30 21:49:15 2009Thanks, done --Joey
(I've written a proposal for this feature --Ben).
Support for uploading files is useful for many circumstances:
- Uploading images.
- Uploading local.css files (admin only).
- Uploading mp3s for podcasts.
- Etc.
ikiwiki should have an easy to use interface for this, but the real meat of the work is in securing it. Several classes of controls seem appropriate:
- Limits to size of files that can be uploaded. Prevent someone spamming the wiki with CD isos..
Limits to the type of files that can be uploaded. To prevent uploads of virii, css, raw html etc, and avoid file types that are not safe. Should default to excluding all files types, or at least all except a very limited set, and should be able to open it up to more types.
Would checking for file extensions (.gif, .jpg) etc be enough? Some browsers are probably too smart for their own good and may ignore the extension / mime info and process as the actual detected file type. It may be necessary to use
file
to determine a file's true type.- Optional ability to test a file using a virus scanner like clamav.
- Limits to who can upload what type of files.
- Limits to what files can be uploaded where.
It seems that for max flexability, rules should be configurable by the admin to combine these limits in different ways. If we again extend the pagespec for this, as was done for conditional text based on ikiwiki features, the rules might look something like this:
( maxsize(30kb) and type(webimage) ) or
( user(joey) and maxsize(1mb) and (type(webimage) or *.mp3) ) or
( user(joey) and maxsize(200mb) and (*.mov or *.avi) and videos/*)
With a small extension, this could even be used to limit the max sizes of normal wiki pages, which could be useful if someone was abusing an open wiki as a wikifs. Maybe.
( type(page) and maxsize(32k) )
And if that's done, it can also be used to lock users from editing a pages or the whole wiki:
!(( user(spammer) and * ) or
( user(42.12.*) and * ) or
( user(http://evilopenidserver/*) and * ) or
( user(annoying) and index) or
( immutable_page ))
That would obsolete the current simple admin prefs for banned users and locked pages. Suddenly all the access controls live in one place. Wonderbar!
(Note that pagespec_match will now return an object that stringifies to a message indicating why the pagespec matched, or failed to match, so if a pagespec lock like the above prevents an edit or upload from happening, ikiwiki could display a reasonable message to the user, indicating what they've done wrong.)
Posted Sun Aug 30 21:49:15 2009Index: IkiWiki/Rcs/git.pm
===================================================================
--- IkiWiki/Rcs/git.pm (revision 4532)
+++ IkiWiki/Rcs/git.pm (working copy)
@@ -275,6 +275,9 @@
my $file = shift || q{--};
+ # Remove srcdir prefix to appease git-rev-list
+ $file =~ s/^$config{srcdir}\/?//;
+
# Ignore error since a non-existing file might be given.
my ($sha1) = run_or_non('git-rev-list', '--max-count=1', 'HEAD', $file);
if ($sha1) {
I actually see a bug in this patch. If srcdir = "foo" and the wiki
contains a "foo/bar" and a "bar", this will make it, in the non-ctime case,
get the sha1 of the wrong file, "bar", when "foo/bar" is asked for.
Better to strip the path out in getctime, I guess.
--Joey
Posted Sun Aug 30 21:49:15 2009Add an option to use the Showdown GUI for editing or adding content. It is BSD-licensed javascript that shows the rendered Markdown (or HTML) while editing.
A demo is at http://www.attacklab.net/showdown-gui.html
(I read about this on the markdown mailing list.)
Posted Sun Aug 30 21:49:15 2009Wikiwyg also can provide a nice GUI for editing, although it would need to be expanded to support markdown. The benefit compared to showdown is that it provides a GUI for editing with widets for italics, etc, compared to showdown which still leaves input in markdown and seems more geared to a fast preview of the html. --Joey
Since we have semi-working wikiwgy and it's better, I'm considering this todo item as done or rather, will-not-be-done..
Given the unfortunate state of affairs for the wikiwyg project, could it be worthwhile to consider this option again? It seems to have a companion product (wmd) with formatting widgets and a live preview pane, that is promised to be MIT licensed as of the next release.... --Chapman Flack
Might be nice to support automatically generating an index based on headers in a page, for long pages. This could be done as a sanitize hook that parsed the html, with a preprocessordirective that controlled it.
done
Posted Sun Aug 30 21:49:15 2009I am serving notice that I am starting work on a calendar plugin inspired by Blosxom's calendar plugin. The current plan is to create a plugin that looks through all the source files matching a certain pagespec, and optionally spit out a month view for the specified month (default to current), or spit out a year view for a given year (defaulting to the current year), of a list of year with posts in them. The output would be a table, with the same CSS directives that the Blosxom plugin used to use (so that I can just reuse my css file). The links would be created to a $config{archivedir}/$year or $config{archivedir}/$year-$month file, which can just have
[[inline pages="blog/* and !*/Discussion and creation_year($year) and creation_month($month)" rss="no" atom="no" show="0"]]
or some thing to generate a archive of postings.
Roland Mas suggested a separate cron job to generate these archive indices automatically, but that is another thread.
ManojSrivastava
This plugin is inspired by the calendar plugin for Blosxom, but derivesno code from it. This plugin is essentially a fancy front end to archives of previous pages, usually used for blogs. It can produce a calendar for a given month, or a list of months for a given year. To invoke the calendar, just use the preprocessor directive:
[[calendar ]]
or
[[calendar type="month" pages="blog/* and !*/Discussion"]]
or
[[calendar type="year" year="2005" pages="blog/* and !*/Discussion"]]
The year and month entities in the out put have links to archive index pages, which are supposed to exist already. The idea is to create an archives hierarchy, rooted in the subdirectory specified in the site-wide customization variable, archivebase. archivebase defaults to "archives". Links are created to pages "$archivebase/$year" and "$archivebase/$year/$month". The idea is to create annual and monthly indices, for example, by using something like this sample from my archives/2006/01.mdwn
[[meta title="Archives for 2006/01"]]
[[inline rootpage="blog" atom="no" rss="no" show="0" pages="blog/* and !*/Discussion and creation_year(2006) and creation_month(01)" ]]
I'll send in the patch via email.
ManojSrivastava
Since this is a little bit er, stalled, I'll post here the stuff Manoj mailed me, and my response to it. --Joey
I'm sending in an updated package, and have removed the older version you had here.--ManojSrivastava
've been looking over the calendar plugin. Some items:
- Why did you need to use a two-stage generation with a format hook? That approach should only be needed if adding something to a page that would be removed by the htmlscrubber, and as far as I can tell, the calendars don't involve anything that would be a problem. It seems that emitting the whole calendar in the preprocess hook would simplify things and you'd not need to save state about calendars.
I am scared of the html scrubber, and have never turned it on, and did not look too deeply into what would be scrubbed out --ManojSrivastava
Unless you're using javascript, a few annoyances link , or inline css, it's unlikly to object to any html you might write. The list of allowed tags and attributes is easy to find near the top of the plugin.
In case the option that gets the ctime of the pages from the SCM itself, %IkiWiki::pagectime is not populated that early, is it? So I waited until the last possible moment to look at the time information.
Actually, since my big rewrite of the rendering path a few months ago, ikiwiki scans and populates almost all page information before starting to render any page. This includes %pagectime, and even %links. So you shouldn't need to worry about running it late.
- The way that it defaults to the current year and current month is a little bit tricky, because of course the wiki might not get updated in a particular time period, and even if it is updated, only iff a page containing a calendar is rebuilt for some other reason will the calendar get updated, and change what year or month it shows. This is essentially the same problem described in tagging with a publication date, although I don't think it will affect the calendar plugin very badly. Still, the docs probably need to be clear about this.
I use it on the sidebar; and the blog pages are almost always rebuilt, which is where the calendar is looked at most often. Oh, and I also cheat, I have ikiwiki --setup foo as a @daily cronjob, so my wiki is always built daily from scratch.
I think it should be mentioned, yes.
- There seems to be something a bit wrong with the year-to-year
navigation in the calendar, based on the example in your blog. If I'm
on the page for 2006, there's an arrow pointing left which takes me to
- If I'm on 2005, the arrow points left, but goes to 2006, not 2004.
I need to look into this.
- AIUI, the archivebase setting makes a directory rooted at the top of the wiki, so you can have only one set of archives per wiki, in /archives/. It would be good if it were possible to have multiple archived for different blogs in the same wiki at multiple locations. Though since the archives contain calendars, the archive location can't just be relative to the page with the calendar. But perhaps archivebase could be a configurable parameter that can be specified in the directive for the calendar? (It would be fine to keep the global location as a default.)
OK, this is simple enough to implement. I'll do that (well, perhaps not before Xmas, I have a family dinner to cook) and send in another patch.
And that's all I've heard so far. Hoping I didn't miss another patch?
--Joey
No, you did not. But I am back to hacking on this, and I think I have discovered a major problem with my approach. One of the problems with the current plugin is that the goal of a calendar is to create a calendar, either a month >or year based on, that provides links to blogs for all the days in (for the month calendar), and all the months (in a year calendar) in which there have been blog postings. For the monthly calendar, it needs to know the previous >and next months where there is a posting, and for the year calendar, it needs to know which of the previous (next) years had entries.
Now, this means that it needs to know about at all pages that meet the pagespec, and stash that information, before it begins generating the calandar in question, in order to calculate how to create the symlinks. And, of >course, all pages that have calendars on them might need to change anytime a page that meets the pagespec is added; and again at midnight, when the current day changes.
I think I have solved the ""Need to look at all pages that match the spec"" issue; but the nightly rebuild to handle the current day changing still remain. I use cron. It is now, however, richly documented
--ManojSrivastava
Posted Sun Aug 30 21:49:15 2009Finally reviewed and applied this. done! --Joey
The bzr plug echoes "added: somefile.mdwn" when it adds somefile.mdwn to the repository. As a result, the redirect performed after a new article is created fails because the bzr output comes before the HTTP headers.
The fix is simply to call bzr
with the --quiet switch. Something like this applied to bzr.pm works for me:
46c46
< my @cmdline = ("bzr", $config{srcdir}, "update");
---
> my @cmdline = ("bzr", "update", "--quiet", $config{srcdir});
74c74
< my @cmdline = ("bzr", "commit", "-m", $message, "--author", $user,
---
> my @cmdline = ("bzr", "commit", "--quiet", "-m", $message, "--author", $user,
86c86
< my @cmdline = ("bzr", "add", "$config{srcdir}/$file");
---
> my @cmdline = ("bzr", "add", "--quiet", "$config{srcdir}/$file");
94a95,97
> eval q{use CGI 'escapeHTML'};
> error($@) if $@;
>
Posted Sun Aug 30 21:49:15 2009done, although I left off the escapeHTML thing which seems to be in your patch by accident.
(Please use diff -u BTW..) --Joey
Turning the wikilink regexp into an extended regexp on the svn trunk seems
to have broken the setuid wrapper on my system, because of two reasons:
First, the wrapper generator should turn each newline in $configstring into
\n
in the C code rather than \
followed by a newline in the C code.
Second, the untainting of $configstring should allow newlines.
Both of these problems were already dealt with in commit r3714, on June 3rd. Confused why you're posting patches for them now. done --Joey
Modified: wiki-meta/perl/IkiWiki.pm
==============================================================================
--- wiki-meta/perl/IkiWiki.pm (original)
+++ wiki-meta/perl/IkiWiki.pm Mon Jun 11 10:52:07 2007
@@ -205,7 +205,7 @@
sub possibly_foolish_untaint ($) { #{{{
my $tainted=shift;
- my ($untainted)=$tainted=~/(.*)/;
+ my ($untainted)=$tainted=~/(.*)/s;
return $untainted;
} #}}}
Modified: wiki-meta/perl/IkiWiki/Wrapper.pm
==============================================================================
--- wiki-meta/perl/IkiWiki/Wrapper.pm (original)
+++ wiki-meta/perl/IkiWiki/Wrapper.pm Mon Jun 11 10:52:07 2007
@@ -62,7 +62,7 @@
}
$configstring=~s/\\/\\\\/g;
$configstring=~s/"/\\"/g;
- $configstring=~s/\n/\\\n/g;
+ $configstring=~s/\n/\\n/g;
#translators: The first parameter is a filename, and the second is
#translators: a (probably not translated) error message.
Posted Sun Aug 30 21:49:15 2009
How about a skip option for inline? This would allow things like the following:
[[inline pages="news/*" show="5"]]
[[inline pages="news/*" skip="5" show="5" archive="yes"]]
I just wrote a patch. --Ethan
done --Joey
Posted Sun Aug 30 21:49:15 2009shortcut creates link shortcut PreprocessorDirectives,
which substitute their argument into the specified shortcut URL to generate
the link target, and use the argument as the link text. For example, given
the example shortcuts, [[wikipedia ikiwiki]]
generates a link to
http://en.wikipedia.org/wiki/ikiwiki, with the link text "ikiwiki". This
works well in many cases; however, for things like the debbug
example, it
simply uses the number as the link text, which does not always provide
enough context to understand the link at first glance. For example,
[[debbug 397501]]
generates a link to http://bugs.debian.org/397501,
with just "397501" as the link text. While template provides a
general solution for arbitrary cases, it would help to have a simple option
via the shortcut plugin to set the link text, with a %s
substitution.
Thus, something like [[shortcut name=debbug
url="http://bugs.debian.org/%s" desc="bug #%s"]]
might suffice on a
Debian-specific wiki to indicate a bug number, while a more general wiki
might use something like [[shortcut name=debbug
url="http://bugs.debian.org/%s" desc="Debian bug #%s"]]
.
Posted Sun Aug 30 21:49:15 2009done --Joey