phpwiki-talk

[Phpwiki-talk] Re: login and password saving issues

[Bernhard K. <ber...@mn...>]

On Sun, 16 May 2004 18:19:28 -0700, Rob Fulwell wrote:

> It seems I can only login users with a BogoLogin.  I have been unable to
> get passwords to save with file, database or PersonalPage methods.  I get
> no warnings (even in debug mode) and yet the UserPreferences page does not
> allow me to set a new password.
> 
> Any ideas?
> 
> I am using 1.3.10 against a MySQL database on a Linux (Debian) system.
> 
I seem to have similar problems. In the index.php I added a passwort
encrypted using passencrypt.php. By using phpmyadmin I can controll the
password. However, when I try to signin as wikiadmin the password seems
invalid.

phpwiki-1.3.9 on Apache2 with php 4.3.4 and Mysql Ver 12.22 Distrib
4.0.18, for pc-linux-gnu 

Any help appreciated

Bernhard

Re: [Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

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

Oliver Betz schrieb:
> Reini Urban <ru...@x-...> wrote:
> [...]
> 
>>No this is indented behaviour with CGI now. Your hoster will not change 
>>it, that's the new default setup for CGI.
> 
> although I don't understand what empty PATH_INFO and PATH_TRANSLATED 
> variables are good for - but I don't need to know.
> 
>>We have to find a way around it. Thanks for bringing this to our attention.
> 
> The information is also in REQUEST_URI (direct, _SERVER and _ENV), it 
> contains '/phpinfo.php/foobar', but I don't know whether this is a 
> reliable place to look for the additional path info.

Yes, we will change this to the difference from
$REQUEST_URI to $SCRIPT_NAME.
That's the reason why all CGI installations with USE_PATH_INFO = true 
failed.

It's only to seperate the script from the args. seperatd by / instead of 
? & pairs.

But today I will finally move, so better expect it tommorrow.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

[Oliver B. <ob...@de...>]

Whit Blauvelt <wh...@tr...> wrote:

[finding info on php.net]

> - but of course that's not searching bugs.php.net. 

but even searching bugs.php.net doesn't show all entries.

[...]

> So it looks like your host is running PHP as a CGI, and that in CGI mode PHP

yes, also in the previous setup.

> formerly didn't really have access to PATH_INFO so it just wasn't provided
> (it was available in the more usual mode of running PHP as an Apache
> module). However, the related PATH_TRANSLATED was kludged to copy the
> available SCRIPT_FILENAME value. Then this was fixed for one version of PHP,
> but that broke scripts expecting to find that kludged value or
> SCRIPT_FILENAME, so php.ini was set to have cgi.fix_pathinfo=0 - which

I'm not sure whether I understand your explanation, but in the 
previous setup, PATH_INFO contained the expected string - regardless 
of how PHP managed this. PhpWiki worked "pretty", although 1.3.7. 
didn't detect it automatically and I had to set USE_PATH_INFO.

And in the actual version, SCRIPT_FILENAME, ORIG_SCRIPT_FILENAME, 
_SERVER["SCRIPT_FILENAME"], _SERVER["ORIG_SCRIPT_FILENAME"], 
_ENV["SCRIPT_FILENAME"], _ENV["ORIG_SCRIPT_FILENAME"] all contain the 
same string, the full path to the script, e.g.

/homepages/u8765/test/phpinfo.php

So I don't know what other value scripts could have been expecting.

ut I really shouldn't think about the details too much as long as I 
have no clue about CGI.

Oliver

Re: [Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

[Oliver B. <ob...@de...>]

Reini Urban <ru...@x-...> wrote:

[...]

> No this is indented behaviour with CGI now. Your hoster will not change 
> it, that's the new default setup for CGI.

although I don't understand what empty PATH_INFO and PATH_TRANSLATED 
variables are good for - but I don't need to know.

> We have to find a way around it. Thanks for bringing this to our attention.

The information is also in REQUEST_URI (direct, _SERVER and _ENV), it 
contains '/phpinfo.php/foobar', but I don't know whether this is a 
reliable place to look for the additional path info.

Oliver

Re: [Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

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

On Mon, May 17, 2004 at 01:17:59AM +0200, Reini Urban wrote:

> No this is indented behaviour with CGI now. Your hoster will not change 
> it, that's the new default setup for CGI.
> 
> We have to find a way around it. Thanks for bringing this to our attention.

Reini,

There used to be no PATH_INFO for CGI (as I read the explanations), then
they fixed it, then they set the default in php.ini to not use the fix,
since that could break some old scripts looking for a related variable. So
the present technique would have never worked on PHP as CGI, then would have
briefly worked (since php.ini defaulted to use it at first), then would have
ceased working as he reports for just those cases where php.ini isn't
intentionally set to use the fix. (Without the fix, both ORIG_PATH_INFO and
PATH_INFO should be empty without the fix, given a CGI PHP.)

So yeah you can't depend on the fix being there or not. Maybe the way he
found of using the phpinfo() function is a way around it? 

Think you could use ini_get('cgi.fix_pathinfo') to test if the fix is set -
although you'd really want to check if it's even running as CGI first, not
sure how.

I imagine at some point the PHP crew will change the default back again to
the fixed state, since that would bring this into conformance with the CGI
standard, which they're a bit concerned with.

Whit

[Phpwiki-talk] login and password saving issues

[Rob F. <rfu...@dr...>]

It seems I can only login users with a BogoLogin.  I have been unable to 
get passwords to save with file, database or PersonalPage methods.  I 
get no warnings (even in debug mode) and yet the UserPreferences page 
does not allow me to set a new password.

Any ideas?

I am using 1.3.10 against a MySQL database on a Linux (Debian) system.

Cheers,

Rob.

Re: [Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

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

On Mon, May 17, 2004 at 12:50:04AM +0200, Oliver Betz wrote:

> http://bugs.php.net/bug.php?id=21575 and 
> http://bugs.php.net/bug.php?id=23800 mention it. Strange that the 
> search function doesn't find both...

Eh. I was using php.net's link to the Google search that gave:

"Your search - ORIG_PATH_INFO site:www.php.net - did not match any
documents." 

- but of course that's not searching bugs.php.net. 

> It can be configured (cgi.fix_pathinfo in php.ini), but I'm not sure 
> whether it is a bug or intended behaviour, so I can't tell my web 
> hoster to change it.
> 
> Any comments?

The PHP manual seems to be totally lacking on this. However there's a
comment in php.ini about it:

; cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI.  PHP's
; previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok 
; what PATH_INFO is.  For more information on PATH_INFO, see the cgi specs.  Setting
; this to 1 will cause PHP CGI to fix it's paths to conform to the spec.  A setting 
; of zero causes PHP to behave as before.  Default is zero.  You should fix your scripts
; to use SCRIPT_FILENAME rather than PATH_TRANSLATED.
; cgi.fix_pathinfo=0

So it looks like your host is running PHP as a CGI, and that in CGI mode PHP
formerly didn't really have access to PATH_INFO so it just wasn't provided
(it was available in the more usual mode of running PHP as an Apache
module). However, the related PATH_TRANSLATED was kludged to copy the
available SCRIPT_FILENAME value. Then this was fixed for one version of PHP,
but that broke scripts expecting to find that kludged value or
SCRIPT_FILENAME, so php.ini was set to have cgi.fix_pathinfo=0 - which
breaks things for you because you need the fix to be ther for the PATH_INFO
variable. So ... your provider can change to cgi.fix_pathinfo=1 (removing
that ";" before it) in php.ini, and you'll be good - but anyone else on the
system using PATH_TRANSLATED in a script (this could be grepped for) needs
to change to SCRIPT_FILENAME or their script will then be broken.

Whit

PS: Reini is of course right on the "SERVER_" stuff - I'm don't always run
in safe mode (too many old, old scripts).

Re: [Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

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

Oliver Betz schrieb:
> Whit Blauvelt <wh...@tr...> wrote:
>>It would be a pretty simple patch to cover this, but I don't know offhand
>>what the ORIG_ prefix means - is it just a customization your host has made?
>>I don't see any mention at all on php.net. So it's probably a patch that
>>would only make sense on your host, that you'd best handle on your own.
> 
> 
> http://bugs.php.net/bug.php?id=21575 and 
> http://bugs.php.net/bug.php?id=23800 mention it. Strange that the 
> search function doesn't find both...
> 
> It can be configured (cgi.fix_pathinfo in php.ini), but I'm not sure 
> whether it is a bug or intended behaviour, so I can't tell my web 
> hoster to change it.

No this is indented behaviour with CGI now. Your hoster will not change 
it, that's the new default setup for CGI.

We have to find a way around it. Thanks for bringing this to our attention.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

[Oliver B. <ob...@de...>]

Reini Urban <ru...@x-...> wrote:

> if (USE_PATH_INFO &&
>      !isset($_SERVER['PATH_INFO']) &&
>      isset($_SERVER['ORIG_PATH_INFO']))
> {
> 	$_SERVER['PATH_INFO'] = $_SERVER['ORIG_PATH_INFO'];
> }

sorry, I forgot to mention that I use PhpWiki 1.3.7.

$_SERVER['PATH_INFO'] = doesn't work, although I checked whether I 
can change the values (with a simple script containing phpinfo()).

I could fix also the other occurences of PATH_INFO listed in the 
phpinfo() output with _ENV[] and putenv() but PhpWiki still showed 
the HomePage regardless of the path.

> The first usage is very late, in main.php:_deducePagename()

$pathinfo = $this->get('ORIG_PATH_INFO'); worked finally. Not a 
really clean solution, but for the moment, I prefer it over the 
?pagename= method.

I still wonder whether this is a configuration problem of my web 
hoster, or a PHP issue, or the new standard behaviour...

Thanks for the help,

Oliver
-- 
Oliver Betz, Muenchen

Re: [Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

[Oliver B. <ob...@de...>]

Whit Blauvelt <wh...@tr...> wrote:

> It would be a pretty simple patch to cover this, but I don't know offhand
> what the ORIG_ prefix means - is it just a customization your host has made?
> I don't see any mention at all on php.net. So it's probably a patch that
> would only make sense on your host, that you'd best handle on your own.

http://bugs.php.net/bug.php?id=21575 and 
http://bugs.php.net/bug.php?id=23800 mention it. Strange that the 
search function doesn't find both...

It can be configured (cgi.fix_pathinfo in php.ini), but I'm not sure 
whether it is a bug or intended behaviour, so I can't tell my web 
hoster to change it.

Any comments?

Thanks,

Oliver
-- 
Oliver Betz, Muenchen

Re: [Phpwiki-talk] Fatal error: Cannot instantiate non-existent class: file_passwd in phpwiki/lib/WikiUserNew.php on line 2122

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

Damian Bierman schrieb:
> thanks for the tip!  unfortunately, adding ./lib/pear to my include_path 
> did not fix the problem.  i also tried feeding the absolute path, and 
> that didn't work either.

Try adding ./lib/pear before the other paths. It looks like you loaded 
an old pear File_Passwd.php module, which misses some features we need.

> any other ideas?
> 
> On May 16, 2004, at 08:10, Reini Urban wrote:
> 
>> Damian Bierman schrieb:
>>
>>> i'm having a problem getting going with 1.3.10 (current), which i 
>>> downloaded today. i've got everything set up and configured according 
>>> to the docs, no problem, but when i load the main page, i encounter 
>>> the following error:
>>> *Fatal error*: Cannot instantiate non-existent class: file_passwd in 
>>> *phpwiki/lib/WikiUserNew.php* on line *2122
>>
>>
>> You have to add "./lib/pear" to your include_path.
>>
>> I thought I fixed that automatically, but obviously not.
>>
>>> *which refers to this code:
>>> // "__PHP_Incomplete_Class"
>>> if (!empty($file) or empty($this->_file) or 
>>> !isa($this->_file,"File_Passwd")) $this->_file = new 
>>> File_Passwd($file, $lock, $lockfile);
>>> i'm using php 4.3.6 on a gentoo linux box (kernel 2.4.21), against a 
>>> mysql 3.2.1 database. i should note that my previous phpwiki 
>>> installation (1.2.something) worked fine against the same setup, and 
>>> that this is a completely fresh installation (i.e. not an upgrade).
>>
>>
>> Using the old WikiUser.php code by ENABLE_USER_NEW = false
>> is not recommended.

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

Re: [Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

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

Whit Blauvelt schrieb:
> It would be a pretty simple patch to cover this, but I don't know offhand
> what the ORIG_ prefix means - is it just a customization your host has made?
> I don't see any mention at all on php.net. So it's probably a patch that
> would only make sense on your host, that you'd best handle on your own.
> 
> Anyway, the patch to insert would look something like:
> 
> if (!isset($PATH_INFO)&&isset($ORIG_PATH_INFO)) {
> 	$PATH_INFO=$ORIG_PATH_INFO;
> }

if (USE_PATH_INFO &&
     !isset($_SERVER['PATH_INFO']) &&
     isset($_SERVER['ORIG_PATH_INFO']))
{
	$_SERVER['PATH_INFO'] = $_SERVER['ORIG_PATH_INFO'];
}

Somewhere in IniConfig.php:fix_config()
or if you omit the USE_PATH_INFO check,
you can put it into index.php also. That's the smallest file.

The first usage is very late, in main.php:_deducePagename()


> Where to put that? Before the first time $PATH_INFO gets called in each pass
> through. Shouldn't be too hard to find, but I haven't looked.
> 
> Whit
> 
> On Sun, May 16, 2004 at 08:58:34PM +0200, Oliver Betz wrote:
> 
>>Hello All,
>>
>>after a server update (now PHP 4.3.6 running as CGI with 
>>Apache/1.3.29) at my web hoster, PATH_INFO is empty, and the 
>>information contained now in ORIG_PATH_INFO. The same for 
>>PATH_TRANSLATED, but PhpWiki doesn't seem to use this.
>>
>>I don't know whether this can/will be changed on the part of the 
>>hoster, but maybe there is a simple way for me to adapt PhpWiki.
>>
>>Any hint how I can solve this problem with minimal changes tp PhpWiki 
>>code? I want to avoid to patch future PhpWiki installations, so maybe 
>>a simple solution is to copy the contents of ORIG_PATH_INFO to 
>>PATH_INFO?
>>
>>I have to admit that I have only rudimentary knowledge about PHP.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

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

It would be a pretty simple patch to cover this, but I don't know offhand
what the ORIG_ prefix means - is it just a customization your host has made?
I don't see any mention at all on php.net. So it's probably a patch that
would only make sense on your host, that you'd best handle on your own.

Anyway, the patch to insert would look something like:

if (!isset($PATH_INFO)&&isset($ORIG_PATH_INFO)) {
	$PATH_INFO=$ORIG_PATH_INFO;
}

Where to put that? Before the first time $PATH_INFO gets called in each pass
through. Shouldn't be too hard to find, but I haven't looked.

Whit

On Sun, May 16, 2004 at 08:58:34PM +0200, Oliver Betz wrote:
> Hello All,
> 
> after a server update (now PHP 4.3.6 running as CGI with 
> Apache/1.3.29) at my web hoster, PATH_INFO is empty, and the 
> information contained now in ORIG_PATH_INFO. The same for 
> PATH_TRANSLATED, but PhpWiki doesn't seem to use this.
> 
> I don't know whether this can/will be changed on the part of the 
> hoster, but maybe there is a simple way for me to adapt PhpWiki.
> 
> Any hint how I can solve this problem with minimal changes tp PhpWiki 
> code? I want to avoid to patch future PhpWiki installations, so maybe 
> a simple solution is to copy the contents of ORIG_PATH_INFO to 
> PATH_INFO?
> 
> I have to admit that I have only rudimentary knowledge about PHP.
> 
> TIA,
> 
> Oliver
> -- 
> Oliver Betz, Muenchen

[Phpwiki-talk] ORIG_PATH_INFO instead of PATH_INFO

[Oliver B. <ob...@de...>]

Hello All,

after a server update (now PHP 4.3.6 running as CGI with 
Apache/1.3.29) at my web hoster, PATH_INFO is empty, and the 
information contained now in ORIG_PATH_INFO. The same for 
PATH_TRANSLATED, but PhpWiki doesn't seem to use this.

I don't know whether this can/will be changed on the part of the 
hoster, but maybe there is a simple way for me to adapt PhpWiki.

Any hint how I can solve this problem with minimal changes tp PhpWiki 
code? I want to avoid to patch future PhpWiki installations, so maybe 
a simple solution is to copy the contents of ORIG_PATH_INFO to 
PATH_INFO?

I have to admit that I have only rudimentary knowledge about PHP.

TIA,

Oliver
-- 
Oliver Betz, Muenchen

Re: [Phpwiki-talk] Fatal error: Cannot instantiate non-existent class: file_passwd in phpwiki/lib/WikiUserNew.php on line 2122

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

Damian Bierman schrieb:
> i'm having a problem getting going with 1.3.10 (current), which i 
> downloaded today. i've got everything set up and configured according to 
> the docs, no problem, but when i load the main page, i encounter the 
> following error:
> 
> *Fatal error*: Cannot instantiate non-existent class: file_passwd in 
> *phpwiki/lib/WikiUserNew.php* on line *2122

You have to add "./lib/pear" to your include_path.

I thought I fixed that automatically, but obviously not.

> *which refers to this code:
> 
> // "__PHP_Incomplete_Class"
> if (!empty($file) or empty($this->_file) or 
> !isa($this->_file,"File_Passwd")) $this->_file = new File_Passwd($file, 
> $lock, $lockfile);
> 
> i'm using php 4.3.6 on a gentoo linux box (kernel 2.4.21), against a 
> mysql 3.2.1 database. i should note that my previous phpwiki 
> installation (1.2.something) worked fine against the same setup, and 
> that this is a completely fresh installation (i.e. not an upgrade).

Using the old WikiUser.php code by ENABLE_USER_NEW = false
is not recommended.


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

[Phpwiki-talk] Re: Fatal error: Cannot instantiate non-existent class: file_passwd in phpwiki/lib/WikiUserNew.php on line 2122

[Damian B. <neb...@ma...>]

hi again,

i temporarily skirted the issue by setting ENABLE_USER_NEW = false in 
config.ini.  maybe this should be the default until the feature is a 
bit less experimental?  ...just a thought.

anyway i'm up and running now.  thanks for a great wiki implementation!

-damian

On May 15, 2004, at 19:45, Damian Bierman wrote:

> dear php-wiki team:
>
> i'm having a problem getting going with 1.3.10 (current), which i 
> downloaded today.  i've got everything set up and configured according 
> to the docs, no problem, but when i load the main page, i encounter 
> the following error:
>
> Fatal error: Cannot instantiate non-existent class: file_passwd in 
> phpwiki/lib/WikiUserNew.php on line 2122
>
> which refers to this code:
>
> 	// "__PHP_Incomplete_Class"
>     if (!empty($file) or empty($this->_file) or 
> !isa($this->_file,"File_Passwd"))	    $this->_file = new 
> File_Passwd($file, $lock, $lockfile);
>
> i'm using php 4.3.6 on a gentoo linux box (kernel 2.4.21), against a 
> mysql 3.2.1 database.  i should note that my previous phpwiki 
> installation (1.2.something) worked fine against the same setup, and 
> that this is a completely fresh installation (i.e. not an upgrade).
>
> can anybody help me?
>
> thanks!
> -damian

[Phpwiki-talk] Fatal error: Cannot instantiate non-existent class: file_passwd in phpwiki/lib/WikiUserNew.php on line 2122

[Damian B. <neb...@ma...>]

dear php-wiki team:

i'm having a problem getting going with 1.3.10 (current), which i 
downloaded today.  i've got everything set up and configured according 
to the docs, no problem, but when i load the main page, i encounter the 
following error:

Fatal error: Cannot instantiate non-existent class: file_passwd in 
phpwiki/lib/WikiUserNew.php on line 2122

which refers to this code:

	// "__PHP_Incomplete_Class"
     if (!empty($file) or empty($this->_file) or 
!isa($this->_file,"File_Passwd"))	    $this->_file = new 
File_Passwd($file, $lock, $lockfile);

i'm using php 4.3.6 on a gentoo linux box (kernel 2.4.21), against a 
mysql 3.2.1 database.  i should note that my previous phpwiki 
installation (1.2.something) worked fine against the same setup, and 
that this is a completely fresh installation (i.e. not an upgrade).

can anybody help me?

thanks!
-damian

[Phpwiki-talk] With DEBUG: wrong WikiDB.pgp: assertion with numeric pagenames

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

This patch fixes a totally weird bug intoduced with 1.3.10,
with numeric pagenames and DEBUG = true or > 0:

If you get an assertion error in WikiDB.php around line 172, either turn 
off DEBUG or apply this patch:

RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiDB.php,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -2 -b -p -d -r1.55 -r1.56
--- WikiDB.php	12 May 2004 19:27:47 -0000	1.55
+++ WikiDB.php	15 May 2004 22:54:49 -0000	1.56
@@ -166,6 +166,7 @@ class WikiDB {
      function getPage($pagename) {
          static $error_displayed = false;
+        $pagename = (string) $pagename;
          if (DEBUG) {
-            if (!(is_string($pagename) and $pagename != '')) {
+            if ($pagename === '') {
                  if ($error_displayed) return false;
                  $error_displayed = true;
@@ -175,6 +176,7 @@ class WikiDB {
                  return false;
              }
-        } else
-            assert(is_string($pagename) and $pagename != '');
+        } else {
+            assert($pagename != '');
+        }
          return new WikiDB_Page($this, $pagename);
      }


-- 
Reini Urban
http://phpwiki.sf.net/

[Phpwiki-talk] Another PagePerm premission problem fixed

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

I just checked another fix for a security problem with PagePerms:

If users were signed in, but not authenticated, mostly by cookies, the 
permission system wrongly granted access for these groups, if the 
not-authenticated user (just the username) was member of these groups:
   admin, owner, creator

Now we check for the authenticated status (correct or no password) if 
access is checked for these groups.

I also checked in the first working copy of WikiAdminSetAcl, but this 
will need some more helpers. For example to display if nothing was 
changed, maybe not to store default ACL's, to change subpages also, and 
the show if the selected pages have different settings.
-- 
Reini Urban
http://phpwiki.sf.net/

Re: [Phpwiki-talk] change templates based on page name?

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

Rob Fulwell schrieb:
> First, congratulations to Reini and the gang on a smooth release.  I 
> finally got a proper MySQL backend going and I'm very happy with the 
> results.  I've moved over my customizations and all is well!

Good to hear.
On my own sites it didn't went that smooth, but at least I have some 
more bugs to hunt at.

> Now a question:
> I am interested in customizing the templates used based on the name of 
> the page being displayed.  I'm imagining this should not be too hard but 
> rather than hack around I would appreciate it if anyone feels there is a 
> "proper" way to do this.

Just go on.
You can do any php logic in the templates, but you cannot change the CSS 
after the head.tmpl.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] change templates based on page name?

[Rob F. <rfu...@dr...>]

First, congratulations to Reini and the gang on a smooth release.  I 
finally got a proper MySQL backend going and I'm very happy with the 
results.  I've moved over my customizations and all is well!

Now a question:
I am interested in customizing the templates used based on the name of 
the page being displayed.  I'm imagining this should not be too hard but 
rather than hack around I would appreciate it if anyone feels there is a 
"proper" way to do this.

Cheers,

Rob.

Re: [Phpwiki-talk] 1.3.10 - config.ini location

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

Jim Cheetham schrieb:
> By default, the 1.3.10 config.ini is placed within the public webspace
> for the wiki.

Oops, please everybody copy lib/.htaccess to config/

$ cp lib/.htaccess config/

> This means that it can be retrieved by anyone asking for
> http://<wikiname>/config/config.ini
> 
> I don't feel very confortable about allowing that file to be returned by
> the web server, so I moved mine outside the DocumentRoot for my site,
> and amended the wiki index.php :-
> 
> #IniConfig(dirname(__FILE__)."/config/config.ini");
> IniConfig("/var/www/docs/<site>/wiki-config.ini");

Matthew Palmers suggestion (the debian maintainer) to put it into 
/etc/phpwiki/config.ini is also fine, provided that the apache user has 
read permissions.

> Now, I expect that as PHP has to read this file, Apache can access it
> too, but because it's not within the DocumentRoot (in my case
> /var/www/docs/<site>/www) it is protected well-enough.
> 
> The most sensitive piece of data in there would be the dsn password,
> which should have been locked down to the webhost only anyway, but that
> won't protect against users who share a common machine with others.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] 1.3.10 released

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

Rob Fulwell schrieb:
>> http://prdownloads.sourceforge.net/phpwiki/phpwiki-1.3.10.tar.gz
>> This file is only 12K?  Previous releases have been 4-7MB...
>> Perhaps that file is only patches?

It's about 2MB, previous releases were about 1.8MB. 1.3.10 adds all the 
adodb drivers, the chinese pgsrc and one more theme (Crao) with a lot of 
new buttons.
These new Crao buttons are very "localization friendly". Only icons, 
without text.

And a lot of new MacOSX buttons by Carsten arrived some hours after the 
release, and are already in CVS. Maybe we will provide an interim tar.gz 
of these new MacOSX buttons, to be uptodate.

Note: In CVS the Crao theme directory is corrupt (wrong permission), 
which requires a fix by the sf.net support theme, which will need at 
least until Tuesday.

Another note: I will move to a new office today, and will probably very 
busy until Monday.

And during the last week (29.Apr-4.May) we were constantly in the top 
ten at the sf.net Most Active projects!
https://sourceforge.net/project/stats/index.php?report=last_30&group_id=6121
-- 
Reini Urban
http://phpwiki.sf.net/

Re: [Phpwiki-talk] ACCESS_LOG variable

[Jim C. <ji...@in...>]

On May 14, 2004, at 5:10 PM, Bernhard Kleine wrote:
>     * Please ensure that the file '/var/www2/tmp/wiki_access_log' is 
> writable,
> 	or redefine ACCESS_LOG in index.php.
>
> Since  this file is owned by wikiuser, I donot understand the error.

Perhaps the apache web-server user is different from 'wikiuser'?
On Debian, the apache server commonly runs as 'www-data', in group 
'www-data'.

Make your files group writeable by the www-data group, and things 
should work.

-jim

[Phpwiki-talk] ACCESS_LOG variable

[Bernhard K. <ber...@mn...>]

Hallo,

I managed to install phpwiki on Apache2 (Debian/Linux) with PHP 4.3.4.

There remains a minor problem: I always get:

PHP Warnings

lib/Request.php:62: Notice[1024]: The PhpWiki access log file is not writable.

    * Please ensure that the file '/var/www2/tmp/wiki_access_log' is writable, 
	or redefine ACCESS_LOG in index.php.

Since  this file is owned by wikiuser, I donot understand the error. Plese
help

/var/www2/tmp# ls -laF
total 8
drwxrwxrwx    2 wikiuser root         4096 Mai 14 06:48 ./ 
drwxr-xr-x    4 root     root         4096 Mai 14 06:13 ../ 
-rwxrwx---    1 wikiuser root           0 Mai 14 06:48 wiki_access_log*


Bernhard