[Phpwiki-talk] Re: PhpWiki - Superglobals and Author-independent Archiving

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

Dan Kamins schrieb:
> Hi guys. First of all, let me say that PhpWiki is great! I just got
> into the Wiki world, evaluated a bunch of Wiki packages, and almost
> immediately left the Wiki world in disgust until I found PhpWiki,
> which is well-organized, efficient, straightforward, and
> configurable.  Kudos. Now before I get too far down the path of using
> it, there are a couple of changes I was going to request, but I would
> actually be happy to do them myself and submit patches.  So what I
> wanted to ask was a) how do you feel about these changes, and b) how
> should I submit them.  It may be possible these are already in the
> 1.3 branch, but I've only installed and worked with 1.2 stable so
> far.  In fact, maybe you've discussed and/or included these in 1.3,
> but I didn't see either in the mail list archives or patch history.

All your requests are in the 1.3.x branch and much more.
1.3 is by far better, you'll like it!

And please post to the mailinglist, not to the indidviduals.

> 1. Superglobals...
> 
> As of PHP 4.2.0, register_globals went from ON to OFF by default. Many servers operate in this new mode, which is far more secure now. The effect is that PhpWiki doesn't work! And I'm *SURE* a lot of users go through what I did: install 10 different Wiki engines and evaluate them. When it doesn't work right out of the box for mysterious reasons, you're going to lose a lot of potential users. I had to dig deep to figure out what the problem was, and I think a lot of people would just move on. 
> 
> The problem manifests itself as the fact that you can't click on anything because all the links are broken. It's easy to fix, and just requires changing all global implicit vars to explicit superglobal references. Like $DOCUMENT_ROOT becomes $_SERVER['DOCUMENT_ROOT'].  A poor workaround is to slam a big set of code up at the top of config.php that does something like:
>    if (isset($_SERVER['SERVER_NAME'])) $SERVER_NAME = $_SERVER['SERVER_NAME'];
>    if (isset($_SERVER['SERVER_PORT'])) $SERVER_PORT = $_SERVER['SERVER_PORT'];
>    if (isset($_SERVER['SCRIPT_NAME'])) $SCRIPT_NAME = $_SERVER['SCRIPT_NAME'];
>    ...
> The right way to do it is to just reference the superglobal names directly.  This will break compatibility with PHPs older than 4.1.0 (when superglobals were introduces), but does anybody really use PHP that old?
> There are a LOT of these variables in the source, but I am volunteering to change them.
> 
> The motivation and history of this is clearly explained at this link:
>   http://us4.php.net/manual/en/security.globals.php
> 
> I saw a discussion regarding this ("superglobals policy") on the mail archives:
>  http://sourceforge.net/mailarchive/message.php?msg_id=2051713
> Valid points were brought up, but that was almost 2 years ago, and the world has changed a lot.  I think it's time to revisit this issue (if it hasn't been yet).
> 
> ---
> 
> 2. Author-Independent Archiving...
> 
> In 1.2 stable, only changes made by different authors get archived and are thus diff-able.  So if I make a change, then make another change, I lose my intermediate change history.  Maybe this is fine for many users, but I'm 100% other users would like every change archived (as I am one of those users), and this is functionality many other engines provide.  I propose adding a config variable (like "ArchiveOnlyWhenAuthorChanges" defaulting to TRUE, which would be same behavior as now) which would be checked in savepage.php at the point of archiving the old data.  If set to FALSE, then every change would be archived.
> 
> ---
> 
> Thanks for listening.  Let me know what you think about these issues and keep up the good work.


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