Tim Starling wrote:
Salvatore's moderation feature was implemented in a similar way to
Magnus' one, in that it used an extra revision ID field in the page
table to point to the relevant version. Salvatore's used parameters
passed back to Revision to determine whether page_latest or
page_verified should be used, whereas Magnus's code operated mainly at
the UI level, redirecting to a page with an oldid parameter, IIRC.
My current
implementation does the template expansion at the moment of
setting the current version, and stores that text in its own database
table. It then checks if the requested version is a stable one, and
replaces the article text with the stored text.
Note that this is not the fastest way to do it, but it allows for
* multiple stable versions (deactivated by default, allowing only one
stable version per article)
* other types of "stablilty", like stable, reviewed, thoroughly
reviewed, really really reviewed, etc. :-)
Both these properties were requested at some time.
Perhaps the simplest solution at the moment is to put Magnus's feature
live (after the necessary code cleanup), and put up with the lack of
caching for a while. We've still got a bit of spare hardware capacity
haven't we? The request rate for stable versions should be lower than
it would have been for verified revisions. If I understand it
correctly, stable revisions are not displayed by default, verified
revisions would have been.
After some hints from Brion yesterday, I changed a few
things. There's
probably lots more, though. :-)
Brion also reported a strange effect on next/prev version links; I see
that too, but it doesn't change when I turn the extension off, so the
effect might not be related to the feature.
A few nice things are also still missing, like marking the stable
version in the page history. Also, maybe the text should display in the
sidebar instead of the sitenotice space.
But the core functionality is there.
Magnus