phpwiki-talk

[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/

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

[Dan K. <do...@ax...>]

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=
 the mail.

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 (=
 http://sourceforge.net/tracker/?func=3Ddetail&aid=3D1013350&group_id=3D6121&atid=3D=
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=
 setup):
  $pat =3D "/\A((?:.|\n)*?)(^(?:[ \t]+\S(?:.*\s*\n[ \t]+\S)*|".
    "\|(?:.*\n\|)*|[#*;]*(?:[*#]|;.*?:)|\[\s*(\d+)\s*\]|".
    "<\?plugin(?:-form)?\b.*\?>\s*$|!{1,3}[^!]).*$)\n?/m";
  $subj =3D str_repeat("123456789 ", 50);
  preg_match($pat, $subj);

Ouch!

--
Dan Kamins

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:
>> http://sourceforge.net/mailarchive/message.php?msg_id=3D2051713
>> 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.

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

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

Dan Kamins schrieb:

> 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 the mail.
> 
> 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 ( http://sourceforge.net/tracker/?func=detail&aid=1013350&group_id=6121&atid=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 setup):
>   $pat = "/\A((?:.|\n)*?)(^(?:[ \t]+\S(?:.*\s*\n[ \t]+\S)*|".
>     "\|(?:.*\n\|)*|[#*;]*(?:[*#]|;.*?:)|\[\s*(\d+)\s*\]|".
>     "<\?plugin(?:-form)?\b.*\?>\s*$|!{1,3}[^!]).*$)\n?/m";
>   $subj = str_repeat("123456789 ", 50);
>   preg_match($pat, $subj);

yes, this is a known issue.
cause still unknown. happens only with huge anchored regex.

please remove pgsrc/OldTextFormattingRules on virgin setup.


> Ouch!
> 
> --
> Dan Kamins
> 
> 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 =
>>>$_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.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 


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

[Phpwiki-talk] PCRE Crash in virgin setup (pgsrc files)

[Dan K. <do...@ax...>]

On Sun, 22 Aug 2004 14:24:43 +0200, Reini Urban wrote:
> Dan Kamins schrieb:
>
>> 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 (
>> http://sourceforge.net/tracker/?func=3Ddetail&aid=3D1013350&group_id=3D6121&
>> atid=3D106121 )... 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 setup):
>> $pat =3D "/\A((?:.|\n)*?)(^(?:[ \t]+\S(?:.*\s*\n[ \t]+\S)*|".
>> "\|(?:.*\n\|)*|[#*;]*(?:[*#]|;.*?:)|\[\s*(\d+)\s*\]|".
>> "<\?plugin(?:-form)?\b.*\?>\s*$|!{1,3}[^!]).*$)\n?/m"; $subj =3D
>> str_repeat("123456789 ", 50); preg_match($pat, $subj);
>
> yes, this is a known issue.
> cause still unknown. happens only with huge anchored regex.
>
> please remove pgsrc/OldTextFormattingRules on virgin setup.
>

Well I removed that file and got the crash on another file instead.  I'm=
 sure if I remove THAT file, then it will crash on either another one of the=
 pgsrc files or one of my users' pages.  Basically it's not useable, and I=
 can't really grok that regexp enough to do anything about it (like=
 splitting it up into multiple passes with smaller expressions or=
 something...).

Guys, the app looks great, and I hope you keep up the good work.  If you=
 could post (reply to this) to this mailing list when you fix this=
 particular bug, I'm sure I (and whoever else finds this thread) will be=
 excited to get back on the bandwagon.  If there's anything I can do to help=
 for now, let me know.  Otherwise I'll be waiting on the sidelines and=
 watching this list.

For reference, the bug report for this item is:
http://sourceforge.net/tracker/?func=3Ddetail&aid=3D1013350&group_id=3D6121&atid=3D1=
06121

--
Dan Kamins

Re: [Phpwiki-talk] PCRE Crash in virgin setup (pgsrc files)

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

Dan Kamins schrieb:
> On Sun, 22 Aug 2004 14:24:43 +0200, Reini Urban wrote:
>>Dan Kamins schrieb:
>>
>>>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 (
>>>http://sourceforge.net/tracker/?func=detail&aid=1013350&group_id=6121&
>>>atid=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 setup):
>>>
>>>$pat = "/\A((?:.|\n)*?)(^(?:[ \t]+\S(?:.*\s*\n[ \t]+\S)*|".
>>>"\|(?:.*\n\|)*|[#*;]*(?:[*#]|;.*?:)|\[\s*(\d+)\s*\]|".
>>>"<\?plugin(?:-form)?\b.*\?>\s*$|!{1,3}[^!]).*$)\n?/m"; $subj =
>>>str_repeat("123456789 ", 50); preg_match($pat, $subj);
>>
>>yes, this is a known issue.
>>cause still unknown. happens only with huge anchored regex.
>>
>>please remove pgsrc/OldTextFormattingRules on virgin setup.
>>
> 
> 
> Well I removed that file and got the crash on another file instead.
I'm sure if I remove THAT file, then it will crash on either another one
of the pgsrc files or one of my users' pages. Basically it's not
useable, and I can't really grok that regexp enough to do anything about
it (like splitting it up into multiple passes with smaller expressions
or something...).

There are two other oldmarkup files known to crash, yes.

> Guys, the app looks great, and I hope you keep up the good work. If
you could post (reply to this) to this mailing list when you fix this
particular bug, I'm sure I (and whoever else finds this thread) will be
excited to get back on the bandwagon. If there's anything I can do to
help for now, let me know. Otherwise I'll be waiting on the sidelines
and watching this list.

If the ConvertOldMarkup() bug will be fixed, the new release will be 
announced. The other issue (large pagelist sets) has a long history on 
sf.net, and only affects huge wikidb's with complied in memory-limit. 
And can easily be worked around with a default limit in AllPages (aka 
"Paging").

lib/upgrade.php and lib/install.php (autoinstaller) need some minor 
tweaks also.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/