From: Jeff D. <da...@da...> - 2002-02-24 02:03:58
|
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...) |
From: Carsten K. <car...@ma...> - 2002-02-24 02:34:22
|
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...) |
From: Jeff D. <da...@da...> - 2002-02-24 17:34:31
|
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...) |
From: Reini U. <ru...@x-...> - 2002-02-24 18:59:30
|
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/ |
From: Carsten K. <car...@ma...> - 2002-02-27 00:31:24
|
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...) > |
From: Jeff D. <da...@da...> - 2002-02-27 02:16:42
|
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... |
From: John K. <jo...@ke...> - 2002-02-27 09:32:56
|
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: jo...@ke... phone: 07944 755613 web: www.kershaw.org AOL: johnkershaw --------------------------------------------------------- |
From: Lawrence A. <la...@us...> - 2002-02-27 09:47:20
|
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 :-) |
From: <ph...@de...> - 2002-02-28 00:20:56
|
On Tue, 26 Feb 2002 18:16:37 -0800 (PST), "Jeff Dairiki" <da...@da...> 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 |
From: Steve W. <sw...@pa...> - 2002-02-28 15:40:47
|
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 ph...@de... wrote: > On Tue, 26 Feb 2002 18:16:37 -0800 (PST), "Jeff Dairiki" > <da...@da...> 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 > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > > > > |
From: Lawrence A. <la...@us...> - 2002-02-27 09:45:56
|
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 |