122 lines
4.4 KiB
Markdown
122 lines
4.4 KiB
Markdown
## online page editing
|
|
|
|
* Eventually, might want page deletion.
|
|
* Eventually, might want file upload.
|
|
|
|
## recentchanges
|
|
|
|
* Should support RSS for notification of new and changed pages.
|
|
|
|
This can be a static rss file that is generated when the moo
|
|
is built. (As long as all changes to all pages is ok.)
|
|
|
|
* 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.
|
|
|
|
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.
|
|
|
|
## 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.
|
|
|
|
## 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 links to commit diffs
|
|
|
|
Would take a bit more viewcvs integration, let the be a "[diff]" link in
|
|
recentchanges that goes to the diff for any listed change.
|
|
|
|
## recentchanges more than 100
|
|
|
|
Possibly add "next 100" link to it, but OTOH, you can just use svn log if
|
|
you need that data..
|
|
|
|
## base wiki
|
|
|
|
Need a toned down version of this wiki with a basic frontpage, sandbox and
|
|
docs to use as a seed for new wikis.
|
|
|
|
## search
|
|
|
|
* full text (use third-party tools?)
|
|
* list of all missing pages
|
|
* list of all pages or some kind of page map
|
|
|
|
## 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?
|
|
|
|
## page locking
|
|
|
|
Some wikis will need the abiity to lock a page, or the whole wiki, so that only admins can edit them. Probably using the same globbing as for recentchanges mails to determine what to lock.
|
|
|
|
Probably it's ok if locking is only supported for web commits.
|
|
|
|
## [[Bugs]]
|