PhpWiki

Hi Jeff,

I based this on the most recent function I could think of that is used by 
PhpWiki, I think it's array_search() but I haven't created a list of all 
the functions used. The PHP online docs say this one needs PHP 4.0.5 or 
greater. What's the pl designation in your version, is that a beta?

Do you know if there is a table somewhere which lists what version of php 
all the various functions were introduced? (so that one doesn't have to 
look at all the individual function pages).

Carsten

On Saturday, February 23, 2002, at 09:03  pm, Jeff Dairiki wrote:

> Carsten Klapp said:
>> Update of /cvsroot/phpwiki/phpwiki
>> In directory usw-pr-cvs1:/tmp/cvs-serv22514
>>
>> Modified Files:
>> 	INSTALL
>> Log Message:
>> Required PHP version 4.0.5, updated instructions for new RawHTML plugin
>
> Why are we requiring 4.0.5?  I use 4.0.4pl1.  I'm sure lots of others
> do too.  (It's what RedHat, and others distributions distribute.)
> (Keep in mind, too, that many people don't have complete control over
> their web-servers.  Up until recently the SourceForge project servers
> were running 4.0.4pl1, I think...)

My point is, that we need to decide what versions of PHP we are going
to support (I thought we already had).  Then, if PhpWiki uses functions
which aren't available in a "supported" version of PHP (without providing
appropriate fallbacks or replacements), it is, by definition, a bug
in PhpWiki.

Of course, it's allowable to change the list of supported PHP versions,
(e.g. PhpWiki 1.2 runs under PHP 3, PhpWiki 1.3 doesn't) but that
shouldn't be done without a fair amount of deliberation.



Carsten Klapp said:
>
> Hi Jeff,
>
> I based this on the most recent function I could think of that is used
> by  PhpWiki, I think it's array_search() but I haven't created a list
> of all  the functions used. The PHP online docs say this one needs PHP
> 4.0.5 or  greater. What's the pl designation in your version, is that a
> beta?
>
> Do you know if there is a table somewhere which lists what version of
> php  all the various functions were introduced? (so that one doesn't
> have to  look at all the individual function pages).
>
> Carsten
>
> On Saturday, February 23, 2002, at 09:03  pm, Jeff Dairiki wrote:
>
>> Carsten Klapp said:
>>> Update of /cvsroot/phpwiki/phpwiki
>>> In directory usw-pr-cvs1:/tmp/cvs-serv22514
>>>
>>> Modified Files:
>>> 	INSTALL
>>> Log Message:
>>> Required PHP version 4.0.5, updated instructions for new RawHTML
>>> plugin
>>
>> Why are we requiring 4.0.5?  I use 4.0.4pl1.  I'm sure lots of others
>> do too.  (It's what RedHat, and others distributions distribute.)
>> (Keep in mind, too, that many people don't have complete control over
>> their web-servers.  Up until recently the SourceForge project servers
>> were running 4.0.4pl1, I think...)

Jeff Dairiki schrieb:
> My point is, that we need to decide what versions of PHP we are going
> to support (I thought we already had).  Then, if PhpWiki uses functions
> which aren't available in a "supported" version of PHP (without providing
> appropriate fallbacks or replacements), it is, by definition, a bug
> in PhpWiki.
> 
> Of course, it's allowable to change the list of supported PHP versions,
> (e.g. PhpWiki 1.2 runs under PHP 3, PhpWiki 1.3 doesn't) but that
> shouldn't be done without a fair amount of deliberation.

imho we don't need any table of supported functions. the manual tells us all, 
and if a function is not supported we can dynamically query for that.
I would like to see php3 also supported. php-4.0.4pl1 is imho the most used
version.

array_search is not that hard to implement. below are some php3 workarounds I
often use.

  function my_array_push ($array, $new_element) {
    if (function_exists('array_push')) {
      array_push($array,$new_element);
    } else {
      $array[] = $new_element;
    }
    return $array;
  }

  function my_in_array($lookup_value, $lookup_array) {
    if (function_exists('in_array')) {
      if (in_array($lookup_value, $lookup_array)) return true;
    } else {
      reset($lookup_array);
      while (list($key, $value) = each($lookup_array)) {
        if ($value == $lookup_value) return true;
      }
    }

    return false;
  }

////
// returns position of found value in indexed array
  function my_array_position ($array, $value, $case_insensitive = false) {
    if (!is_array($array)) return false;
    for ($i=0; $i < count($array); $i++) {
      if ($array[$i] === $value) return $i;
      if (is_string($value)) {
	if ($case_insensitive) {
	  if (strcasecmp($array[$i], $value) === 0) return $i;
	} else {
	  if (strcmp($array[$i], $value) === 0) return $i;
	}
      }
    }
    return false;
  }

BTW: phpwiki fails on safe_mode on.
plugins cannot be executed without proper 
php_admin_value open_basedir settings.


> Carsten Klapp said:
> > I based this on the most recent function I could think of that is used
> > by  PhpWiki, I think it's array_search() but I haven't created a list
> > of all  the functions used. The PHP online docs say this one needs PHP
> > 4.0.5 or  greater. What's the pl designation in your version, is that a
> > beta?
> >
> > Do you know if there is a table somewhere which lists what version of
> > php  all the various functions were introduced? (so that one doesn't
> > have to  look at all the individual function pages).
> >
> > Carsten
> >
> > On Saturday, February 23, 2002, at 09:03  pm, Jeff Dairiki wrote:
> >
> >> Carsten Klapp said:
> >>> Update of /cvsroot/phpwiki/phpwiki
> >>> In directory usw-pr-cvs1:/tmp/cvs-serv22514
> >>>
> >>> Modified Files:
> >>>     INSTALL
> >>> Log Message:
> >>> Required PHP version 4.0.5, updated instructions for new RawHTML
> >>> plugin
> >>
> >> Why are we requiring 4.0.5?  I use 4.0.4pl1.  I'm sure lots of others
> >> do too.  (It's what RedHat, and others distributions distribute.)
> >> (Keep in mind, too, that many people don't have complete control over
> >> their web-servers.  Up until recently the SourceForge project servers
> >> were running 4.0.4pl1, I think...)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Jeff,

Very well put, I understand now and agree with your point, that PhpWiki 
should generally strive to support a particular version of PHP and stick 
with it, until in the future it might be agreed that a higher version of 
PHP is needed.

I have some questions for you and the group about how to proceed from here.
..

The INSTALL docs I can change back to:

  PhpWiki requires a web server with PHP version 4.0.? or greater and a
  database application.

(Fill in the decided upon version number above) and change the version 
number in the next line from 4.0.5 to:

  (PhpWiki uses the array_search() function which is present only in PHP
  version php-4.0.4pl1 or greater.)

Up until now I hadn't been giving any consideration to which version of 
PHP a function was available in, except perhaps
that it is available in PHP 4.x.x. So far I only recall the one function I 
added in, array_search(), which apparently is only available in 4.0.4pl1 ? 
and Reini has given some handy substitute functions so this can easily be 
changed to work with older versions of PHP.

Whenever this situation arises in the future, should we put the workaround 
functions somewhere globally accessible like stdlib? or start a new 
library file only containing these functions? (and then call them if 
!function_exists('funcname') ?)

 From browsing around the PHP web site a bit, I think I figured out that 
php-4.0.4pl1 is a CVS version of PHP before the final release of 4.0.4. 
The online documentation doesn't always list in which CVS version of PHP a 
function was added, usually just the full release version number as is the 
case with the example array_search(). (The docs for call_user_func_array 
is one I found which *does* mention a pl version number http://www.php.net/
manual/en/html/function.call-user-func-array.html). At least I haven't 
found any such online reference yet for which functions were added in any 
pl version.

When SF was running the older version of PHP it probably would have been 
almost immediately evident when a new function was added which broke it. 
So now that SF is running PHP/4.0.6 do we just wait until somebody 
complains ;-) that a new function broke their PhpWiki running PHP-plxxx?

I'm sure there are a lot of stable CVS variations of PHP different people 
could be using, how to decide which version is PhpWiki going to support? 
If it will help us, I am willing to to some "monkey" work, examine each 
function currently used in PhpWiki then visit each function page in the 
PHP docs to determine the necessary PHP version. Someone else with 
experience using non-release "pl" builds would have to fill in the blanks 
where the pl version is not available.

Carsten

On Sunday, February 24, 2002, at 12:34  pm, Jeff Dairiki wrote:

> My point is, that we need to decide what versions of PHP we are going
> to support (I thought we already had).  Then, if PhpWiki uses functions
> which aren't available in a "supported" version of PHP (without providing
> appropriate fallbacks or replacements), it is, by definition, a bug
> in PhpWiki.
>
> Of course, it's allowable to change the list of supported PHP versions,
> (e.g. PhpWiki 1.2 runs under PHP 3, PhpWiki 1.3 doesn't) but that
> shouldn't be done without a fair amount of deliberation.
>
>
>
> Carsten Klapp said:
>>
>> Hi Jeff,
>>
>> I based this on the most recent function I could think of that is used
>> by  PhpWiki, I think it's array_search() but I haven't created a list
>> of all  the functions used. The PHP online docs say this one needs PHP
>> 4.0.5 or  greater. What's the pl designation in your version, is that a
>> beta?
>>
>> Do you know if there is a table somewhere which lists what version of
>> php  all the various functions were introduced? (so that one doesn't
>> have to  look at all the individual function pages).
>>
>> Carsten
>>
>> On Saturday, February 23, 2002, at 09:03  pm, Jeff Dairiki wrote:
>>
>>> Carsten Klapp said:
>>>> Update of /cvsroot/phpwiki/phpwiki
>>>> In directory usw-pr-cvs1:/tmp/cvs-serv22514
>>>>
>>>> Modified Files:
>>>> 	INSTALL
>>>> Log Message:
>>>> Required PHP version 4.0.5, updated instructions for new RawHTML
>>>> plugin
>>>
>>> Why are we requiring 4.0.5?  I use 4.0.4pl1.  I'm sure lots of others
>>> do too.  (It's what RedHat, and others distributions distribute.)
>>> (Keep in mind, too, that many people don't have complete control over
>>> their web-servers.  Up until recently the SourceForge project servers
>>> were running 4.0.4pl1, I think...)
>

Carsten Klapp said:

> The INSTALL docs I can change back to:

>  PhpWiki requires a web server with PHP version 4.0.? or greater and a
>  database application.

I think 4.0.4pl1 was the unspoken standard, and would be fine.  As
Reini says, it's in quite common use.  IIRC, it's the first version
of PHP 4 which didn't have big bugs.  (BTW, 4.0.4pl1 came after 4.0.4.
"pl" stands for "patch level", I think.  It's a ("doh!") stupid
bug-fix release, I think.)

> Whenever this situation arises in the future, should we put the
> workaround  functions somewhere globally accessible like stdlib?
> or start a new  library file only containing these functions? (and then
> call them if  !function_exists('funcname') ?)

I think stdlib.  As long as it's not too painful to implement a full
replacement for a particular function, I think we can just do:

if (!function_exists('func_x')) {
   function func_x () {
       ... our replacement ...
   }
}

Though when the need for such a replacement arises, one should first
consider if one can do the job adequately without using the function
in question at all.

Mostly, I would say, don't sweat it too much.  When you use a new
function, check the PHP docs (which you probably need to do anyway,
since it's a new function); if it says, e.g., "(PHP4 >= 4.0.5)",
then consider whether you can do the job some other way (in PHP,
as in Perl there are often about a zillion ways to do any
particular task), or provide a replacement.

If some newer functions slip in unoticed, someone will complain
eventually, and we can address the problem then.

Also note that (just to keep you on your toes) function semantics
often change from PHP release to PHP release.  (E.g. "In PHP 4.0.5
and later, every parameter to str_replace() can be an array.")

My main point is that we need to decide what version we will support,
and stick by it...

Hi,

Quite often people arrive at my site then, after clicking a link, 
find they've got &PHPSESSID=blahblahblah tagged to the end of their 
URL. This then screws up the next link they click, so clicking the 
wikiword:

BurleyGreenWall

takes them to the page

BurleyGreenWall& (or BurleyGreenWall%26)

which of course doesn't exist, and causes them to wonder what went wrong.

What's causing this and how do I stop it?

John.
-- 

---------------------------------------------------------
email:  john@...         phone:      07944 755613
web:     http://www.kershaw.org    AOL: johnkershaw
---------------------------------------------------------

Carsten,

I think the pl versions were released as patches - pl stands for patch 
level.  Sometimes significant things happened in the patches.  I thing, for 
example, that "include_once " came out with 4.01pl2

Lawrence

At 00:31 27/02/2002, you wrote:

>Jeff,
>
>Very well put, I understand now and agree with your point, that PhpWiki 
>should generally strive to support a particular version of PHP and stick 
>with it, until in the future it might be agreed that a higher version of 
>PHP is needed.
>
>I have some questions for you and the group about how to proceed from here.
>..
>
>The INSTALL docs I can change back to:
>
>  PhpWiki requires a web server with PHP version 4.0.? or greater and a
>  database application.
>
>(Fill in the decided upon version number above) and change the version 
>number in the next line from 4.0.5 to:
>
>  (PhpWiki uses the array_search() function which is present only in PHP
>  version php-4.0.4pl1 or greater.)
>
>Up until now I hadn't been giving any consideration to which version of 
>PHP a function was available in, except perhaps
>that it is available in PHP 4.x.x. So far I only recall the one function I 
>added in, array_search(), which apparently is only available in 4.0.4pl1 ? 
>and Reini has given some handy substitute functions so this can easily be 
>changed to work with older versions of PHP.
>
>Whenever this situation arises in the future, should we put the workaround 
>functions somewhere globally accessible like stdlib? or start a new 
>library file only containing these functions? (and then call them if 
>!function_exists('funcname') ?)
>
> From browsing around the PHP web site a bit, I think I figured out that 
> php-4.0.4pl1 is a CVS version of PHP before the final release of 4.0.4. 
> The online documentation doesn't always list in which CVS version of PHP 
> a function was added, usually just the full release version number as is 
> the case with the example array_search(). (The docs for 
> call_user_func_array is one I found which *does* mention a pl version 
> number http://www.php.net/
>manual/en/html/function.call-user-func-array.html). At least I haven't 
>found any such online reference yet for which functions were added in any 
>pl version.
>
>When SF was running the older version of PHP it probably would have been 
>almost immediately evident when a new function was added which broke it. 
>So now that SF is running PHP/4.0.6 do we just wait until somebody 
>complains ;-) that a new function broke their PhpWiki running PHP-plxxx?
>
>I'm sure there are a lot of stable CVS variations of PHP different people 
>could be using, how to decide which version is PhpWiki going to support? 
>If it will help us, I am willing to to some "monkey" work, examine each 
>function currently used in PhpWiki then visit each function page in the 
>PHP docs to determine the necessary PHP version. Someone else with 
>experience using non-release "pl" builds would have to fill in the blanks 
>where the pl version is not available.
>
>Carsten

At 02:16 27/02/2002, you wrote:

>I think 4.0.4pl1 was the unspoken standard


Ah - that'll be why I never heard that it was the standard then :-)

On Tue, 26 Feb 2002 18:16:37 -0800 (PST), "Jeff Dairiki"
<dairiki@...> wrote:
=> I think 4.0.4pl1 was the unspoken standard, and would be fine.  As
=> Reini says, it's in quite common use.  IIRC, it's the first version
=> of PHP 4 which didn't have big bugs.  (BTW, 4.0.4pl1 came after 4.0.4.
=> "pl" stands for "patch level", I think.  It's a ("doh!") stupid
=> bug-fix release, I think.)

You had to tempt fate, didn't you?  <grin>

PHP 4.1.2 was released today because almost all previous PHP
versions have a security flaw related to the mime upload type,
which may allow a remote attacker to execute arbitrary code. It
appears this would afect PHP installed at a CGI in addition to
the PHP module for Apache.

More info:
http://security.e-matters.de/advisories/012002.html
http://www.php.net/

	HTH,

	- Don

Most unfortunate... I've becomee a recent convert to the school of 
"wikis need file uploads." We are using Twiki here at my new job (about 
which I'll write more some day), and the ability to attach Word or Visio 
docs to a page is very useful.

~swain

phpwiki@... wrote:
> On Tue, 26 Feb 2002 18:16:37 -0800 (PST), "Jeff Dairiki"
> <dairiki@...> wrote:
> => I think 4.0.4pl1 was the unspoken standard, and would be fine.  As
> => Reini says, it's in quite common use.  IIRC, it's the first version
> => of PHP 4 which didn't have big bugs.  (BTW, 4.0.4pl1 came after 4.0.4.
> => "pl" stands for "patch level", I think.  It's a ("doh!") stupid
> => bug-fix release, I think.)
> 
> You had to tempt fate, didn't you?  <grin>
> 
> PHP 4.1.2 was released today because almost all previous PHP
> versions have a security flaw related to the mime upload type,
> which may allow a remote attacker to execute arbitrary code. It
> appears this would afect PHP installed at a CGI in addition to
> the PHP module for Apache.
> 
> More info:
> http://security.e-matters.de/advisories/012002.html
> http://www.php.net/
> 
> 	HTH,
> 
> 	- Don
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Phpwiki-talk@...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 
> 
> 
>