I spent a few hours digging into 1.3 source. Wow, it looks like a complete=
rewrite. I didn't expect so much to change in a minor version. I'm glad I=
didn't spend too much time familiarizing with the 1.2 codebase! Sorry for=
I'm kind of at a standstill now though, because 1.2 doesn't have the=
features I need (as mentioned below) or work on my server without=
modifications, and 1.3 crashes my server in a weird way (=
106121 )... What to do... Anybody seen this PCRE crash before?
>From the bug report, this code crashes (which is a simpler version of what=
my ConvertOldMarkup() does to the file OldTextFormattingRules during virgin=
$pat =3D "/\A((?:.|\n)*?)(^(?:[ \t]+\S(?:.*\s*\n[ \t]+\S)*|".
$subj =3D str_repeat("123456789 ", 50);
On Sat, 21 Aug 2004 10:34:12 +0200, Reini Urban wrote:
> 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 =3D
>> $_SERVER['SERVER_NAME']; if (isset($_SERVER['SERVER_PORT']))
>> $SERVER_PORT =3D $_SERVER['SERVER_PORT']; if
>> (isset($_SERVER['SCRIPT_NAME'])) $SCRIPT_NAME =3D
>> $_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:
>> 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.