awesome new blog-based todo page
parent
b056a106b8
commit
5c8351541d
147
doc/todo.mdwn
147
doc/todo.mdwn
|
@ -1,146 +1,9 @@
|
||||||
## online page editing
|
Welcome to ikiwiki's todo blog. Feel free to add todo items on [[SubPage]s.
|
||||||
|
|
||||||
* Eventually, might want page deletion.
|
## recently added
|
||||||
* Eventually, might want file upload.
|
|
||||||
|
|
||||||
## recentchanges
|
[[inline pages="todo/* !*/Discussion" show="30"]]
|
||||||
|
|
||||||
* Should support mail notification of new and changed pages.
|
## all todo items
|
||||||
|
|
||||||
Hmm, should be easy to implement this.. it runs as a svn post-coommit hook
|
[[inline pages="todo/* !*/Discussion" archive="yes"]]
|
||||||
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!
|
|
||||||
|
|
||||||
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]]
|
|
||||||
|
|
||||||
## pluggable renderers
|
|
||||||
|
|
||||||
I'm considering a configurable rendering pipeline for each supported
|
|
||||||
filename extension. So for ".mdwn" files, it would send the content through
|
|
||||||
linkify, markdown, and finalize, while for ".wiki" files it might send it
|
|
||||||
through just a wiki formatter and finalize.
|
|
||||||
|
|
||||||
This would allow not only supporting more types of markup, but changing
|
|
||||||
what style of [[WikiLink]]s are supported, maybe some people want to add
|
|
||||||
[[CamelCase]] for example, or don't like the [[SubPage/LinkingRules]].
|
|
||||||
|
|
||||||
The finalize step is where the page gets all the pretty junk around the
|
|
||||||
edges, so that clearly needs to be pluggable too.
|
|
||||||
|
|
||||||
There also needs to be a step before finalize, where stuff like lists of pages
|
|
||||||
that linked back to it could be added to the page. However, doing linkbacks
|
|
||||||
also needs to tie into the main logic, to determine what pages need to be
|
|
||||||
renered, so maybe that won't be a plugin.
|
|
||||||
|
|
||||||
## blogging
|
|
||||||
|
|
||||||
- Add a small form at top and bottom of a blog to allow entering
|
|
||||||
a title for a new item, that goes to a template to create the new page.
|
|
||||||
- Should probably add params to control various rss fields like the blog
|
|
||||||
title, its author email, its copyright info, etc.
|
|
||||||
|
|
||||||
## revisit case
|
|
||||||
|
|
||||||
Being case insensative is handy, but it does make the [[BackLinks]] a bit
|
|
||||||
ugly compared to other links. It should be possible to support pagenames
|
|
||||||
that have uppercase, while still allowing them to be linked to using any
|
|
||||||
case.
|
|
||||||
|
|
||||||
## html
|
|
||||||
|
|
||||||
Make the html valid. Add css and prettify. Make RecentChanges use table for formatting, and images to indicate web vs svn commits and to link to diffs.
|
|
||||||
|
|
||||||
All of this should be doable w/o touching a single line of code, just editing the [[templates]] BTW.
|
|
||||||
|
|
||||||
## sigs
|
|
||||||
|
|
||||||
Need a way to sign name in page that's easier to type than "--\[[Joey]]"
|
|
||||||
and that includes the date.
|
|
||||||
|
|
||||||
What syntax do other wikis use for this? I'm considering "\[[--]]" (with
|
|
||||||
spaces removed) as it has a nice nmemonic.
|
|
||||||
|
|
||||||
OTOH, adding additional syntax for this would be counter to one of the
|
|
||||||
design goals for ikiwiki: keeping as much markup as possible out of the
|
|
||||||
wiki and not adding nonstandard markup. And it's not significantly hard to
|
|
||||||
type "--\[[Joey]]", and as to the date, we do have page history.
|
|
||||||
|
|
||||||
## recentchanges more than 100
|
|
||||||
|
|
||||||
Possibly add "next 100" link to it, but OTOH, you can just use svn log if
|
|
||||||
you need that data..
|
|
||||||
|
|
||||||
## search
|
|
||||||
|
|
||||||
* page name substring search
|
|
||||||
* full text (use third-party tools?)
|
|
||||||
|
|
||||||
## lists
|
|
||||||
|
|
||||||
* list of all missing pages
|
|
||||||
|
|
||||||
This could be its own static pages updated when other pages are updated.
|
|
||||||
Perhaps this ties in with the pluggable renderers stuff.
|
|
||||||
|
|
||||||
## page indexes
|
|
||||||
|
|
||||||
Might be nice to support automatically generating an index based on headers
|
|
||||||
in a page, for long pages. The question is, how to turn on such an index?
|
|
||||||
|
|
||||||
## basewiki underlay
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
Impementaion 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.
|
|
||||||
|
|
||||||
There are also difficulties related to removing files from the srcdir, and
|
|
||||||
exposing ones from the underlaydir. Will need to make sure that the mtime
|
|
||||||
for the source file is zeroed when the page is removed, and that it then
|
|
||||||
finds the underlay file and treats it as newer.
|
|
||||||
|
|
||||||
## wikilinks features
|
|
||||||
|
|
||||||
- \[[John|Fred]] is a Wikipedia method for linking to the one page
|
|
||||||
while displaying it as the other, Kyle would like this.
|
|
||||||
|
|
||||||
## Logo
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
## [[Bugs]]
|
|
||||||
|
|
|
@ -0,0 +1,5 @@
|
||||||
|
- Add a small form at top and bottom of a blog to allow entering
|
||||||
|
a title for a new item, that goes to a template to create the new page.
|
||||||
|
- Should probably add params to control various rss fields like the blog
|
||||||
|
title, its author email, its copyright info, etc.
|
||||||
|
|
|
@ -0,0 +1,5 @@
|
||||||
|
Being case insensative is handy, but it does make the [[BackLinks]] and
|
||||||
|
[[blog]] links a bit ugly compared to other links. It should be possible to
|
||||||
|
support pagenames that have uppercase, while still allowing them to be
|
||||||
|
linked to using any case.
|
||||||
|
|
|
@ -0,0 +1,6 @@
|
||||||
|
Make the html valid. Add css and prettify. Make RecentChanges use table for
|
||||||
|
formatting, and images to indicate web vs svn commits and to link to diffs.
|
||||||
|
|
||||||
|
All of this should be doable w/o touching a single line of code, just
|
||||||
|
editing the [[templates]] BTW.
|
||||||
|
|
|
@ -0,0 +1,4 @@
|
||||||
|
* list of all missing pages
|
||||||
|
|
||||||
|
This could be its own static pages updated when other pages are updated.
|
||||||
|
Perhaps this ties in with the [[pluggablerenderers]]?
|
|
@ -0,0 +1,3 @@
|
||||||
|
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.
|
||||||
|
|
|
@ -0,0 +1,36 @@
|
||||||
|
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!
|
||||||
|
|
||||||
|
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]]
|
|
@ -0,0 +1,3 @@
|
||||||
|
* Eventually, might want page deletion.
|
||||||
|
* Eventually, might want file upload.
|
||||||
|
|
|
@ -0,0 +1,2 @@
|
||||||
|
Might be nice to support automatically generating an index based on headers
|
||||||
|
in a page, for long pages. The question is, how to turn on such an index?
|
|
@ -0,0 +1,17 @@
|
||||||
|
I'm considering a configurable rendering pipeline for each supported
|
||||||
|
filename extension. So for ".mdwn" files, it would send the content through
|
||||||
|
linkify, markdown, and finalize, while for ".wiki" files it might send it
|
||||||
|
through just a wiki formatter and finalize.
|
||||||
|
|
||||||
|
This would allow not only supporting more types of markup, but changing
|
||||||
|
what style of [[WikiLink]]s are supported, maybe some people want to add
|
||||||
|
[[CamelCase]] for example, or don't like the [[SubPage/LinkingRules]].
|
||||||
|
|
||||||
|
The finalize step is where the page gets all the pretty junk around the
|
||||||
|
edges, so that clearly needs to be pluggable too.
|
||||||
|
|
||||||
|
There also needs to be a step before finalize, where stuff like lists of pages
|
||||||
|
that linked back to it could be added to the page. However, doing linkbacks
|
||||||
|
also needs to tie into the main logic, to determine what pages need to be
|
||||||
|
renered, so maybe that won't be a plugin.
|
||||||
|
|
|
@ -0,0 +1,3 @@
|
||||||
|
* page name substring search
|
||||||
|
* full text (use third-party tools?)
|
||||||
|
|
|
@ -0,0 +1,11 @@
|
||||||
|
Need a way to sign name in page that's easier to type than "--\[[Joey]]"
|
||||||
|
and that includes the date.
|
||||||
|
|
||||||
|
What syntax do other wikis use for this? I'm considering "\[[--]]" (with
|
||||||
|
spaces removed) as it has a nice nmemonic.
|
||||||
|
|
||||||
|
OTOH, adding additional syntax for this would be counter to one of the
|
||||||
|
design goals for ikiwiki: keeping as much markup as possible out of the
|
||||||
|
wiki and not adding nonstandard markup. And it's not significantly hard to
|
||||||
|
type "--\[[Joey]]", and as to the date, we do have page history.
|
||||||
|
|
|
@ -0,0 +1,15 @@
|
||||||
|
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.
|
||||||
|
|
||||||
|
Impementaion 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.
|
||||||
|
|
||||||
|
There are also difficulties related to removing files from the srcdir, and
|
||||||
|
exposing ones from the underlaydir. Will need to make sure that the mtime
|
||||||
|
for the source file is zeroed when the page is removed, and that it then
|
||||||
|
finds the underlay file and treats it as newer.
|
||||||
|
|
|
@ -0,0 +1,3 @@
|
||||||
|
- \[[John|Fred]] is a Wikipedia method for linking to the one page
|
||||||
|
while displaying it as the other, Kyle would like this.
|
||||||
|
|
Loading…
Reference in New Issue