phpwiki-talk

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki INSTALL,1.15,1.16

[Lawrence A. <la...@us...>]

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 :-)

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki INSTALL,1.15,1.16

[Lawrence A. <la...@us...>]

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

[Phpwiki-talk] PHPSESSID woes

[John K. <jo...@ke...>]

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

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki INSTALL,1.15,1.16

[Jeff D. <da...@da...>]

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...

Re: [Phpwiki-talk] Upgrading from 1.2 to 1.3

[Carsten K. <car...@ma...>]

If your wiki isn't too big you could unzip it and delete the old action 
pages, then load the pages from the directory instead of the zip. Other 
than loading the pages in the order you describe and taking particular 
attention of which pages might be overwritten there's no easy solution.

There has been some talk of a new pgsrc version number scheme which could 
be used in the future to help in this situation, but there is no code for 
it as of yet.

Carsten

On Tuesday, February 26, 2002, at 06:57  pm, Malcolm Ross Kinsella Ryan 
wrote:

> Hi all,
>
> I've just done a trial upgrade for my NomicWiki from PhpWiki 1.2.2 to 1.3.
> 3.
> There was only one hassle: loading the new standard pages. At first I 
> tried
> loading the new wiki directly from the wiki.zip file (rather than from
> pgsrc) but this meant that a significant number of things were broken as
> a number of "action pages" were missing.
>
> I then loaded the files from pgsrc over the top. This overwrote the 
> HomePage.
> Fortunately this isn't a problem for me, as I don't use "HomePage" as my
> home page, but it could be a problem for others upgrading.
>
> If I did it in the opposite order there would be more problems. Loading
> the wiki.zip from the old wiki over the top of the 1.3.3 pages would mean
> that the old TextFormattingRules and similar pages would overwrite the 
> new.
>
> Is there a good solution to this?
>
> Malcolm
>
> --
> Malcolm Ryan - mal...@cs... - 
> http://www.cse.unsw.edu.au/~malcolmr/
>   AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 
> 9385-4936
>
>            "He causes his sun to rise on the evil and the good,
>            and sends rain on the righteous and the unrighteous." - Matt 5:
> 45

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki INSTALL,1.15,1.16

[Carsten K. <car...@ma...>]

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...)
>

[Phpwiki-talk] Upgrading from 1.2 to 1.3

[<mal...@cs...>]

Hi all,

I've just done a trial upgrade for my NomicWiki from PhpWiki 1.2.2 to 1.3.3.
There was only one hassle: loading the new standard pages. At first I tried
loading the new wiki directly from the wiki.zip file (rather than from
pgsrc) but this meant that a significant number of things were broken as
a number of "action pages" were missing. 

I then loaded the files from pgsrc over the top. This overwrote the HomePage.
Fortunately this isn't a problem for me, as I don't use "HomePage" as my
home page, but it could be a problem for others upgrading.

If I did it in the opposite order there would be more problems. Loading 
the wiki.zip from the old wiki over the top of the 1.3.3 pages would mean
that the old TextFormattingRules and similar pages would overwrite the new.

Is there a good solution to this?

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/
  AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-4936

           "He causes his sun to rise on the evil and the good,
           and sends rain on the righteous and the unrighteous." - Matt 5:45

Re: [Phpwiki-talk] removing index.php from phpwiki url's at SourceFroge ..

[Steve W. <sw...@pa...>]

Ha! I was looking for FAQ, not Fr*Ask*Que*. :-)

~swain

Lawrence Akka wrote:
> We do.  It must have slipped your mind!
> 
> http://phpwiki.sourceforge.net/phpwiki/FrequentlyAskedQuestions
> 
> 
> 
> At 14:59 26/02/2002, Steve Wainstead wrote:
> 
>> Definitely another one for the FAQ. If we had a FAQ! High time to 
>> start one! The first question should deal with the missing dba_open() 
>> function.
>>
>> ~swain
>>
>> Geoff Eldridge wrote:
>>
>>> I am a new php and phpwiki user of about 30 minutes ..
>>> I have installed phpwiki-1.3.3.tar.gz on sourceforge:
>>>    http://elj.sourceforge.net/phpwiki/index.php/HomePage
>>> I am trying to work out how to make this url:
>>>    http://elj.sourceforge.net/phpwiki/
>>>    -- I notice the the phpwiki page works like this:
>>>    --     http://phpwiki.sourceforge.net/phpwiki/
>>> The current page for this url details ``Loading up virgin wiki''
>>> --8<--
>>> Loading up virgin wiki
>>> AddingPages from MIME file ./pgsrc/AddingPages new page - saved to 
>>> database as version .
>>> -->8--
>>> Is there some setting in the index.php file that I need to make to 
>>> obtain
>>> the desired behaviour?  Or is it some kind of admin setup with the elj
>>> soruceforge account?
>>> Also I would like to provide a SourceForge link at the top or bottom of
>>> each phpwiki page:
>>> --8<--
>>> <a href="http://sourceforge.net">
>>> <img src="http://sourceforge.net/sflogo.php?group_id=45427"
>>> width="88" height="31" border="0"
>>> alt="elj hosted and supported by SourceForge">
>>> </a>
>>> -->8--
>>> Could someone quickily indicate to me where this might be done.
>>> Thanks for phpwiki, it is a great package which is much deserving of its
>>> high SourceForge ranking.
>>> Thanks .. Geoff Eldridge
>>> -- ge...@el...
>>> -- http://elj.sf.net/
>>>
>>> _______________________________________________
>>> Phpwiki-talk mailing list
>>> Php...@li...
>>> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>>>
>>
>>
>>
>> _______________________________________________
>> Phpwiki-talk mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 
> 
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 
> 
> 

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib Theme.php,1.43,1.44

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

Lawrence Akka schrieb:
> Workaround absence of %e date format specifier in Windows strftime function.
> See code for comments
> +    // As a result, we have to use %d, and strip out leading zeros ourselves.
> +
> +    var $_dateFormat = "%B %d, %Y";
>      var $_timeFormat = "%I:%M %p";

I would really prefer %x and %X because these are the recommended local
settings.
so one doesn't have to fix this for his locale.

themes/*/themeinfo.php:
$Theme->setDateFormat("%x");
$Theme->setTimeFormat("%X");

lib/Themes.lib:
    //var $_dateFormat = "%B %d, %Y";
    //var $_timeFormat = "%I:%M %p";
    $_dateFormat = "%x";
    $_timeFormat = "%X";

docs:
%x - preferred date representation for the current locale without the time 
%X - preferred time representation for the current locale without the date 

these do work in windows.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] phpWiki patch - concurrent updates

[Marcel v. d. B. <ma...@hs...>]

That would indeed solve most of the problems.  Even the more complex 
problems somewhere in the middle of my initial comments.

As the situation has occurs I'll post our experiences.

Thanks guys.

Marcel


Jeff Dairiki wrote:

>Marcel van der Boom said:
>
>>But (at least in the PN module version) the instructions of the
>>error message are wrong. When hitting the back button, the page is
>>retrieved from the db again, so the last changes are lost. (maybe that
>>is the error).
>>
>
>Yes.  That's a function of the cache-control HTTP headers sent by
>PHP.  This started happening when we starting using PHP's session
>support.  It's now been fixed (in the main PhpWiki CVS) by doing
>a
>
>  session_cache_limit('none');
>
>before the first call to any other session handling functions.
>
>
>
>Also note that (though I haven't played with it yet, so I might
>have details wrong) Lawrence has added "merge conflicting edits"
>functionality to the latest CVS version of PhpWiki:  If you try
>to save your edits, when there has been an intervening save by
>another user, you get returned to the edit form, but the text in
>the edit form will contain the latest changes merged with your
>changes.  You can simply hit "save" again to save the merged
>version, if that's what you want.
>
>I think that ought to solve most problems arising from
>simultaneous edits...
>
>
>
>

-- 
Marcel van der Boom
HS-Development BV
Kwartiersedijk 14B
Fijnaart, The Netherlands
Tel. : 0168-468822
Fax. : 0168-468823
Email: ma...@hs...

Re: [Phpwiki-talk] phpWiki patch - concurrent updates

[Jeff D. <da...@da...>]

Marcel van der Boom said:

> But (at least in the PN module version) the instructions of the
> error message are wrong. When hitting the back button, the page is
> retrieved from the db again, so the last changes are lost. (maybe that
> is the error).

Yes.  That's a function of the cache-control HTTP headers sent by
PHP.  This started happening when we starting using PHP's session
support.  It's now been fixed (in the main PhpWiki CVS) by doing
a

  session_cache_limit('none');

before the first call to any other session handling functions.



Also note that (though I haven't played with it yet, so I might
have details wrong) Lawrence has added "merge conflicting edits"
functionality to the latest CVS version of PhpWiki:  If you try
to save your edits, when there has been an intervening save by
another user, you get returned to the edit form, but the text in
the edit form will contain the latest changes merged with your
changes.  You can simply hit "save" again to save the merged
version, if that's what you want.

I think that ought to solve most problems arising from
simultaneous edits...

Re: [Phpwiki-talk] phpWiki patch - concurrent updates

[Marcel v. d. B. <ma...@hs...>]

>
>
>Marcel's patch (which is reversed?)
>
Yep, it's reverse I'm sorry, too quick...

>turns
>saving a concurrent update from an error (save fails) into a warning
>(save succeeds).
>
>If that's right, it's a bad idea IMHO.  It makes it just too easy for some
>bozo to blow away somebody else's edits.
>
>If someone tries to run PhpWiki in an environment where it routinely
>sees multiple edits per minute per page, this issue is going to be
>among the least of their problems, I think.
>
- It makes it easy to create a newer revision, but no data is lost. (it 
needs extra work though when a bozo has done the editting ) The patch 
should obviously be more elegant (besides being reversed) than it is 
now. But (at least in the PN module version) the instructions of the 
error message are wrong. When hitting the back button, the page is 
retrieved from the db again, so the last changes are lost. (maybe that 
is the error).
- our Wiki isn't busy at all. The number of edits per minute is not 
really relevant, but the time elapsed between start of edit and save. We 
are creating documents in a team and especially when creating new 
documents it happens frequently that users are working on the same 
documents ( a development task list for example is quite a busy document)
Sometimes I'm testing some software and keep the edit window of a Wiki 
page open for  a longer period of time to document the results as I go 
along.  I applied the patch to our installation after loosing edits 
several times. The Wiki doesn't have to be busy at all for this. All it 
takes is one edit during the time I'm editting.
- the bozo factor is a risk in a Wiki, especially if you have a loose 
permission scheme.  We have a PostNuke permission scheme in place to 
minimize this risk.

Marcel

Re: [Phpwiki-talk] phpWiki patch - concurrent updates

[Adam S. <ad...@pe...>]

> If someone tries to run PhpWiki in an environment where it routinely
> sees multiple edits per minute per page, this issue is going to be
> among the least of their problems, I think.

and i'm not sure how much of a "real world" problem this is.  the
personal telco wiki is moderately busy:

 http://www.personaltelco.net/stats/m_usage_200201_000_001.html

and i can count on one hand the number of times i've had to backup and
merge changes by hand in over a year.

also busier sites tend to have more pages which also distributes the
edits.

i'm not saying that the comments aren't valid, if you're consistantly
seeing multiple edits a minute on a single page it would be a major pain
but that i'm not sure any wiki has ever gotten that popular. :)

adam.

Re: [Phpwiki-talk] phpWiki patch - concurrent updates

[Jeff D. <da...@da...>]

Lawrence Akka said:
> Any views from the floor?
>
> Marcel is using the PostNukeModule (in effect, phpWiki 1.3.2), but his
> comments apply generally.

If I grokked correctly, Marcel's patch (which is reversed?) turns
saving a concurrent update from an error (save fails) into a warning
(save succeeds).

If that's right, it's a bad idea IMHO.  It makes it just too easy for some
bozo to blow away somebody else's edits.

If someone tries to run PhpWiki in an environment where it routinely
sees multiple edits per minute per page, this issue is going to be
among the least of their problems, I think.

[Phpwiki-talk] phpWiki patch - concurrent updates

[Lawrence A. <la...@20...>]

Any views from the floor?

Marcel is using the PostNukeModule (in effect, phpWiki 1.3.2), but his 
comments apply generally.


>Date: Tue, 26 Feb 2002 15:28:20 +0100
>From: Marcel van der Boom <ma...@hs...>
>Organization: HS-Development BV
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) 
>Gecko/20020222
>X-Accept-Language: en-us
>To: Lawrence Akka <la...@us...>
>Subject: Re: phpWiki patch - concurrent updates
>
>Lawrence,
>
>I think I disagree. The user is indeed presented with an error now. The 
>patch turns this error effectively into a warning.  The modifications of 
>the user are saved under a new (higher than expected from the users point 
>of view) revision and the warning says that the user *should* look at the 
>diff.  This looks like the normal "flow" when editting documents, storing 
>the latest edit under the highest revision.. It is also independent of 
>users settings of caching and browser. I agree that the patch is a tempory 
>fix. The user should really be presented with a choice of:
>* merge documents
>* revert to older revision (discard edits)
>* apply my edits.
>
>During the warning it might be wise to lock the page to prevent second or 
>higher order effects to occur (see below).
>
>The code with the patch applied is still not save, or not concurrent 
>enough. As the number of concurrent edits increase, the "cumbersomeness" 
>increases as well.  With "n" edits applied *in order* the user has to look 
>at "n"diffs to decide what to do, which is not really comfortable. The 
>risk of this obviously depends on the "edit-time" and the number of users 
>working on the same document.
>This is the simplest situation. It could get worse. What happens for 
>example when multiple  edits are done when the user is reading the 
>warning?  By the time he has examined  the diff a higher version may 
>exist. This can create rather complicated sessions with cascading warnings 
>and our users will be confused the first time, let alone the second 
>time.  I guess this is a problem which really should be dealt with in a 
>broader context (if it is a problem and I'm not mistaken).
>
>For our purpose the safety net for a concurrency of 2 of the first order 
>is probably enough, but we haven't taken the phpWiki to implementations at 
>customers sites yet.
>
>Am I seeing things too complicated here?
>
>To summarize:
>The fact that the createRevision will return false is "a choice". I think 
>the call should return true and warn the user that the flow is 
>interrupted.  This applies only if phpWiki wants to allow concurrent 
>editting. Another strategy would be the locking of pagesduring an edit 
>sessions, but this is quite another discussion, and will look somewhat 
>more unfriendly.
>
>The problem, as far as I can see now, is not related to caching (at least 
>not in the PN version), but I might be wrong. I tend to choose solutions 
>which do not depend on client settings.
>
>Marcel
>
>
>>I am not sure at the moment that your patch is necessary.  If during the 
>>time that the code has been executing another user has edited and saved 
>>the page,  the call to $page->createRevision($editversion + 1 ....  will 
>>return false.  The createRevision function will not be able to create the 
>>desired revision, because there will exist a revision with a later 
>>version number.  Accordingly, if (!is_object($newrevision)) ... is true 
>>and an error is reported to the user.
>>
>>Let me know if you disagree
>>
>>Lawrence
>>
>>At 13:25 26/02/2002, you wrote:
>>
>>>Lawrence,
>>>
>>>>This might be something to do with caching problems in the 
>>>>browser.  phpWiki 1.3.2 merges conflicting edits (in a similar way to 
>>>>cvs), and gives the user the chance to edit the merged result before saving.
>>>I checked to savepage.php file and noticed that it is assumed that the 
>>>editted version is still the current version, which is in this case wrong.
>>>
>>>I've included a little patch for this. As I'm (yet) unfamiliar with the 
>>>phpWiki code and didn't know if this was PostNuke related I thought I 
>>>send the patch first to you.  If you want me to take other actions, let 
>>>me know.  The change is almost to small to apply the patch file but if 
>>>you want it let me know what your groups standard cmdline for diff is 
>>>and i'll send it to you.
>>>
>>>Cheers,
>>>Marcel
>>>
>>>--- ./savepage.php      Tue Feb 26 14:20:54 2002
>>>
>>>+++ /home/httpd/hsd/modules/phpWiki/lib/savepage.php    Tue Nov 27 
>>>11:29:02 2001
>>>@@ -129,10 +129,7 @@
>>>
>>>
>>>//
>>>
>>>    // From here on, we're actually saving.
>>>
>>>
>>>//
>>>
>>>-    // Don't assume we're still editting the current revision
>>>
>>>-    // This section is now critical (in terms of concurrency)
>>>
>>>-    $currentversion = $current->getVersion();
>>>
>>>-    $newrevision = $page->createRevision($currentversion + 1,
>>>+    $newrevision = $page->createRevision($editversion + 1,
>>>
>>>                                         $content, $meta,
>>>
>>>
>>>ExtractWikiPageLinks($content));
>>>
>>>    if (!is_object($newrevision)) {
>>>
>>>@@ -145,13 +142,6 @@
>>>
>>>
>>>$cleaner->cleanPageRevisions($page);
>>>
>>>
>>>
>>>
>>>    $warnings = $dbi->GenericWarnings();
>>>
>>>-
>>>
>>>-    // Have we skipped a revision?
>>>
>>>-    if(($currentversion > $editversion)){
>>>
>>>-       // Somehow an intermediate revision was created warn user
>>>-       $warnings ="While you were editting another revision was 
>>>created. You might want to check a diff between your revision and the
>>>previous one";
>>>
>>>-
>>>}
>>>
>>>-
>>>
>>>    if (empty($warnings)) {
>>>
>>>        // Do redirect to browse page.
>>>
>>>        // In this case, the user will most likely not see the rest of
>>>@@ -165,7 +155,6 @@
>>>
>>>    $html .= gettext ("Your careful attention to detail is much 
>>> appreciated.");
>>>    $html .= "\n";
>>>
>>>
>>>
>>>
>>>-
>>>
>>>    if ($warnings) {
>>>
>>>        $html .= Element('p', "<b>Warning!</b> "
>>>
>>>                         . htmlspecialchars($warnings)
>>>
>>>--
>>>Marcel van der Boom
>>>HS-Development BV
>>>Kwartiersedijk 14B
>>>Fijnaart, The Netherlands
>>>Tel. : 0168-468822
>>>Fax. : 0168-468823
>>>Email: ma...@hs...
>>>
>>>
>>
>
>--
>Marcel van der Boom
>HS-Development BV
>Kwartiersedijk 14B
>Fijnaart, The Netherlands
>Tel. : 0168-468822
>Fax. : 0168-468823
>Email: ma...@hs...
>
>
>


==========NOTICE==========
Internet e-mail is not necessarily secure or reliable.  Please let us know if you would like to establish a secure channel of communication.
This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.
Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.
Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...

Re: [Phpwiki-talk] removing index.php from phpwiki url's at SourceFroge ..

[Lawrence A. <la...@us...>]

We do.  It must have slipped your mind!

http://phpwiki.sourceforge.net/phpwiki/FrequentlyAskedQuestions



At 14:59 26/02/2002, Steve Wainstead wrote:
>Definitely another one for the FAQ. If we had a FAQ! High time to start 
>one! The first question should deal with the missing dba_open() function.
>
>~swain
>
>Geoff Eldridge wrote:
>>I am a new php and phpwiki user of about 30 minutes ..
>>I have installed phpwiki-1.3.3.tar.gz on sourceforge:
>>    http://elj.sourceforge.net/phpwiki/index.php/HomePage
>>I am trying to work out how to make this url:
>>    http://elj.sourceforge.net/phpwiki/
>>    -- I notice the the phpwiki page works like this:
>>    --     http://phpwiki.sourceforge.net/phpwiki/
>>The current page for this url details ``Loading up virgin wiki''
>>--8<--
>>Loading up virgin wiki
>>AddingPages from MIME file ./pgsrc/AddingPages new page - saved to 
>>database as version .
>>-->8--
>>Is there some setting in the index.php file that I need to make to obtain
>>the desired behaviour?  Or is it some kind of admin setup with the elj
>>soruceforge account?
>>Also I would like to provide a SourceForge link at the top or bottom of
>>each phpwiki page:
>>--8<--
>><a href="http://sourceforge.net">
>><img src="http://sourceforge.net/sflogo.php?group_id=45427"
>>width="88" height="31" border="0"
>>alt="elj hosted and supported by SourceForge">
>></a>
>>-->8--
>>Could someone quickily indicate to me where this might be done.
>>Thanks for phpwiki, it is a great package which is much deserving of its
>>high SourceForge ranking.
>>Thanks .. Geoff Eldridge
>>-- ge...@el...
>>-- http://elj.sf.net/
>>
>>_______________________________________________
>>Phpwiki-talk mailing list
>>Php...@li...
>>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>>
>
>
>
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] removing index.php from phpwiki url's at SourceFroge ..

[Steve W. <sw...@pa...>]

Definitely another one for the FAQ. If we had a FAQ! High time to start 
one! The first question should deal with the missing dba_open() function.

~swain

Geoff Eldridge wrote:
> I am a new php and phpwiki user of about 30 minutes ..
> 
> I have installed phpwiki-1.3.3.tar.gz on sourceforge:
> 
>    http://elj.sourceforge.net/phpwiki/index.php/HomePage
> 
> I am trying to work out how to make this url:
> 
>    http://elj.sourceforge.net/phpwiki/
> 
>    -- I notice the the phpwiki page works like this:
>    --     http://phpwiki.sourceforge.net/phpwiki/
> 
> The current page for this url details ``Loading up virgin wiki''
> 
> --8<--
> Loading up virgin wiki
> AddingPages 
> from MIME file ./pgsrc/AddingPages new page - saved to database as version 
> .
> 
> -->8--
> 
> Is there some setting in the index.php file that I need to make to obtain
> the desired behaviour?  Or is it some kind of admin setup with the elj
> soruceforge account?
> 
> Also I would like to provide a SourceForge link at the top or bottom of
> each phpwiki page:
> 
> --8<--
> <a href="http://sourceforge.net">
> <img src="http://sourceforge.net/sflogo.php?group_id=45427"
> width="88" height="31" border="0"
> alt="elj hosted and supported by SourceForge">
> </a>
> -->8--
> 
> Could someone quickily indicate to me where this might be done.
> 
> Thanks for phpwiki, it is a great package which is much deserving of its
> high SourceForge ranking.
> 
> Thanks .. Geoff Eldridge
> 
> -- ge...@el...
> -- http://elj.sf.net/
> 
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 
> 
> 
> 

Fwd: Re: [Phpwiki-talk] removing index.php from phpwiki url's at SourceFroge ..

[Lawrence A. <la...@us...>]

>Date: Tue, 26 Feb 2002 21:04:35 +1100 (EST)
>From: Geoff Eldridge <gel...@pr...>
>To: Lawrence Akka <la...@us...>
>Subject: Re: [Phpwiki-talk] removing index.php from phpwiki url's at
>  SourceFroge ..
>
>On Tue, 26 Feb 2002, Lawrence Akka wrote:
>
> > Looks like youv'e figured it out Geoff!
> >
> > If you need any more help, just ask.
>
>Yes, I managed to find where the templates were and add in the sourceforge
>logo and link into the area where phpwiki puts its own logo.
>
>The top level  link is working as expected now:
>
>    http://elj.sourceforge.net/phpwiki/
>
>However lower level links still require the index.php made expliicit:
>
>    http://elj.sourceforge.net/phpwiki/index.php/MostPopular
>
>If I try:
>
>    http://elj.sourceforge.net/phpwiki/MostPopular
>
>I get the following error message:
>
>--8<--
>Not Found
>The requested URL /phpwiki/MostPopular was not found on this server.
>---------------------------------------------------------------------------
>Apache/1.3.20 Server at elj.sourceforge.net Port 80
>-->8--
>
>For your project you can use the short form:
>
>    http://phpwiki.sourceforge.net/phpwiki/MostPopular
>
>and get the expected behaviour. Is there something in the index.php (or
>related file) I need to modify.
>
>Thanks .. Geoff
>
>PS _ thanks for modifyng the format on the SmallEIffel page ..
>
>-- ge...@el...
>-- http://elj.sf.net/

[Phpwiki-talk] removing index.php from phpwiki url's at SourceFroge ..

[Geoff E. <gel...@pr...>]

I am a new php and phpwiki user of about 30 minutes ..

I have installed phpwiki-1.3.3.tar.gz on sourceforge:

   http://elj.sourceforge.net/phpwiki/index.php/HomePage

I am trying to work out how to make this url:

   http://elj.sourceforge.net/phpwiki/

   -- I notice the the phpwiki page works like this:
   --     http://phpwiki.sourceforge.net/phpwiki/

The current page for this url details ``Loading up virgin wiki''

--8<--
Loading up virgin wiki
AddingPages 
from MIME file ./pgsrc/AddingPages new page - saved to database as version 
..

-->8--

Is there some setting in the index.php file that I need to make to obtain
the desired behaviour?  Or is it some kind of admin setup with the elj
soruceforge account?

Also I would like to provide a SourceForge link at the top or bottom of
each phpwiki page:

--8<--
<a href="http://sourceforge.net">
<img src="http://sourceforge.net/sflogo.php?group_id=45427"
width="88" height="31" border="0"
alt="elj hosted and supported by SourceForge">
</a>
-->8--

Could someone quickily indicate to me where this might be done.

Thanks for phpwiki, it is a great package which is much deserving of its
high SourceForge ranking.

Thanks .. Geoff Eldridge

-- ge...@el...
-- http://elj.sf.net/

[Phpwiki-talk] we rank 18th on Sourceforge

[Steve W. <sw...@pa...>]

If you look at Sourceforge's front page (http://sf.net/), in the right 
column they list Most Active (projects) This Week. We are ranked #18 
right now.

cheers
~swain

Re: [Phpwiki-talk] CVS: phpwiki INSTALL,1.15,1.16

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

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/

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki INSTALL,1.15,1.16

[Jeff D. <da...@da...>]

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...)

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki INSTALL,1.15,1.16

[Carsten K. <car...@ma...>]

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...)

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki INSTALL,1.15,1.16

[Jeff D. <da...@da...>]

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...)

[Phpwiki-talk] ok

[Steve W. <sw...@pa...>]

I've made the tarball. You may resume  CVS activity, and start 
committing broken code ;-)


~swain