diff options
Diffstat (limited to 'doc/todo')
| -rw-r--r-- | doc/todo/Commit_emails:_ones_own_changes.mdwn | 3 | ||||
| -rw-r--r-- | doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn | 6 | ||||
| -rw-r--r-- | doc/todo/aggregate_to_internal_pages.mdwn | 5 | ||||
| -rw-r--r-- | doc/todo/bzr.mdwn | 8 | ||||
| -rw-r--r-- | doc/todo/httpauth_example.mdwn | 3 | ||||
| -rw-r--r-- | doc/todo/mercurial.mdwn | 2 | ||||
| -rw-r--r-- | doc/todo/passwordauth:_sendmail_interface.mdwn | 1 | ||||
| -rw-r--r-- | doc/todo/plugin.mdwn | 16 | ||||
| -rw-r--r-- | doc/todo/recentchanges.mdwn | 56 |
9 files changed, 81 insertions, 19 deletions
diff --git a/doc/todo/Commit_emails:_ones_own_changes.mdwn b/doc/todo/Commit_emails:_ones_own_changes.mdwn index d577c454f..862a85071 100644 --- a/doc/todo/Commit_emails:_ones_own_changes.mdwn +++ b/doc/todo/Commit_emails:_ones_own_changes.mdwn @@ -4,3 +4,6 @@ What's the rationale behind excluding ones own changes from the commit emails se > Well, commit mails are intended to keep you informed of changes in the > wiki, and I assumed you'd know about changes you made yourself. > --[[Joey]] + +> [[done]] -- commit mails removed; recentchanges feeds can be configured +> for whatever you like. diff --git a/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn b/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn index 70970c6cc..dc456bbbf 100644 --- a/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn +++ b/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn @@ -3,4 +3,8 @@ user to add a page to their subscribed list while editing. This would prove particularly useful for [[todo]] and [bug](bugs) items, to allow users to receive notifications for activity on their reports. ---[[JoshTriplett]]
\ No newline at end of file +--[[JoshTriplett]] + +I went and removed commit notification mails entirely, the idea is that you +subscribe using the [[RecentChanges]] rss feed, and filter it on your end. +Good enough? --[[Joey]] diff --git a/doc/todo/aggregate_to_internal_pages.mdwn b/doc/todo/aggregate_to_internal_pages.mdwn new file mode 100644 index 000000000..a4164fa25 --- /dev/null +++ b/doc/todo/aggregate_to_internal_pages.mdwn @@ -0,0 +1,5 @@ +The new internal page feature is designed for something like +[[plugins/aggregate]]. + +How to transition to it though? inlines of aggregated content would need to +change their pagespecs to use `internal()`. diff --git a/doc/todo/bzr.mdwn b/doc/todo/bzr.mdwn index dbe35245c..51ae08146 100644 --- a/doc/todo/bzr.mdwn +++ b/doc/todo/bzr.mdwn @@ -4,6 +4,8 @@ rcs_commit was only changed to work around bzr's lack of a switch to set the username). bzr_log could probably be written better by someone better at perl, and rcs_getctime and rcs_notify aren't written at all. --[[bma]] +(rcs_notify is not needed in this branch --[[Joey]]) + #!/usr/bin/perl use warnings; @@ -183,4 +185,8 @@ and rcs_getctime and rcs_notify aren't written at all. --[[bma]] >>> It's new (in fact I'm not even sure that it made it in to 0.90, it might be in 0.91 due >>> in a couple of weeks. ->>> I was just noting it for a future enhancement. --[[JamesWestby]]
\ No newline at end of file +>>> I was just noting it for a future enhancement. --[[JamesWestby]] + +> I've just posted another patch with support for bzr, including support for +> --author and a testsuite to git://git.samba.org/jelmer/ikiwiki.git. I hadn't +> seen this page earlier. --[[jelmer]] diff --git a/doc/todo/httpauth_example.mdwn b/doc/todo/httpauth_example.mdwn index f67f67371..0c6268aa1 100644 --- a/doc/todo/httpauth_example.mdwn +++ b/doc/todo/httpauth_example.mdwn @@ -3,3 +3,6 @@ authentication (perhaps as a [[tip|tips]]), showing how to authenticate the user for edits without requiring authentication for the entire wiki. (Ideally, recentchanges should work without authentication as well, even though it goes through the CGI.) --[[JoshTriplett]] + +> (Now that recentchanges is a static page, it auths the same as other wiki +> pages.) --[[Joey]] diff --git a/doc/todo/mercurial.mdwn b/doc/todo/mercurial.mdwn index e5de93521..608c7d681 100644 --- a/doc/todo/mercurial.mdwn +++ b/doc/todo/mercurial.mdwn @@ -1,6 +1,6 @@ * Need to get post commit hook working (or an example of how to use it.) * See below. --[[bma]] -* rcs_notify is not implemented +* rcs_notify is not implemented (not needed in this branch --[[Joey]]) * Is the code sufficiently robust? It just warns when mercurial fails. * When rcs_commit is called with a $user that is an openid, it will be passed through to mercurial -u. Will mercurial choke on this? diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn index 4714a7a09..4bbda6565 100644 --- a/doc/todo/passwordauth:_sendmail_interface.mdwn +++ b/doc/todo/passwordauth:_sendmail_interface.mdwn @@ -44,7 +44,6 @@ Remaining TODOs: just for this bit of functionality? * Debian news file. * ikiwiki news file. - * Are commit emails still working? --[[tschwinge]] diff --git a/doc/todo/plugin.mdwn b/doc/todo/plugin.mdwn index 0d702975f..89dbb04a2 100644 --- a/doc/todo/plugin.mdwn +++ b/doc/todo/plugin.mdwn @@ -6,20 +6,6 @@ Suggestions of ideas for plugins: > web-server-specific code to list all users, and openid can't feasibly do so > at all. --[[JoshTriplett]] -* Support [[RecentChanges]] as a regular page containing a plugin that - updates each time there is a change, and statically builds the recent - changes list. (Would this be too expensive/inflexible? There might be - other ways to do it as a plugin, like making all links to RecentChanges - link to the cgi and have the cgi render it on demand.) - - Or using an iframe - to inline the cgi, although firefox seems to render that nastily with - nested scroll bars. :-( -> Or just link to the equivalent in the version control system, if available; -> gitweb's shortlog or summary view would work nicely as a -> RecentChanges. --[[JoshTriplett]] ->>Why not fork the process? We wouldn't have to wait around for a response since we would assume the recent changes page was being generated correctly. - * It would be nice to be able to have a button to show "Differences" (or "Show Diff") when editing a page. Is that an option that can be enabled? Using a plugin? @@ -58,4 +44,4 @@ Suggestions of ideas for plugins: * As I couldn't find another place to ask, I'll try here. I would like to install some contributed plugins, but can not find anywhere to downlod them. - > Not sure what you mean, the [[plugins/contrib]] page lists contributed plugins, and each of their pages tells where to download the plugin from.. --[[Joey]]
\ No newline at end of file + > Not sure what you mean, the [[plugins/contrib]] page lists contributed plugins, and each of their pages tells where to download the plugin from.. --[[Joey]] diff --git a/doc/todo/recentchanges.mdwn b/doc/todo/recentchanges.mdwn index d46c0d9a8..91128a860 100644 --- a/doc/todo/recentchanges.mdwn +++ b/doc/todo/recentchanges.mdwn @@ -86,3 +86,59 @@ your pages. --Ethan > backend. > > -- CharlesMauch + +---- + +Here's a full design for redoing recentchanges, based on Ethan's ideas: + +* Add a recentchanges plugin that has a preprocessor directive: + \[[recentchanges num=100 pages=* template=recentchanges.tmpl]] + If put on the [[recentchanges]] page, this would result in up to 100 + recentchanges/change_$id.mdwn files being created. +* Which means the plugin has to store state and use a checkconfig hook + or the like to create the requested pages (and delete old ones) when + the wiki is rebuilt and when the post_commit hook is run. +* Then it's a simple matter of using inline on the recentchanges page + to display the changes. (With a special template to display nicely.) +* Rss/atom comes for free.. +* So drop mail notifications. +* If someone wants to subscribe to notifications for only a subset + of pages, they can either filter the recentchanges in their rss + aggregator, or they can set up their own page that uses the recentchanges + directive for only the pages they want. +* The `rcs_notify` functions will be removed. +* To add diffs, another plugin can add a pagetemplate hook that calls + a `rcs_diff`. (optional) +* So to update the changes files, just call `rcs_recentchanges`, create + files for each new id, and delete files for each id that is no longer + included. +* The cgi support for recentchanges can be dropped, or moved to a different + plugin. + +I'm unsure how fast this will all be, but by using regular pages, there's +cacheing, at least. The main slowdown might turn out to be the inlining and +not the generation of the changes pages. The current cgi recentchanges +code saves a tenth of a second or so by memoizing htmllink, an optimisation +that won't be available when using the more general inlining code. + +An obvious optimisation, and one implied by this design, is that each change +file is only written once. This assumes that the data in them doesn't ever +change, which actually isn't true (svn commit messages can be changed), but +is probably close enough to true for our purposes. + +Another optimisation would be to htmlize the change files when they're +written out -- avoids re-rendering a given file each time a new change is +made (thus doing 1/100th the work). + +Links in the change files to the changed pages will need special handling. +These links should not generate backlinks. They probably shouldn't be +implemented as wikiliks at all. Instead, they should be raw, absolute +html links to the pages that were changed. + +Only problem with this approach is that the links break if the changed +page later gets deleted. I think that's acceptable. It could link to +`ikiwiki.cgi?do=redir&page=foo`, but that's probably overkill. + +--[[Joey]] + +[[done]] !! (in this branch at least :-) |