## online page editing
-To support editing pages in a web browser, a CGI script is needed that
-pulls the page out of [[Subversion]], presents it to the user for editing,
-and then commits the changed page back to [[Subversion]].
+* Missing support for preview.
+* Missing conflict detection, just overwrites changes and does not svn up
+ first..
+* Eventually, might want page deletion.
+* Eventually, might want file upload.
-Due to [[WikiSpam]], this will probably also need to incorporate a user
-registration system. So there will need to be a script that handles logins
-and registrations, sets a cookie, and the page editor can refuse to edit
-pages for users who arn't logged in, and include a not of who made the
-change in the svn log.
+## recentchanges
-If possible I'd prefer to use someone else's generic web user registration
-and login system, if one exists.
+* Should support RSS for notification of new and changed pages.
-## [[RecentChanges]]
+ 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.)
-This will need to be another cgi script, that grubs through the
-[[Subversion]] logs.
+* Should support mail notification of new and changed pages.
-This should support RSS for notification of new and changed pages.
-
-## page history
-
-To see past versions of a page, we can either implement a browser for that,
-or just provide a way to link to the page in viewcvs.
+ 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.
## pluggable renderers
The finalize step is where the page gets all the pretty junk around the
edges, so that clearly needs to be pluggable too.
-There could also be a step before finalize, where stuff like lists of pages
-that linked back to it could be added to the page.
+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
+
+## [[Bugs]]
projects / ikiwiki.git / blobdiff