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 Sat Feb 10 15:27:11 2007Thanks, done --Joey
The RSS feeds on a page should be indicated with <link rel>, so that they can be found by aggregators.
--tumov
I've been wondering about this. Ikiwiki's rss buttons include a type="application/rss+xml" and link to the rss file, and this is enough for at least some auto-discovery tools to find the rss feed. But apparently not all of them.
For example, firefox requires the following:
<link rel="alternate" type="application/rss+xml" title="RSS" href="index.rss" />
done
--Joey
Posted Sat Feb 10 15:27:11 2007- page name substring search
- full text (use third-party tools?)
- hyperestraier looks nice
done
Posted Sat Feb 10 15:27:11 2007Might 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 Sat Feb 10 15:27:11 2007An idea: Use graphviz to generate a map of all the links between pages. (Could it be made clickable somehow?)
Graphviz can output image maps. -- ChristofferSawicki
done
Posted Sat Feb 10 15:27:11 2007Rather than copy the basewiki around everywhere, it should be configured to underlay the main srcdir, and pages be rendered from there if not in the srcdir. This would allow upgrades to add/edit pages in the basewiki.
Implementaion will be slightly tricky since currently ikiwiki is hardcoded in many places to look in srcdir for pages. Also, there are possible security attacks in the vein of providing a file ikiwiki would normally skip in the srcdir, and tricking it to processing this file instead of the one from the underlaydir. -- Fixed by scanning srcdir first, then underlaydir, and refusing to add any files from underlaydir if they also exist in the srcdir. However, see security for caveats.
done
Posted Sat Feb 10 15:27:11 2007Doctype is XHTML 1.0 Strict
One consideration of course is that regular users might embed html that uses deprecated presentational elements like <center>. At least firefox seems to handle that mixture ok. --Joey
[ [inlinepage] ] gets wrapped in <p>...</p> which has a high chance of invalidating the page.
Since markdown does this, the only way I can think to fix it is to make the inlined page text start with </p> and end with <p>. Ugly, and of course there could be problems with markdown enclosing it in other spanning tags in some cases. I've implemented this hack now. :-/ --Joey
I used this 'hack' myself, but yesterday I came up with a better idea:
<div class="inlinepage">
[ [inlinepage] ]
</div>
This prevents markdown enclosing and even adds a useful css identifier. Problem is that this should be added to every page and not in the template(s). --?JeroenSchotI can make ikiwiki add that around every inlined page easily enough. However, where is it documented? Came up dry on google. --Joey
From http://daringfireball.net/projects/markdown/syntax#html:
The only restrictions are that block-level HTML elements e.g. <div>, <table>, <pre>, <p>, etc. must be separated from surrounding content by blank lines, and the start and end tags of the block should not be indented with tabs or spaces. Markdown is smart enough not to add extra (unwanted) <p> tags around HTML block-level tags. [snip] Note that Markdown formatting syntax is not processed within block-level HTML tags. E.g., you can't use Markdown-style *emphasis* inside an HTML block.
Because [ [inlinepage] ] isn't separated by a blank line it gets treated as a block-level element. Hmm, will this stop all formatting, including *'s to em-tags? --?JeroenSchot
Ah didn't realize you meant it fixed it at the markdown level. I'll think about making postprocessordirectives into preprocessordirectives instead, then I could use that fix (but I'm not sure how feasible it is to do that). --Joey
Done.. inlining is now a preprocessor directive, happens before markdown, and the inlinepage template uses div as suggested, this does prevent markdown from doing any annoying escaping of the preprocessor directives, as well as preventing it wrapping subpages in <p>. --Joey
This page is now valid. Test: validate this page
done
Posted Sat Feb 10 15:27:11 2007It seems that pages like Todo aren't rebuilt automatically when a new item is added using the web interface.
AFAIK this is working ok. For example, this page appears in TODO. Maybe you need to force-refresh the page in your web browser? --Joey
done
Posted Sat Feb 10 15:27:11 2007- ?John is a Wikipedia method for linking to the one page while displaying it as the other, Kyle would like this.
done
Posted Sat Feb 10 15:27:11 2007Should support mail notification of new and changed pages.
Hmm, should be easy to implement this.. it runs as a svn post-coommit hook already, so just look at the userdb, svnlook at what's changed, and send mails to people who have subscribed.
A few details: 1. Joey mentioned that being able to subscribe to globs as well as explicitly named pages would be desirable. 2. I think that since we're using Perl on the backend, being able to let users craft their own arbitrary regexes would be good.
Joey points out that this is actually a security hole, because Perl
regexes let you embed (arbitrary?) Perl expressions inside them. Yuck!
(This is not actually true unless you "use re 'eval';", without which (?{ code }) is disabled for expressions which interpolate variables. See perldoc re, second paragraph of DESCRIPTION. It's a little iffy to allow arbitrary regexen, since it's fairly easy to craft a regular expression that takes unbounded time to run, but this can be avoided with the use of alarm to add a time limit. Something like
eval { # catches invalid regexen
no re 'eval'; # to be sure
local $SIG{ALRM} = sub { die };
alarm(1);
... stuff involving m/$some_random_variable/ ...
alarm(0);
};
if ($@) { ... handle the error ... }
should be safe. --?WillThompson)
It would also be good to be able to subscribe to all pages except discussion pages or the SandBox: `* !*/discussion !sandobx`, maybe --<a href="../joey.html">Joey</a>
Of course if you do that, you want to have form processing on the user page that lets them tune it, and probably choose literal or glob by default.
I think that the new globlist() function should do everything you need. Adding a field to the prefs page will be trivial --Joey
The first cut, I suppose, could use one sendmail process to batch-mail all subscribers for a given page. However, in the long run, I can see users demanding a bit of feature creep:
Each user should be able to tune whether they see the actual diff parts or not.
- Each user should be able to set a maximum desired email size.
We might want to support a user-specified shibboleth string that will be included in the email they receive so they can easily procmail the messages into a folder.
--?BrandenRobinson
I'm deferring these nicities until there's some demonstrated demand --Joey.
done
Posted Sat Feb 10 15:27:11 2007