pages that link to my home page in the wiki"
- Locking any pages that are linked to from a particular page, so that
lists of locks can be exposed in the wiki.
+ * Reorganised the doc wiki's todo/* pages, using a [[done]] tag to flag
+ when a todo item is done, instead of the previous moving it to a different
+ subdir.
- -- Joey Hess <joeyh@debian.org> Thu, 1 Jun 2006 20:56:58 -0400
+ -- Joey Hess <joeyh@debian.org> Thu, 1 Jun 2006 21:30:03 -0400
ikiwiki (1.4) unstable; urgency=low
`svn://svn.kitenet.net/ikiwiki/trunk`
The source in subversion can be browsed [with viewcvs](http://svn.kitenet.net/trunk/?root=ikiwiki).
+
+If you would like to be subscribed to svn commit messages for ikiwiki,
+mail joey@kitenet.net.
-Welcome to ikiwiki's todo list. Items are moved to [[todo/done]] when done.
+Welcome to ikiwiki's todo list. Link items to [[todo/done]] when done.
-[[inline pages="todo/* !todo/done* !*/Discussion" rootpage="todo" show="30"]]
+[[inline pages="todo/* !todo/done !link(done) !*/Discussion" rootpage="todo" show="30"]]
----
# Full list of open items:
-[[inline pages="todo/* !todo/done* !*/Discussion" archive="yes"]]
+[[inline pages="todo/* !todo/done !link(done) !*/Discussion" archive="yes"]]
--- /dev/null
+The following need to be resolved before ikiwiki 1.0 can be released:
+
+* HTML XSS [[security]] issues. Do I need to find or write a html sanitiser and bolt it onto the wiki, or can this stupid issue be ignored? It's really the browser's fault, and sanitising out html that is exploitable in all the buggy browsers out there is a neverending treadmill.
+
+That's all!
+
+[[done]]
--- /dev/null
+It 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]]
--- /dev/null
+ikiwiki needs to support blogging. Make subpages of a page turn into a blog
+with a special post-processor rune.
+
+[[done]]
recently fixed [[TODO]] items
-[[inline pages="todo/done/* !*/Discussion" show="10"]]
+[[inline pages="todo/* link(done) !*/Discussion" show="10"]]
+++ /dev/null
-The following need to be resolved before ikiwiki 1.0 can be released:
-
-* HTML XSS [[security]] issues. Do I need to find or write a html sanitiser and bolt it onto the wiki, or can this stupid issue be ignored? It's really the browser's fault, and sanitising out html that is exploitable in all the buggy browsers out there is a neverending treadmill.
-
-That's all!
\ No newline at end of file
+++ /dev/null
-It 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]]
\ No newline at end of file
+++ /dev/null
-ikiwiki needs to support blogging. Make subpages of a page turn into a blog
-with a special post-processor rune.
+++ /dev/null
-# html validation
-
- * A doctype: XHTML 1.0 strict.
- * <hr> to <hr /> etc.
- * Image wikilinks provide an alt text.
- * &'s in (cgi-)url's escaped as &amp;.
+++ /dev/null
- * Doctype 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). --[[JeroenSchot]]
-
- I 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
- [[preprocessordirective]]s 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](http://validator.w3.org/check?url=referer)
+++ /dev/null
-ikiwiki needs a logo. I'm thinking something simple like the word "ikiwiki"
-with the first "k" backwards; drawn to show that it's "wiki" reflected.
-
+++ /dev/null
-Should 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 --[[Joey]]
-
- 3. 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:
-
- 4. Each user should be able to tune whether they see the actual diff parts or
- not.
- 5. Each user should be able to set a maximum desired email size.
- 6. 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]].
+++ /dev/null
-* page name substring search
-* full text (use third-party tools?)
- - hyperestraier looks nice
-
+++ /dev/null
-There should be a --strftime switch that controls how all the dates are
-formatted.
+++ /dev/null
-Rather 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.
+++ /dev/null
-It's annoying to have to manually run --setup, especially for multiple
-blogs, on upgrade. Is the deb is used, there could be a postinst hook to do
-this.
-
-Let there be an /etc/ikiwiki/wikis, which just lists setup files and the
-user who owns them. postinst loops through, su's, and runs --setup. Voila!
+++ /dev/null
-ikiwiki should support utf-8 pages, both input and output. To test, here's a
-utf-8 smiley:
-
-# ☺
-
-Currently ikiwiki is belived to be utf-8 clean itself; it tells perl to use
-binmode when reading possibly binary files (such as images) and it uses
-utf-8 compatable regexps etc.
-
-Notes:
-
-* Apache "AddDefaultCharset on" settings will not play well with utf-8
- pages. Turn it off.
+++ /dev/null
-- \[[John|Fred]] is a Wikipedia method for linking to the one page
- while displaying it as the other, Kyle would like this.
-
--- /dev/null
+ * Doctype 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). --[[JeroenSchot]]
+
+ I 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
+ [[preprocessordirective]]s 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](http://validator.w3.org/check?url=referer)
+
+[[done]]
--- /dev/null
+ikiwiki needs a logo. I'm thinking something simple like the word "ikiwiki"
+with the first "k" backwards; drawn to show that it's "wiki" reflected.
+
+[[done]]
--- /dev/null
+Should 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 --[[Joey]]
+
+ 3. 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:
+
+ 4. Each user should be able to tune whether they see the actual diff parts or
+ not.
+ 5. Each user should be able to set a maximum desired email size.
+ 6. 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]]
--- /dev/null
+* page name substring search
+* full text (use third-party tools?)
+ - hyperestraier looks nice
+
+[[done]]
--- /dev/null
+There should be a --strftime switch that controls how all the dates are
+formatted.
+
+[[done]]
--- /dev/null
+Rather 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]]
--- /dev/null
+It's annoying to have to manually run --setup, especially for multiple
+blogs, on upgrade. Is the deb is used, there could be a postinst hook to do
+this.
+
+Let there be an /etc/ikiwiki/wikis, which just lists setup files and the
+user who owns them. postinst loops through, su's, and runs --setup. Voila!
+
+[[done]]
--- /dev/null
+ikiwiki should support utf-8 pages, both input and output. To test, here's a
+utf-8 smiley:
+
+# ☺
+
+Currently ikiwiki is belived to be utf-8 clean itself; it tells perl to use
+binmode when reading possibly binary files (such as images) and it uses
+utf-8 compatable regexps etc.
+
+Notes:
+
+* Apache "AddDefaultCharset on" settings will not play well with utf-8
+ pages. Turn it off.
+
+[[done]]
--- /dev/null
+- \[[John|Fred]] is a Wikipedia method for linking to the one page
+ while displaying it as the other, Kyle would like this.
+
+[[done]]