phpwiki-talk

Re: [Phpwiki-talk] 1.3.9 security fixes and 1.3.7

[Matthew P. <mp...@he...>]

On Mon, May 10, 2004 at 03:24:53PM +0200, Reini Urban wrote:
> BTW, to which security problems did he refer to?

He just pointed to the patch tracker entry for -p1, but I'm pretty sure it
was "Default persmissions not honored.  Everybody was able to edit".

> that the registered websites did that) I better bring out a tested 
> stable release with 80% of the planned features, and do the rest in a 1.3.11

Hey, version numbers are cheap.  Release early, release often...

> >I'm happy to take this discussion to the list if it's better that way.
> 
> We already are on the list, aren't we?

Yes, we are.  The cold and flu tablets I'm on appear to have some side
effects... <grin>

- Matt

Re: [Phpwiki-talk] 1.3.9 security fixes and 1.3.7

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

Matthew Palmer schrieb:
> On Mon, May 10, 2004 at 12:32:53PM +0200, Reini Urban wrote:
>>Matthew Palmer schrieb:
>>
>>>Do any of the fixes in 1.3.9p1 fix security problems which were introduced
>>>before or in 1.3.7?  The conglomerate patch provided isn't real easy to 
>>>work out.
>>
>>No.
> 
> Thanks for confirming that.  Had a user who was worried about it, and it's
> always better safe than sorry.

BTW, to which security problems did he refer to?
Most old 1.3.7 and 1.3.4 bugs are closed now. These ARE fixed.
See the sf.net bugs page.

>>problems fixed with 1.3.9p1 which also affected 1.3.7:
>>* set UserPreferences for bool and int fixed
>>* dba open problems improved
>>* php-4.0.6 support re-enabled (superglobals,array_key_exists)
>>* PageGroup support for [links] and subpages
>>
>>BTW: As soom as some pending InlineParser problems (still minor ones) 
>>are fixed, I'll roll out another release.
> 
> I think I'll hold off packaging another phpwiki release until 1.3.10, then.

I think most problems are now resolved.
The only pending problem TBD is CreateToc. So I think 1.3.10 will be out 
by tomorrow.

This will not include all of my initial goals.
   http://phpwiki.sourceforge.net/phpwiki?DevelopmentBranch
But since the 1.3.9-p1 patches aren't really easy to apply (didn't see 
that the registered websites did that) I better bring out a tested 
stable release with 80% of the planned features, and do the rest in a 1.3.11
(WikiGroup user independency, RateIt, Crao, LDAP-old, editpage toolbar, 
SOAP, config helpers - installer)

> On the subject of releases (mainly the stable series), has anyone been
> working on a translator from the 1.3 series index.php config to the new
> INIConfig system?  Manually rewriting bits and pieces of the config file is
> probably fairly easy for most situations, but I'd like a (semi) automated
> solution for the Debian packaging, if possible.

I think Joby has something in the works. At least the values at the demo 
site seemed to be autogenerated.

> I'm happy to take this discussion to the list if it's better that way.

We already are on the list, aren't we?
-- 
Reini Urban
http://phpwiki.sf.net/

Re: [Phpwiki-talk] 1.3.9 security fixes and 1.3.7

[Matthew P. <mp...@he...>]

On Mon, May 10, 2004 at 12:32:53PM +0200, Reini Urban wrote:
> Matthew Palmer schrieb:
> >Do any of the fixes in 1.3.9p1 fix security problems which were introduced
> >before or in 1.3.7?  The conglomerate patch provided isn't real easy to 
> >work
> >out.
> 
> No.

Thanks for confirming that.  Had a user who was worried about it, and it's
always better safe than sorry.

> problems fixed with 1.3.9p1 which also affected 1.3.7:
> * set UserPreferences for bool and int fixed
> * dba open problems improved
> * php-4.0.6 support re-enabled (superglobals,array_key_exists)
> * PageGroup support for [links] and subpages
> 
> BTW: As soom as some pending InlineParser problems (still minor ones) 
> are fixed, I'll roll out another release.

I think I'll hold off packaging another phpwiki release until 1.3.10, then.

On the subject of releases (mainly the stable series), has anyone been
working on a translator from the 1.3 series index.php config to the new
INIConfig system?  Manually rewriting bits and pieces of the config file is
probably fairly easy for most situations, but I'd like a (semi) automated
solution for the Debian packaging, if possible.

I'm happy to take this discussion to the list if it's better that way.

- Matt

Re: [Phpwiki-talk] a new wiki bug

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

Micki Kaufman schrieb:
> Still trying to get my 1.3.4 production site up on 1.3.9 or 1.4.0 - Two 
> bugs to report.
> 
> 1. My wiki is only displaying some of the characters on each line:
> 
> WikiText:
> ---
> ~WikiPlugins allow one to easily add new types of dynamic content (as
> well as other functionality) to wiki pages within PhpWiki.  In this
> very wiki, the RecentChanges, BackLinks, LikePages and most other indexing
> scheme pages are all implemented using plugins.
> 
> Sooner or later the old-style phpwiki: [MagicPhpWikiURLs] will be replaced
> by plugins too.
> ---
> 
> 
> the browser displays:
> ---
> WikiPluginswell as other functionality) to wiki pages within PhpWikiwell 
> as other functionality) to wiki pages within PhpWikivery wiki, the 
> RecentChangesecentChanges, BackLinks, LikePagesscheme pages are all 
> implemented using plugins.
> 
> Sooner or later the old-style phpwiki: MagicPhpWikiURLs?by plugins too.
> ---
> 
> For example, PhpWikiAdministration reads
> 
> ---
> Php Wiki Administration
> 
> 
> Note: password in the PhpWikipassword in the PhpWikipassword in the 
> PhpWikipassword in the PhpWikipassword in the PhpWikipassword in the 
> PhpWikithe PhpWiki config file.
> ---
> 
> Looks like something is truncating on display.

Yes, I know. This is my premature InlineParser optimization, introduced 
2004-05-09. I'll try to find a better solution or revert back to the 
previous version today.

> Also - bonus bugs:
> 
> 1. I have set the proper admin username and password in my config.ini 
> file, and have disabled 'encrypted password', but I still see an error 
> when attempting to log in as admin with the correct credentials, if 'Db' 
> is in my USER_AUTH_ORDER. Removing 'Db' allowed me to log in as admin.
> 
>  DEBUG: ALLOW_ANON_EDIT = false, ALLOW_BOGO_LOGIN = false, 
> ALLOW_USER_PASSWORDS = true USER_AUTH_ORDER: PersonalPage => Db => 
> Forbidden, USER_AUTH_POLICY: old, PASSWORD_LENGTH_MINIMUM: 2

If DB fails there must be something wrong with your SELECT statements

; database-hashed passwords (more secure):
DBAUTH_AUTH_CHECK = "SELECT IF(passwd=PASSWORD('$password'),1,0) FROM 
user WHERE userid='$userid'"

But it could be me, I'll check it.

> 2. I wound up removing 'MagicPHPWikiURLs' and creating the page 
> manually, cause it seems to hang the install.

Thanks for the report.

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

Re: [Phpwiki-talk] 1.3.9 security fixes and 1.3.7

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

Matthew Palmer schrieb:
> Do any of the fixes in 1.3.9p1 fix security problems which were introduced
> before or in 1.3.7?  The conglomerate patch provided isn't real easy to work
> out.

No.

problems fixed with 1.3.9p1 which also affected 1.3.7:
* set UserPreferences for bool and int fixed
* dba open problems improved
* php-4.0.6 support re-enabled (superglobals,array_key_exists)
* PageGroup support for [links] and subpages

BTW: As soom as some pending InlineParser problems (still minor ones) 
are fixed, I'll roll out another release.
-- 
Reini Urban
http://phpwiki.sf.net/

[Phpwiki-talk] another interesting bug

[Micki K. <mic...@co...>]

When I'm on the 'PhpAdministration' page and I log out, or log in, it 
reloads the page with the whole page repeated at the 'Email 
Verification' button, in its' place.

Weird!

By the way, this latest go-around is looking very promising! 
BogoLogin seems the only big issue remaining!

Micki
-- 

Micki
mailto:mic...@co...

[Phpwiki-talk] a new wiki bug

[Micki K. <mic...@co...>]

Hi friends.

Still trying to get my 1.3.4 production site up on 1.3.9 or 1.4.0 - 
Two bugs to report.

1. My wiki is only displaying some of the characters on each line:

WikiText:
---
~WikiPlugins allow one to easily add new types of dynamic content (as
well as other functionality) to wiki pages within PhpWiki.  In this
very wiki, the RecentChanges, BackLinks, LikePages and most other indexing
scheme pages are all implemented using plugins.

Sooner or later the old-style phpwiki: [MagicPhpWikiURLs] will be replaced
by plugins too.
---


the browser displays:
---
WikiPluginswell as other functionality) to wiki pages within 
PhpWikiwell as other functionality) to wiki pages within PhpWikivery 
wiki, the RecentChangesecentChanges, BackLinks, LikePagesscheme pages 
are all implemented using plugins.

Sooner or later the old-style phpwiki: MagicPhpWikiURLs?by plugins too.
---

For example, PhpWikiAdministration reads

---
Php Wiki Administration


Note: password in the PhpWikipassword in the PhpWikipassword in the 
PhpWikipassword in the PhpWikipassword in the PhpWikipassword in the 
PhpWikithe PhpWiki config file.
---

Looks like something is truncating on display.

Also - bonus bugs:

1. I have set the proper admin username and password in my config.ini 
file, and have disabled 'encrypted password', but I still see an 
error when attempting to log in as admin with the correct 
credentials, if 'Db' is in my USER_AUTH_ORDER. Removing 'Db' allowed 
me to log in as admin.

  DEBUG: ALLOW_ANON_EDIT = false, ALLOW_BOGO_LOGIN = false, 
ALLOW_USER_PASSWORDS = true USER_AUTH_ORDER: PersonalPage => Db => 
Forbidden, USER_AUTH_POLICY: old, PASSWORD_LENGTH_MINIMUM: 2

2. I wound up removing 'MagicPHPWikiURLs' and creating the page 
manually, cause it seems to hang the install.

Thanks,
Micki
-- 

Micki
mailto:mic...@co...

[Phpwiki-talk] 1.3.9 security fixes and 1.3.7

[Matthew P. <mp...@he...>]

Do any of the fixes in 1.3.9p1 fix security problems which were introduced
before or in 1.3.7?  The conglomerate patch provided isn't real easy to work
out.

- Matt

Re: [Phpwiki-talk] current CVS InlineParser problem fixed

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

Reini Urban schrieb:
> I found now the problem with the current InlineParser, why it fails only 
> on sf.net:
> The problem is that the php at sf.net has less memory for regular 
> expressions than a typical php, both have an 8M memory_limit, but 
> somehow anchored pcre regex obviously allocate from somewhere else.

Problem on http://phpwiki.sf.net/demo/ fixed.

It was not the memory, it was an endless loop, caused by an empty 
definition of WIKI_NAME_REGEXP, which I fixed now in IniConfig.php.
Exactly this constant wasn't checked for its default setting.

Anyway the huge regexp string is now gone also, and the whole inline 
parsing is now a lot better, falling back to the previous hairy code 
only if two conflicting markups are found in the same block.

> The problem is RegexpSet::_match with the huge regexp string, which now 
> with the added Inline plugin markup overflow its limit.
> 
> The pattern is contructed from
>   $pat= "/ ( . $repeat ) ( (" . join(')|(', $regexps) . ") ) /Asx";
> The modifier A (ANCHORED) tells pcre to store the block, regexps is an 
> array of 10 rather complicated regex strings, and repeat starts from 
> "*?" to {nn} towards the end, so that the prematch gets longer and 
> longer, until nothing is found anymore and the final "$" regexps 
> matches. This ends the loop.
> 
> On sf.net we don't have an endless loop, we rather run out of memory, 
> because of the continued anchored matching of the same huge regexp, 
> until repeat gets large enough. The /A tells pcre to store the matching 
> block to notify match() which regexps actually matched, and to be able 
> to recurse into shorter substrings then.
> 
> I rewrote now that critical part to be somewhat slower, but to need much 
> less memory.
> We don't really need to string-join the regexps array together.
> It is sufficient to loop through all regexps until one balanced or 
> simple markup matches.
> The problem is that the longest substring should be favoured, so that it 
> recurses into matches, that's what /A is for.
> e.g. for "<small>*WikiWord*</small>" it has to match at first the 
> balanced <small> tag, than the *...* emphasis and at last the wikiword 
> inside.
> 
> The hugest partial regexp is the interwiki map which constructs 
> "(moniker1:|moniker2:|moniker3:|moniker4:|moniker5:|moniker6:|moniker7:|...)" 
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] To 1.3.9 or to 1.4.0?

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

Whit Blauvelt schrieb:
> Will the 1.3.9 to 1.4.0 upgrade path be trivial, or will there be enough
> work in upgrading between the two to make it worth waiting for 1.4.0 before
> implementing a fairly complex project given that 1.4.0 (and beyond) should
> be the target for it?

index.php configs moved to config/config.ini
   (finished, in current CVS, some problems occur from time to time)
the PrettyWiki detection is much more stable now (hope it stays so),
the include code for pear is kind of problematic, because it leaves the 
decision to the user (no problems yet reported, but I am sure there will 
be),
adodb is completely new (finished, in current CVS, no problems since two 
weeks anymore),
page permissions will be usable (not yet).

Some bugs will be fixed, and some new bugs will be introduced (hopefully 
not)

But before 1.4.0 we will bring out 1.3.10, to test the latest fixes and 
to gain some confidence in the stability.

Carsten thought about full utf-8 support, but I think we will postpone 
this to the 1.5.x branch.
Currently we cannot switch between single-byte charsets and multi-byte 
charsets. Either you define utf-8 and convert all docs to utf-8 (chinese 
and japanese already are), or you define for example latin-1 and cannot 
display japanese and chinese together with the single-byte charsets.
regex attributes might have to be fixed for utf-8, dynamic conversion 
will have be to be done, and so on.

Currently I work on
* support for older php versions (on 4.0.5 and 4.0.4-pl1 it runs very 
unstable) and the php-5.0 branch,
* strange dba problems with certain php versions (< 4.1 and > 4.3, with 
locking and session_write_close problems), and
* a weird pcre problem which only appears on the loaded sf.net server 
(php-4.1.2)

This might lead to some needed optimizations for the InlineParser.
If this cannot be fixed sooner or later, we will have to revert to the 
old parser code, without the memory optimizations and without inlined 
tightened plugins.
e.g. "* <small><?plugin MostPopular></small>", or
inlined "This site runs the PhpWiki <?plugin SystemInfo version?> version."
will then not be supported.

But if my analysis is true, adding more Interwiki urls will also break 
the parser sooner or later, which is not really an option.

Besides that a lot of bugs appear and disappear on the sf.net tracker, 
which is good sign.
I also expect some adodb pgsql problems with transactions, and mysqli 
and mysqlt requests.

You can try out the current CVS code by yourself. I don't expect it to 
break. Only on very very weird setups it breaks.
-- 
Reini Urban
http://phpwiki.sf.net/

[Phpwiki-talk] To 1.3.9 or to 1.4.0?

[Whit B. <wh...@tr...>]

Will the 1.3.9 to 1.4.0 upgrade path be trivial, or will there be enough
work in upgrading between the two to make it worth waiting for 1.4.0 before
implementing a fairly complex project given that 1.4.0 (and beyond) should
be the target for it?

Thanks,
Whit

Re: [Phpwiki-talk] current CVS InlineParser

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

I found now the problem with the current InlineParser, why it fails only 
on sf.net:
The problem is that the php at sf.net has less memory for regular 
expressions than a typical php, both have an 8M memory_limit, but 
somehow anchored pcre regex obviously allocate from somewhere else.

The problem is RegexpSet::_match with the huge regexp string, which now 
with the added Inline plugin markup overflow its limit.

The pattern is contructed from
   $pat= "/ ( . $repeat ) ( (" . join(')|(', $regexps) . ") ) /Asx";
The modifier A (ANCHORED) tells pcre to store the block, regexps is an 
array of 10 rather complicated regex strings, and repeat starts from 
"*?" to {nn} towards the end, so that the prematch gets longer and 
longer, until nothing is found anymore and the final "$" regexps 
matches. This ends the loop.

On sf.net we don't have an endless loop, we rather run out of memory, 
because of the continued anchored matching of the same huge regexp, 
until repeat gets large enough. The /A tells pcre to store the matching 
block to notify match() which regexps actually matched, and to be able 
to recurse into shorter substrings then.

I rewrote now that critical part to be somewhat slower, but to need much 
less memory.
We don't really need to string-join the regexps array together.
It is sufficient to loop through all regexps until one balanced or 
simple markup matches.
The problem is that the longest substring should be favoured, so that it 
recurses into matches, that's what /A is for.
e.g. for "<small>*WikiWord*</small>" it has to match at first the 
balanced <small> tag, than the *...* emphasis and at last the wikiword 
inside.

The hugest partial regexp is the interwiki map which constructs 
"(moniker1:|moniker2:|moniker3:|moniker4:|moniker5:|moniker6:|moniker7:|...)"

Without this regexp it doesn't run out of memory anymore.

Joby Walker schrieb:
> I haven't been able to reproduce the error.  Which is too bad because I 
> have just finished setting up Xdebug.
> 
> Reini Urban wrote:
>> Dan Frankowski schrieb:
>>
>>> I was not able to reproduce the problem. I might work on debugging 
>>> the SourceForge site if I had access to it. What's the word on that?
>>
>> The problem is for us developers, that we can only do printf-style 
>> debugging on sf.net, and this only for one day. On the next night the 
>> whole content will be overwritten by steve's automatic cvs update script.
>>
>> But most importantly we cannot use a php debugger there.
>> So I would love to see anyone with debugging skills, on whose site 
>> this problem also exists. This would narrow the search for the 
>> possible problem.
>>
>> Yesterday I could reproduce a similar problem with an endless loop in 
>> the InlineParser, and so at least some parts of the website are 
>> accessible again.
>> I also found a strange dba session problem with this special php 
>> version 4.1.2 and 4.1.1, but not really related to my current problem.

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

[Phpwiki-talk] Re: [phpwiki - Open Discussion] using apache authentication

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

SourceForge.net schrieb:
> Read and respond to this message at: 
> https://sourceforge.net/forum/message.php?msg_id=2559559
> By: smarlowe
> 
> Hi, my site uses apache authentication, and PHPWiki almost, nearly seems to
> be able to use it.  It sees my name, and says I'm sorta halfware logged in,
> but it would be quite nice to have it just use the apache authentication and
> not have to have all 1500 employees where I work register in yet another software
> app.  We use LDAP for our backend, so if hitting LDAP would be a way to keep
> track of users, I'd be willing to do some of the work to make that happen. 
> Once I get my brain wrapped around a bit more of the phpwiki code.

Please see doc/README.phpwiki-auth

We already support both, apache http auth and LDAP.

If you use LDAP as backend for apache http auth, just define
"HttpAuth" in USER_AUTH_ORDER.

The problem might be the "halfway" logged in.
The exact message or problem description please.
If you loose the authenticated status on the second click, it's a 
session problem, not a auth problem.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Unit tests ?

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

Dan Frankowski schrieb:
> I think unit testing is valuable for software development. There is some 
> kind of testing framework in phpwiki at phpwiki/tests. However, it seems 
> to be "functional tests"-- that is, tests of the entire interface, 
> rather than individual classes or methods (unit testing). Furthermore, 
> it requires perl and java, and seems to have many moving parts.
> 
> I have written the very beginning of a small unit test framework, and I 
> attach it to this email. 

Now that's really great news!
I added some tricky link syntax and committed it.
It doesn't run yet inside the Zend Debugger, but this should be trivial.

> phpwiki/tests/unit % php test.php
> Run tests ..
> TestCase inlineparsertest->testnowikiwords() passed
> TestCase inlineparsertest->testwikiword() passed

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

Re: [Phpwiki-talk] current CVS InlineParser

[Joby W. <joby@u.washington.edu>]

I haven't been able to reproduce the error.  Which is too bad because I 
have just finished setting up Xdebug.

Joby Walker
C&C Computer Operations Software Support Group



Reini Urban wrote:
> Dan Frankowski schrieb:
> 
>> I was not able to reproduce the problem. I might work on debugging the 
>> SourceForge site if I had access to it. What's the word on that?
> 
> 
> The problem is for us developers, that we can only do printf-style 
> debugging on sf.net, and this only for one day. On the next night the 
> whole content will be overwritten by steve's automatic cvs update script.
> 
> But most importantly we cannot use a php debugger there.
> So I would love to see anyone with debugging skills, on whose site this 
> problem also exists. This would narrow the search for the possible problem.
> 
> Yesterday I could reproduce a similar problem with an endless loop in 
> the InlineParser, and so at least some parts of the website are 
> accessible again.
> I also found a strange dba session problem with this special php version 
> 4.1.2 and 4.1.1, but not really related to my current problem.

Re: [Phpwiki-talk] current CVS InlineParser

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

Dan Frankowski schrieb:
> I was not able to reproduce the problem. I might work on debugging the 
> SourceForge site if I had access to it. What's the word on that?

The problem is for us developers, that we can only do printf-style 
debugging on sf.net, and this only for one day. On the next night the 
whole content will be overwritten by steve's automatic cvs update script.

But most importantly we cannot use a php debugger there.
So I would love to see anyone with debugging skills, on whose site this 
problem also exists. This would narrow the search for the possible problem.

Yesterday I could reproduce a similar problem with an endless loop in 
the InlineParser, and so at least some parts of the website are 
accessible again.
I also found a strange dba session problem with this special php version 
4.1.2 and 4.1.1, but not really related to my current problem.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Unit tests ?

[Dan F. <dfr...@cs...>]

Folks,

I think unit testing is valuable for software development. There is some 
kind of testing framework in phpwiki at phpwiki/tests. However, it seems 
to be "functional tests"-- that is, tests of the entire interface, 
rather than individual classes or methods (unit testing). Furthermore, 
it requires perl and java, and seems to have many moving parts.

I have written the very beginning of a small unit test framework, and I 
attach it to this email. Take unit.tgz, and

cd phpwiki/tests
tar xvfz unit.tgz
cd unit
php test.php

and it should run the tests.

If this looks good and is checked in, I will start writing more tests 
for it, and encourage others to do so.

I started with InlineParser, as it seemed to be something we'd like to 
have unit tests for.

I cut and paste the readme.html from the tarball below.

Dan


  Introduction

This directory contains unit tests for PhpWiki. You must have PEAR's 
PHPUnit package <http://pear.php.net/package/PHPUnit>. These tests are 
unrelated to maketest.pl in the directory above this one, which do not 
use PHPUnit.


  Prerequisites


    PHP

You need the php command-line interface 
<http://us3.php.net/features.commandline>. It was experimental as of PHP 
4.2.0, default as of PHP 4.3.0. You also need the 'pear' executable.


    PHPUnit

You can use pear to see if PHPUnit is installed:

/export/scratch/apache/2.0.46/php/bin) % ./pear list
Installed packages:
===================
Package        Version State
Archive_Tar    0.9     stable
Console_Getopt 1.0     stable
DB             1.3     stable
HTTP           1.2     stable
HTTP_Upload    0.8.1   stable
Mail           1.0.1   stable
Net_SMTP       1.0     stable
Net_Socket     1.0.1   stable
PEAR           1.1     stable
PHPUnit        1.0.0   stable
XML_Parser     1.0.1   stable
XML_RPC        1.0.4   stable

If it is not installed, you can use 'pear' to install it:

/export/scratch/apache/2.0.46/php/bin) % ./pear install PHPUnit


  Running these unit tests

You must be in the phpwiki/tests/unit subdirectory. Then use the php 
command-line executable to run the tests. For example:

phpwiki/tests/unit % php test.php
Run tests ..
TestCase inlineparsertest->testnowikiwords() passed

TestCase inlineparsertest->testwikiword() passed

Re: [Phpwiki-talk] current CVS InlineParser

[Dan F. <dfr...@cs...>]

Reini Urban wrote:

> Reini Urban schrieb:
>
>> I would appreciate if someone can help me finding the cause of
>> the problem with the current CVS code.
>> See http://phpwiki.sourceforge.net/demo/
>>
>> It looks like a InlineParser or BlockParser problem.
>> The last change was the new SimpleMarkup Markup_plugin,
>> which works fine for me. Even without this new markup it breaks.
>> Actions without display do work fine at sf.net.
>>
>> I tested it with the login.tmpl which is displayed fine without the
>>   $t = asXML(TransformText(_("You may sign in using any 
>> [WikiWord|AddingPages] as a user id. (Any characters in %s etc. may 
>> be used too). The user id will be used as a link in RecentChanges to 
>> your home page."), 2.0, true));
>> line, but breaks with the TransformText() function.
>>
>> But it could also be a subtle config problem. This is very fresh also.
>>
>> It works for me, only at the sf.net site it breaks.
>> So if the current CVS code breaks for someone also,
>> and he is able to debug it, this would be great.
>
>
> Apparently nobody was able to reproduce this problem, as it happens on 
> sf.net.
> I added now some debugging options to avoid the endless loop in the 
> InlineParser, which doesn't solve the problem, but helps the poor 
> sf.net server and displays an almost empty page.
> With DEBUG = on you get this behavior, with DEBUG = false you get the 
> old assertion errors and will not be able to backup or fix anything.
>
> http://phpwiki.sourceforge.net/demo/


I was not able to reproduce the problem. I might work on debugging the 
SourceForge site if I had access to it. What's the word on that?

Dan

Re: [Phpwiki-talk] current CVS InlineParser

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

Reini Urban schrieb:
> I would appreciate if someone can help me finding the cause of
> the problem with the current CVS code.
> See http://phpwiki.sourceforge.net/demo/
> 
> It looks like a InlineParser or BlockParser problem.
> The last change was the new SimpleMarkup Markup_plugin,
> which works fine for me. Even without this new markup it breaks.
> Actions without display do work fine at sf.net.
> 
> I tested it with the login.tmpl which is displayed fine without the
>   $t = asXML(TransformText(_("You may sign in using any 
> [WikiWord|AddingPages] as a user id. (Any characters in %s etc. may be 
> used too). The user id will be used as a link in RecentChanges to your 
> home page."), 2.0, true));
> line, but breaks with the TransformText() function.
> 
> But it could also be a subtle config problem. This is very fresh also.
> 
> It works for me, only at the sf.net site it breaks.
> So if the current CVS code breaks for someone also,
> and he is able to debug it, this would be great.

Apparently nobody was able to reproduce this problem, as it happens on 
sf.net.
I added now some debugging options to avoid the endless loop in the 
InlineParser, which doesn't solve the problem, but helps the poor sf.net 
server and displays an almost empty page.
With DEBUG = on you get this behavior, with DEBUG = false you get the 
old assertion errors and will not be able to backup or fix anything.

http://phpwiki.sourceforge.net/demo/
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Wiki 1.3.3 supports MSSQLServer

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

shreedhar schrieb:
> Is wiki 1.3.3 supports MSSQLServer. If it supports what will be the 
> configuration in index.php.

Same as with all other databases:
define PearDB, ADODB can only be used for mysql (all others since 
1.3.10, which is not released yet)

$DbParams['dbtype'] = 'SQL';

$DbParams['dsn'] = 'mssql://username@hostspec/database';

But you can also try to use ODBC
   $DbParams['dsn'] = 'odbc://username@localhost/global_dsn';

Look at lib/pear/DB/mssql.php and lib/pear/DB/odbc.php
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Wiki 1.3.3 supports MSSQLServer

[shreedhar <shr...@lu...>]

Is wiki 1.3.3 supports MSSQLServer. If it supports what will be the =
configuration in index.php.

Sreedhar

Re: [Phpwiki-talk] How to create new pages

[Dan F. <dfr...@cs...>]

shreedhar wrote:

> Hi All,
>  
> How do add my own pages through wiki. I checked "Sandbox" it has its 
> own default text. Can't I create my new pages.
>  
> Sree


If you are using Phpwiki, see 
http://phpwiki.sourceforge.net/phpwiki/AddingPages.

Dan

[Phpwiki-talk] How to create new pages

[shreedhar <shr...@lu...>]

Hi All,

How do add my own pages through wiki. I checked "Sandbox" it has its own =
default text. Can't I create my new pages.=20

Sree

[Phpwiki-talk] Re: postgresql problem

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

Christopher Benson-Manica schrieb:
> initdb doesn't work, because it says the shmget system call is not
> implemented.  Is there anything I can do about this?

yes, read the docs.

You need to start ipc-daemon2 before.
And you need to pass --locale=C to initdb also.

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

[Phpwiki-talk] 1.3.9 patch available

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

I collected a patch for some severe 1.3.9 problems at
http://sourceforge.net/tracker/index.php?func=detail&aid=947848&group_id=6121&atid=306121

This patch fixes the following problems:

1.3.9p1 May 4, 2004, Reini Urban:

Bugfix release for the following 1.3.9 problems:
* Default permissions not honored. Everybody was able to edit.
* set UserPreferences for bool and int fixed
* dba open problems improved
* session transportation improved, no db objects stored
* php-4.0.6 support re-enabled (superglobals, array_key_exists)
* WikiAdminRemove deleted too many if args passed from WikiAdminSelect
* PageGroup support for [links] and subpages
* disabled default dba sessions, broken!
* HttpClient fixes for older php's
* RssFeed for allow_url_fopen=false, IMAGE support, empty ITEM list

apply it e.g. like this:

gunzip /tmp/phpwiki-1.3.9-p1.patch.gz
cd phpwiki-1.3.9
patch -p1 < /tmp/phpwiki-1.3.9-p1.patch

I was not able to re-enable USE_DB_SESSION for "dba" with php-4.0.6 and 
php-4.1.2. This are the special versions I tested with this special 
patch, the current main branch for 1.3.10 is tested with some more newer 
php's, so it will work there also.
In detail I test regularly against 4.0.6, 4.1.2, 4.2.1, 4.3.2, 4.3.5 and 
4.3.7.
So I disabled the default setting for DB_Sessions under dba.

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