phpwiki-talk

Re: [Phpwiki-talk] index.php vs config.php

[Joby W. <joby@u.washington.edu>]

I agree with Martin that we need to provide some additional options, 
which I would be happy to help with.  Another option would be a command 
line php script, much like Squirrelmail's perl configuration script.

jbw

Martin Geisler wrote:
> Jeff Dairiki <da...@da...> writes:
> 
> 
>>Maybe, since we have a configuration script, the configuration
>>script should do all the figuring of the defaults and autodetected
>>values. (I.e. everything that's now down in lib/config.php.)
>>
>>Then it can generate a single config file with all required settings
>>as constants.
> 
> 
> Are you sure it's a good idea to have the script write a file with the
> settings? This was how my first attempt at a configuration tool
> worked, but I've now moved away from the idea.
> 
> The problem is that it rarely works... It only works if the webserver
> has write permission to the installation directory of PhpWiki.
> 
> At my server PHP runs as the user 'nobody' whereas the files are owned
> by user 'gimpster'.
> 
> The configuration tool also has to be protected so that others cannot
> change the configuration. This is not a problem, but it has to be
> considered.
> 
> The current configurator lets you create a configuration that you can
> /download/ and then later upload using FTP or whatever mechanism you
> use for this.
> 
> Just a couple of thoughts...
> 

Re: [Phpwiki-talk] index.php vs config.php

[Martin G. <gim...@gi...>]

Jeff Dairiki <da...@da...> writes:

> Maybe, since we have a configuration script, the configuration
> script should do all the figuring of the defaults and autodetected
> values. (I.e. everything that's now down in lib/config.php.)
>
> Then it can generate a single config file with all required settings
> as constants.

Are you sure it's a good idea to have the script write a file with the
settings? This was how my first attempt at a configuration tool
worked, but I've now moved away from the idea.

The problem is that it rarely works... It only works if the webserver
has write permission to the installation directory of PhpWiki.

At my server PHP runs as the user 'nobody' whereas the files are owned
by user 'gimpster'.

The configuration tool also has to be protected so that others cannot
change the configuration. This is not a problem, but it has to be
considered.

The current configurator lets you create a configuration that you can
/download/ and then later upload using FTP or whatever mechanism you
use for this.

Just a couple of thoughts...

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] How to delete a specific revision?

[Martin G. <gim...@gi...>]

Joby Walker <joby@u.washington.edu> writes:

> Martin Geisler wrote:
> > I don't quite follow you... is this based on a philosophical view that
> > deleting any information is bad? If so, then another solution to my
> > problem with bad revisions could be to create a new revision based on
> > an old (good) revision.
> >
> 
> It has to do with application.  My wiki is for the documentation for
> the University of Washington's Operations Center, so writing/editing
> permissions are being locked down to administrators -- thus defacement
> should be seriously limited and would be necessary evidence for a
> security audit.

I can see how your environment is different from mine: I'm the only
administrator whereas you have a whole team of them.
 
> And yes I do create new revisions off of the last good one (I've
> messed pages up by accident...).

OK - I wasn't aware of this trick when I wrote my first message, but
now that I know about it, I can see how easy it is to revert changes.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] How to delete a specific revision?

[Joby W. <joby@u.washington.edu>]

Martin Geisler wrote:
 > I don't quite follow you... is this based on a philosophical view that
 > deleting any information is bad? If so, then another solution to my
 > problem with bad revisions could be to create a new revision based on
 > an old (good) revision.
 >

It has to do with application.  My wiki is for the documentation for the 
University of Washington's Operations Center, so writing/editing 
permissions are being locked down to administrators -- thus defacement 
should be seriously limited and would be necessary evidence for a 
security audit.

And yes I do create new revisions off of the last good one (I've messed 
pages up by accident...).

jbw

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib/plugin RedirectTo.php,1.2,1.3

[Reini U. <ru...@x-...>]

Geoffrey T. Dairiki schrieb:
> Index: RedirectTo.php
> + * BUGS/COMMENTS:
> + *
> + * Actually, it seems that this plugin can be invoked from anywhere on a page.
> + * (Not just the first line.)

fixed in current CVS.

> + * This plugin could probably result in a lot of confusion, especially when
> + * redirecting to external sites.  (Perhaps it can even be used for dastardly
> + * purposes?)  Maybe it should be disabled by default.
> + *
> + * It would be nice, when redirecting to another wiki page, to (as
> + * UseModWiki does) add a note to the top of the target page saying
> + * something like "(Redirected from SomeRedirectingPage)".

See this patch attached.
Maybe we shouldn't check for another get argument at WikiRequest. 
redirectfrom=FromPage. But okay for me.

The question is if we should add the note "Redirected from Pagename" at 
the top or bottom. Currently at the bottom. Looks better to me, but for 
consistency it would also be okay at the top.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] index.php vs config.php

[Reini U. <ru...@x-...>]

Reini Urban schrieb:
> Jeff Dairiki schrieb:
>> Maybe, since we have a configuration script, the configuration script
>> should do all the figuring of the defaults and autodetected values.
>> (I.e. everything that's now down in lib/config.php.)
>> Then it can generate a single config file with all required settings
>> as constants.   Faster to load at run time  --- though I doubt that's
>> our main speed bottleneck :-)
> 
> Yes.
> Configurator.php should be called when no lib/config-user.php exists,
> the virgin setup.

I added that in the current cvs configurator.

> Then we can ensure that e.g. the admin password is encrypted, the 
> include path and many more paths can be guessed automatically and good 
> suggestions for VIRTUAL_PATH configurations can be choosen from.

This will need some apache/conf/httpd.conf parsing and changing. This 
way we could check file-permissions and provide a good .htaccess 
solution. But not quite easy.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] simplify default template

[Reini U. <ru...@x-...>]

Reini Urban schrieb:
> I want to simplify the default template actionbar:
> Show only the Edit and Info button.
> The Diff, PageHistory and DebugInfo buttons are accessible from the 
> info.tmpl page.
> Should I give it a try on the demo wiki?

I now committed it now to CVS.

See also my shorter "Search" button and the autosplit buttons at 
http://xarch.tu-graz.ac.at/autocad/wiki/

How about changing the pagename "FindPage" => "Search" on the default 
template? (German: "Suche")
Of course one can create his own navbar.tmpl template version.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib Template.php,1.45,1.46 WikiPlugin.php,1.25,1.26

[Jeff D. <da...@da...>]

Hi Reini,

Now that I've started looking at PhpWiki code a bit again
(I hadn't really followed a lot of the changes for the past
few months)...   whew.... it's getting pretty messy.
(Not your fault, for the most part... :-) )

Anyhow,  I don't like <?plugin-head, and the extra hooks it
involves....   If something like it is really necessary, it
should probably be done via pagetypes rather than plugins.

Using plugins for RedirectTo is kludgy, but, I think, acceptable,
except for the extra hooks.

I've always planned on modifying the plugin API a bit, once
it became clear how it should be modified.  I don't think it
would a bad idea to modify the expandPI API so that a plugin
can get some information about the context from where it's called.
(That way RedirectTo can check that it's the first thing on
the page, and issue an error if it's not...)

Not sure how this should best be done.  I'm thinking: pass expandPI
a PluginContext object (or some such) instead of the current $request
second argument.  The PluginContext  will contain methods to access
things like:
  * pagename
  * input line number?
  * query POST/GET args directed at the plugin?
  * the $request
  What else?

I'm beginning to plan on cleaning up the PageType code now too,
as that is driving me nuts....

I think, at present the only other place plugin-head is used
is your FrameInclude plugin.   (Another plugin which scatters
hooks everywhere ... hmm...)

...err... random thoughts and rantings... on sunday .. before coffee...
  sorry I'm so grumpy...


Anyhow, I plan on trying out a Transclude plugin which will
use <iframe>s (or <layer>s for NS4 compat) which might obviate some of
the need for FrameInclude...



More random comments:
     Why UserPage/Preferences?  Why not just store the prefs in a
  'preferences' meta value  (which would be a hash) on the UserPage?  
  Actually, even better, why not just one meta-value called 'userpage'
  attached to the UserPage.  It would be a hash containing among other
  things:
     'preferences':  (another hash)
     'password':  (if password is stored in the UserPage)
     ....
  (This avoids namespace pollution of the meta-tags.) 
  (The presence of the 'userpage' meta tag marks the page as a user page.)


About subpages:

  /Page still looks like a absolute path to me.  (I think I still
  like the idea of dots instead of slashes --- but maybe that's
  just cause I'm an object orientated kind of guy....)

  Should /SubPage (which really means ThisPage/SubPage)
  really be displayed (when linkified) as "SubPage"?
  (I think the '/' should be preseved to indicate to the user
  that it's a subpage link.)

  Should ThisPage/SubPage (within page text) really be rendered
  as two links (with "ThisPage" linking to the parent and "SubPage"
  linking to the child?)    I think splitting the page title
  this way makes lots of sense --- it makes it easy to get to
  the parent page.  But splitting links within the
  page text this way, to me, just seems to add confusion without
  adding much utility...
  
  It would be nice to have a shorthand for referring to sibling
  subpages.  Any ideas?  '../SiblingPage' might work, but I don't
  like it.  which leads to...

  Shorthand for referring to the parent page?

Again, sorry I'm so grumpy this morning....

Re: [Phpwiki-talk] index.php vs config.php

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
> On Sun, 15 Sep 2002 12:50:11 +0100
> Reini Urban <ru...@x-...> wrote:
> 
>>Maybe an INI style lib/config.ini
>>lib/config.php parses this then and fills in the defaults.
> 
> I'm not sure I see the advantage of an INI style config file
> over an user-config.php.

Readability.

> Brainstorming...
> 
> Maybe, since we have a configuration script, the configuration script
> should do all the figuring of the defaults and autodetected values.
> (I.e. everything that's now down in lib/config.php.)
> Then it can generate a single config file with all required settings
> as constants.   Faster to load at run time  --- though I doubt that's
> our main speed bottleneck :-)

Yes.
Configurator.php should be called when no lib/config-user.php exists,
the virgin setup.

Then we can ensure that e.g. the admin password is encrypted, the 
include path and many more paths can be guessed automatically and good 
suggestions for VIRTUAL_PATH configurations can be choosen from.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] index.php vs config.php

[Jeff D. <da...@da...>]

On Sun, 15 Sep 2002 12:50:11 +0100
Reini Urban <ru...@x-...> wrote:

> Maybe an INI style lib/config.ini
> lib/config.php parses this then and fills in the defaults.

I'm not sure I see the advantage of an INI style config file
over an user-config.php.

Brainstorming...

Maybe, since we have a configuration script, the configuration script
should do all the figuring of the defaults and autodetected values.
(I.e. everything that's now down in lib/config.php.)
Then it can generate a single config file with all required settings
as constants.   Faster to load at run time  --- though I doubt that's
our main speed bottleneck :-)

Re: [Phpwiki-talk] Upgrading to newer versions of PHPWiki.

[Reini U. <ru...@x-...>]

Lawrence F. London, Jr. schrieb:
> 1) Where can I download upgrades of PHPWiki and see working demos of them?

http://phpwiki.sourceforge.net/phpwiki/

> 2) What is the most efficient way to upgrade an existing installation of 
> PHPWiki?
>    - I assume start from scratch with a new filesystem then configure 
> all necessary files
>      (index.php, themes, maybe others) from data in files from old version.

yes. new directory and new database scheme and some new configuration 
options.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] List all Titles / Pages?

[Reini U. <ru...@x-...>]

Ian Porteous schrieb:
> Hello,
>  
> Is there an easy way to list all the titles / pages in a phpWiki site 
> (perhaps using a plugin?) Preferably in alphabetical order, to create a 
> sort of index?

yes. AllPages using the plugin AllPages.
See http://phpwiki.sourceforge.net/demo/en/AllPages


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib/plugin RedirectTo.php,1.2,1.3

[Reini U. <ru...@x-...>]

Geoffrey T. Dairiki schrieb:
> + * BUGS/COMMENTS:
> + *
> + * Actually, it seems that this plugin can be invoked from anywhere on a page.
> + * (Not just the first line.)

oops.

> + * This plugin could probably result in a lot of confusion, especially when
> + * redirecting to external sites.  (Perhaps it can even be used for dastardly
> + * purposes?)  Maybe it should be disabled by default.

yes, disable the href parameter like ENABLE_RAW_HTML.

> + * It would be nice, when redirecting to another wiki page, to (as
> + * UseModWiki does) add a note to the top of the target page saying
> + * something like "(Redirected from SomeRedirectingPage)".

good idea.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] index.php vs config.php

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
>>How about placing the configuration in two files: one file with a
>>default configuration and one file with the users customizations.
> 
> Yes.  The current system sort of started out that way with
> the 'user-config' in index.php and the 'dist-config' in
> lib/config.php.  I.e. most of the settings in index.php
> were commented out be default, and then lib/config.php
> filled in the defaults...
 >
> I think it would be real slick if the config script got all its
> info from (specially formatted) comments (and code) in the 
> dist-config file.  (Maybe it already works that way?)
> Then problems with keeping the configurator in sync with the
> config options go away....

Maybe an INI style lib/config.ini
lib/config.php parses this then and fills in the defaults.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] index.php vs config.php

[Jeff D. <da...@da...>]

 
> How about placing the configuration in two files: one file with a
> default configuration and one file with the users customizations.

Yes.  The current system sort of started out that way with
the 'user-config' in index.php and the 'dist-config' in
lib/config.php.  I.e. most of the settings in index.php
were commented out be default, and then lib/config.php
filled in the defaults...

(Note that due to our use of define()s (which can't be
re-defined)  the dist-defaults need to be filled in _after_
the user customizations, like so:

  if (!defined('FOO'))
     define('FOO', 'default value');
)


Over time, as people have added options to index.php, I see
the defaults have been stuck in there too...  

I think it would be real slick if the config script got all its
info from (specially formatted) comments (and code) in the 
dist-config file.  (Maybe it already works that way?)
Then problems with keeping the configurator in sync with the
config options go away....

Re: [Phpwiki-talk] index.php vs config.php

[Martin G. <gim...@gi...>]

Jeff Dairiki <da...@da...> writes:

> Hey, I'd like to move the configuration data out of index.php
> (again). (The little auto-decide if we really wanted to fire up main
> or not code at the bottom of the current index.php is
> problematic...) Having the config information in index.php was
> clever when we only had one script using the info, but now it's just
> a pain, and causing uneeded complexity...

How about placing the configuration in two files: one file with a
default configuration and one file with the users customizations. The
default configuration should always be included, but the users
customization is only included if the right file exists. Somethings
like this:

    include('config/config-dist.php');

    if(file_exists('config/config-user.php')) {
      include('config/config-user.php');
    }

The config-user.php file should then be ignored by CVS: I've seen
conflicts when I've done 'cvs update' due to my changes in index.php.

This config-user.php file should then be generated by some tool - I
was very happy when I saw, that you've used the configurator.php
script from PHP Weather 1.x as a basis for such a tool.

Perhaps you'll like the new config tool I've made for PHP Weather 2.0.
It does nice things like generating JavaScript code to check
selections at the client before they're submitted and have a general
system for defining dependencies between the various options which
should prevent the user from making a wrong config file.

You can try it out here:

  http://phpweather.sourceforge.net/phpweather/config/make_config.php

And the source can be found here:

  http://cvs.sf.net/cgi-bin/viewcvs.cgi/phpweather/phpweather/config/

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

[Phpwiki-talk] index.php vs config.php

[Jeff D. <da...@da...>]

Hey, I'd like to move the configuration data out of index.php (again).
(The little auto-decide if we really wanted to fire up main or not
code at the bottom of the current index.php is problematic...)
Having the config information in index.php was clever when we
only had one script using the info, but now it's just a pain,
and causing uneeded complexity...

My current thinking is that index.php should look like:

<?php
include('config/config.php')
include('lib/main.php')
main();
?>

(Also, I think we should ensure that including lib files doesn't
actually _do_ anything beyond defining things (i.e. classes, defines,
functions, or variables).  One should have to call a function before
anything happens.)

Any objections or other comments?

[Phpwiki-talk] List all Titles / Pages?

[Ian P. <ia...@ip...>]

Hello,

Is there an easy way to list all the titles / pages in a phpWiki site =
(perhaps using a plugin?) Preferably in alphabetical order, to create a =
sort of index?

Regards

Ian

[Phpwiki-talk] Upgrading to newer versions of PHPWiki.

[Lawrence F. L. Jr. <lf...@in...>]

1) Where can I download upgrades of PHPWiki and see working demos of them?
2) What is the most efficient way to upgrade an existing installation of PHPWiki?
    - I assume start from scratch with a new filesystem then configure all necessary files
      (index.php, themes, maybe others) from data in files from old version.
LL
-- 
L.F.London
lf...@in...
http://market-farming.com
PermacultureWiki
http://www.ibiblio.org/ecolandtech/pcwiki/index.php

Re: [Phpwiki-talk] How to delete a specific revision?

[Reini U. <ru...@x-...>]

Martin Geisler schrieb:
> Reini Urban <ru...@x-...> writes:
>>I'll add it to a new plugin similar to WikiAdminRemove. Name:
>>WikiAdminRemoveLatestVersion, on which you can do it on multiple
>>pages.
> Sounds great! I'll be watching the CVS commits...

WikiAdminRemoveLatestVersion is already ready,
but before committing it I'll have to fix the current WikiAuth problem...
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] How to delete a specific revision?

[Martin G. <gim...@gi...>]

Martin Geisler <gim...@gi...> writes:

> Reini Urban <ru...@x-...> writes:
>
>> I'll add it to a new plugin similar to WikiAdminRemove. Name:
>> WikiAdminRemoveLatestVersion, on which you can do it on multiple
>> pages.
> 
> Sounds great! I'll be watching the CVS commits...

It doesn't appear to be necessary - Lawrence F. London made me aware
that editing and saving an old revision overwrites the current
revision. That's exactly the kind of thing I was looking for.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] How to delete a specific revision?

[Martin G. <gim...@gi...>]

Reini Urban <ru...@x-...> writes:

> Deleting the last version only is a good idea. Deleting in-between
> versions probably not.

I agree - this should only be used to restore the content of a page
that has been vandalised, not to make arbitrary changes to the history
of a page.

> Currently we do manual reverting, which might become tedious on
> WikiVandalism.
> 
> I'll add it to a new plugin similar to WikiAdminRemove. Name:
> WikiAdminRemoveLatestVersion, on which you can do it on multiple
> pages.

Sounds great! I'll be watching the CVS commits...

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] How to delete a specific revision?

[Martin G. <gim...@gi...>]

Joby Walker <joby@u.washington.edu> writes:

> Martin Geisler wrote:
> 
>> But I imagined that it should work just like the 'Remove Page'
>> button that only appears when you're signed in as the
>> administrator. So normal users shouldn't have access to it.
>>
> 
> That's not really the issue. I don't want _ANYONE_ to be able to
> delete versions. Although I have an intesive backup scheme, I don't
> want to lose any data -- even if undesireable.

I don't quite follow you... is this based on a philosophical view that
deleting any information is bad? If so, then another solution to my
problem with bad revisions could be to create a new revision based on
an old (good) revision.

So if R0 is the revision with SPAM, then I could create revision R1
based on a copy of R-1 and then nothing would have been deleted.

If it's not about this, then I don't understand the problem - the
ability for the administrator to delete a single revision is just a
more fine-grained version of the 'Remove Page' button the
administrator has access to now.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] How to delete a specific revision?

[Reini U. <ru...@x-...>]

Joby Walker schrieb:
> Martin Geisler wrote:
> 
>> Aha, like a linked list? But the comments also say that you cannot
>> modify a revision, you can only create or delete them, so perhaps this
>> is a bigger issue?
>>
> 
> Kinda.  I'm not a huge fan of the current structure, but as far as I can 
> see by looking at the database (version table).  Each record stores the 
> mtime of the version number that replaces it.  Thus the following would 
> have to happen:
> 
> I'll use R0 for the revision to be deleted. R1 for a revision that might 
> follow R0.  And R-1 for the revision that is prior to R0.
> 
> If the purged revision is the newest:
> 1) delete R0
> 2) revert R-1 to be the final version
> 
> If there is a R1:
> 1) grab from R0 the mtime of R1
> 2) change the mtime stored in R-1 (which would be R0) to value in 1)
> 3) delete R0.
> 
> There might be other consiquenses.  I haven't looked too much into this. 
>  The developers that have been around longer would know.
> 
>> But I imagined that it should work just like the 'Remove Page' button
>> that only appears when you're signed in as the administrator. So
>> normal users shouldn't have access to it.
>>
> 
> That's not really the issue.  I don't want _ANYONE_ to be able to delete 
> versions.  Although I have an intesive backup scheme, I don't want to 
> lose any data -- even if undesireable.  Of course I am implimenting some 
> severe editing restrictions so undesireable content is unlikely to 
> occur.  I would prefer if this functionality would have to be enabled 
> via a defined constant in index.php.

Deleting the last version only is a good idea. Deleting in-between 
versions probably not.
Currently we do manual reverting, which might become tedious on 
WikiVandalism.

I'll add it to a new plugin similar to WikiAdminRemove.
Name: WikiAdminRemoveLatestVersion, on which you can do it on multiple 
pages.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] How to delete a specific revision?

[Joby W. <joby@u.washington.edu>]

Martin Geisler wrote:
> Aha, like a linked list? But the comments also say that you cannot
> modify a revision, you can only create or delete them, so perhaps this
> is a bigger issue?
> 

Kinda.  I'm not a huge fan of the current structure, but as far as I can 
see by looking at the database (version table).  Each record stores the 
mtime of the version number that replaces it.  Thus the following would 
have to happen:

I'll use R0 for the revision to be deleted. R1 for a revision that might 
follow R0.  And R-1 for the revision that is prior to R0.

If the purged revision is the newest:
1) delete R0
2) revert R-1 to be the final version

If there is a R1:
1) grab from R0 the mtime of R1
2) change the mtime stored in R-1 (which would be R0) to value in 1)
3) delete R0.

There might be other consiquenses.  I haven't looked too much into this. 
  The developers that have been around longer would know.

> But I imagined that it should work just like the 'Remove Page' button
> that only appears when you're signed in as the administrator. So
> normal users shouldn't have access to it.
> 

That's not really the issue.  I don't want _ANYONE_ to be able to delete 
versions.  Although I have an intesive backup scheme, I don't want to 
lose any data -- even if undesireable.  Of course I am implimenting some 
severe editing restrictions so undesireable content is unlikely to 
occur.  I would prefer if this functionality would have to be enabled 
via a defined constant in index.php.

jbw