## 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]].
+* 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 mail notification of new and changed pages.
-## [[RecentChanges]]
+ 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.
-This will need to be another cgi script, that grubs through the
-[[Subversion]] logs.
+ 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.
-This should support RSS for notification of new and changed pages.
+ Joey points out that this is actually a security hole, because Perl
+ regexes let you embed (arbitrary?) Perl expressions inside them. Yuck!
-## page history
+ It would also be good to be able to subscribe to all pages except discussion pages or the SandBox: `* !*/discussion !sandobx`, maybe --[[Joey]]
-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.
+ 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
also needs to tie into the main logic, to determine what pages need to be
renered, so maybe that won't be a plugin.
-## revist case
+## 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]]
sipb-www / ikiwiki.git / blobdiff