145 lines
7.2 KiB
Markdown
145 lines
7.2 KiB
Markdown
* Why isn't it statically-genereated, but generated dynamically by CGI? It
|
|
seems like it could be beneficial to have it rendered in the post-commit
|
|
hook, just like everything else in the wiki.
|
|
|
|
> I hope to statically generate it eventually, currently the problem is
|
|
> that it takes at least several seconds to generate the recentchanges
|
|
> page, and adding several seconds to every page edit is not desiriable. If
|
|
> the time can be reduced it could be done, I'm also not adverse to
|
|
> adding an optional way to statically render it even at the current
|
|
> speed. --[[Joey]]
|
|
|
|
* Also, is it planned/desired that recent changes generate the same
|
|
information in RSS feed format? This seems like it could be a useful way
|
|
to keep track of the wiki as a whole.
|
|
|
|
> This is used by various interwiki type things, I think, so should be
|
|
> done.. --[[Joey]]
|
|
|
|
* Lastly, would it be possible to use the recent changes code with a
|
|
pagespec? I understand this sort of infringes on territory covered by the
|
|
inline plugin, but the inline plugin only puts a page in the RSS feed
|
|
once, when it's created, and I imagine some people -- some deranged,
|
|
obsessive-compulsive people like myself -- would like to know about the
|
|
changes made to existing pages as well as newly-created pages.
|
|
|
|
> That would work rather well for pages like [[todo]] and [[bugs]], where
|
|
> you want to know about any updates, not just initial
|
|
> creation. --[[JoshTriplett]]
|
|
|
|
> Of course you can use email subscriptions for that too.. --[[Joey]]
|
|
|
|
>> I have more thoughts on this topic which I will probably write
|
|
>> tomorrow. If you thought my other patches were blue-sky, wait until
|
|
>> you see this. --Ethan
|
|
|
|
OK, so here's how I see the RecentChanges thing. I write blog posts and
|
|
the inline plugin generates RSS feeds. Readers of RSS feeds are notified
|
|
of new entries but not changes to old entries. I think it's rude to change
|
|
something without telling your readers, so I'd like to address this.
|
|
To tell the user that there have been changes, we can tell the user which
|
|
page has been changed, the new text, the RCS comment relating to
|
|
the change, and a diff of the actual changes. The new text probably isn't
|
|
too useful (I have a very hard time rereading things for differences),
|
|
so any modifications to inline to re-inline pages probably won't help,
|
|
even if it were feasible (which I don't think it is). So instead we
|
|
turn to creating diffs automatically and (maybe) inlining them.
|
|
|
|
I suggest that for every commit, a diff is created automagically
|
|
but not committed to the RCS. The page containing this diff would be
|
|
a "virtual page", which cannot be edited and is not committed.
|
|
(Committing here would be bad, because then it would create a new
|
|
commit, which would need a new diff, which would need to be committed,
|
|
etc.) Virtual pages would "expire" and be deleted if they were not
|
|
depended on in some way.
|
|
|
|
Let's say these pages are created in edits/commit_%d.mdwn. RecentChanges
|
|
would then be a page which did nothing but inline the last 50 `edits/*`.
|
|
This would give static generation and RSS/Atom feeds. The inline
|
|
plugin could be optionally altered to inline pages from `edits/*`
|
|
that match any pages in its pagespec, and through this we could get
|
|
a recent-changes+pagespec thing. You could also exclude edits that have
|
|
"minor" in the commit message (or some other thing that marks them as
|
|
unremarkable).
|
|
|
|
You could make an argument that I care way too much about what amounts
|
|
to edits anyhow, but like Josh says, there are use cases for this.
|
|
While this could be done with mail subscriptions, I can think of sites
|
|
where you might want to disable all auth so that people can't edit
|
|
your pages. --Ethan
|
|
|
|
> I really dislike all Wiki engine recentchanges pages. They all tend to be
|
|
> fairly machine readable, but confusing for non-wiki users to grok. And I've
|
|
> yet to see an _attractive_ recentchanges implementation. IkiWikis' is no
|
|
> better or worse than the others.
|
|
>
|
|
> I really like the frontpage of [Bill
|
|
> Seitz](http://webseitz.fluxent.com/wiki/FrontPage) as an recentchanges
|
|
> format. Note how he uses some clever css to show changes in different
|
|
> sections of the website. I modeled my own
|
|
> [recentchanges](http://xtermin.us/recentchanges) page page on his ideas. This
|
|
> probably isn't appropriate for non-WikiLog style setups, but is this
|
|
> something closer to what you what was requested?
|
|
>
|
|
> BTW: My recentchanges plugin does not seem to add a lot processing time
|
|
> to compiling. Then again, I'm not pulling changelog message from the RCS
|
|
> 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 :-)
|