phpwiki-talk

Re: [Phpwiki-talk] Bug fix for removepage.php

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

On Sun, 20 Oct 2002 21:46:26 +0200
"Oliver Betz" <ob...@de...> wrote:

> This works here: 
> 
>  if (isset($_GET['pagename']))     return $_GET['pagename']; 
> 
> Or $GLOBALS['HTTP_GET_VARS']['pagename'] for "old" PHP. 
> 
> but I have no clue whether this is good style. 

That's, essentially, what I did.  (Using $HTTP_GET_VARS rather
than $_GET, since I think we all decided a couple of months ago
that that's the way to go for now...)  (I sure wish those PHP
guys would stop changing basic things like that...)

> I assume that there is a reason for the nesting and against combining it
> 
> in request(). 

You mean WikiRequest vs. Request?  They could be combined with no
functional
loss --- I left them separate for both evolutinary and organizational
reason.
Request is completely non-wiki-specific.  It just deals with CGI request
things: gettings query args, setting cookies, etc...
WikiRequest deals with all the specifics of handling a request
to view/edit a PhpWiki page.  In retrospect WikiRequest should probably
_use_ Request rather than _being_ a Request.

(So anything that treats 'pagename' differently than any other
query arg should be in WikiRequest, not Request....)


> I see, the problem is really the missing argument from the "action" of a
> 
> "get" form. I checked also Opera 6.05 and Mozilla 1.1 with a simple
> form, but didn't find the argument passed to a PHP variable, so I
> wouldn't call it InternetExplorerGetMethodBug. So I use the fixes with
> hidden input fields. 

Is this still a problem in the current CVS code?  If so, can you provide
me a few details?

Re: [Phpwiki-talk] Suggestion on a 1.3 task

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

Johnny L. Wales schrieb:
> I was looking around the sourceforge page and noticed that there's an open
> task to write a robots.txt file which will prevent a few pages from being
> indexed. 
> 
> Maybe instead, we should include tags like this on pages we don't want
> indexed:
> <META NAME="ROBOTS" CONTENT="NOINDEX">
> 
> And, if you want the robot to stop following links on this page, you add
> this to it:
> <META NAME="ROBOTS" CONTENT="NOFOLLOW">
> 
> That should get everything you need to do done, right?

We already use the robots meta tag. The problem is that some robots 
ignore these tags and robots.txt also. So the only solution will be to 
block these. ward's wiki uses a timeout. my first patch was based on the 
$REMOTE_HOST and $HTTP_USER_AGENT.

I had this:

$badrobots = array ('gw01.webtop.com',
	       '202.102.65.191',
	       '202.111.8.102',
	       // '202.39.29.102', HTTrack 2.0x
	       // '212.182.4.121' HTTrack 2.0x
	       '61.132.57.226',
	       'lgdx06atm.lg.ehu.es', // reported falsely as Mozilla
	       );
$badagentsre = '/(WebZIP)|(Teleport 
Pro)|(Googlebot)|(DigExt)|(FAST-WebCrawler)|(Wget)|(Mercator-1.2)|(HTTrack)|(Openfind)/';
// good robots: FAST-WebCrawler, TridentSpider3

This should be an optional configuration item.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] GroupWikiPage

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

Jeff Dairiki schrieb:
>>A solution to both is "pagetype" in its own field in $page_tbl (or if it
>>
>>is the consensus a meta-data entry).  A single small int would resolve 
>>the issue:
>>
>>0 - WIKI_PAGE    # Standard Wiki Page
>>1 - GROUP_PAGE   # Group page with list of members
>>2 - USER_PAGE    # User Homepage with Meta-data containing password
>>3 - ADMIN_PAGE   # ? not sure just brainstorming for potential
>>
>>This would enable quick identification (field would be faster than 
>>meta-data), provide better security, and well...make things clearer.


> That, of course, would require back-end changes as well as requiring
> some new UI to allow editing of the page type.  (I.e. you can't change
> a page type just by editing the page in the normal way --- or at least
> you'd have to fix things so that you can....)
> 
> If you're willing to go that far, then it's probably better to just
> stick with separate group dbs, as originally suggested.  (I.e. the
> main point of cramming the group information into wiki pages was to
> avoid backend changes, and to avoid having to implement a group
> management UI...)
> 
> As you point out: so long as the GroupDatabase (and UserDatabase(s))
> are implemented as standalone objects, all of the implementation
> details can be cleanly changed later should someone feel the
> need....

I'm also against this new pagetype field. We can solve this more
easily and with less efforts in the administration.


>>>2) It looks like a non-homepage can be compromised and turned into a 
>>>homepage by adding a CategoryHomepage and then trying to login with that

In my design I store the prefs meta-data field to denote it as UserPage, 
not CategoryHomepage. "This page holds the UserPrefs".

CategoryHomepage is also fine, but a seperate IndexingMechanism.
The AllUsers plugin looks for stored UserPreferences, not for a 
CategoryHomepage link.


> I think in Reini's current design, user password verification can from
> from a number of sources (LDAP, IMAP, seperate SQL db, or data stored
> in UserPage).  Still, there is a single user namespace.   So the problem
> is a little more complicated (and insidious) since users can be created
> by processes completely unrelated to WikiPage creation/modification...
> I.e. it's not clear to me that all valid users necessarily even have
> a UserPage.  The only unique user identifier we have is the username.
> (Iff two users have the same username, they are the same user.)
> There may or may not be a wikipage with that name, and, even if there
> is, it may or may not be that users UserPage.
> 
> Is that right Reini?

exactly.
the UserPage if it exists is the best place to store the preferences. if 
it not exists it has to be stored in the cookie as before.

alternatively the admin can setup a database (also external) to store 
userprefs (and passwords).
then you need no UserPage and no cookies.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] How to submit bug fixes?

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

Oliver Betz schrieb:
> where is the right place to post a suggestion for a bug fix?
> Any special procedures to observe?

post the patch at the sf.net patch page and here an announcement.

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

[Phpwiki-talk] Email gateway to a wiki

[Lawrence F. L. Jr. <lf...@in...>]

Would there be any way to port email directly into a wiki. Like
configure a secure email ID for the wiki (in index.php) to use to subscribe to 
an existing mailing list with, like a Mailman list. Have the wiki only accept 
email from the list, configure the index.php with this email ID. Have all posts 
to the list show up in a wiki page in a Blog-like format or something similar.

-- 
L.F.London
lf...@in...
http://market-farming.com
http://www.ibiblio.org/ecolandtech/pcwiki/index.php/london

[Phpwiki-talk] dynamic linking

[aphid <me...@ap...>]

one thing i thought of when dealing with [bracketed phrases] is that 
there are many (though certainly not all) cases where other instances 
of bracketed phrases don't link..

  it occurred to me that i could do a search for each bracketed phrase 
and use that to, by hand, bracket the appropriate ones, but there must 
be some better way to go about this.  perhaps a semi-automated plugin 
(for admin only?) which brings up a queue of possible matches which 
then get marked as yes (link them) or no (leave them as they are).  has 
this been tried before?

cheers
a

Re: [Phpwiki-talk] Bug fix for removepage.php

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

Jeff Dairiki wrote: 

[$request->getArg looks in HTTP_POST_VARS] 

> Yes, but not quite.  $Request is a WikiRequest, and the constructor
> for WikiRequest fills in 'pagename' from some other sources if it's

I see. 

[merge HTTP_POST_VARS and HTTP_GET_VARS] 

> In general, I think that's a bad idea.  For security reasons, one should

Ack. I only thought about 'pagename'. 

[...] 

> So (shortly) I'm going to fix WikiRequest::_deducePagename() 
> (in main.php) so that it'll be able to figure out pagename from
> HTTP_GET_VARS...

This works here: 

 if (isset($_GET['pagename']))     return $_GET['pagename']; 

Or $GLOBALS['HTTP_GET_VARS']['pagename'] for "old" PHP. 

but I have no clue whether this is good style. 


I assume that there is a reason for the nesting and against combining it 
in request(). 


[Could this relate to the search functions not working...] 


> It might be related to other problems with USE_PATH_INFO=false, but I
> doubt it has to do with USE_PATH_INFO=true problems.

I see, the problem is really the missing argument from the "action" of a 
"get" form. I checked also Opera 6.05 and Mozilla 1.1 with a simple form, 
but didn't find the argument passed to a PHP variable, so I wouldn't call 
it InternetExplorerGetMethodBug. So I use the fixes with hidden input 
fields. 


Oliver 
-- 
Oliver Betz, Muenchen

[Phpwiki-talk] Hi Steve

[Saravanan S. <sar...@ho...>]

Hi Steve

I noticed you have added my pages =
(http://wiki.w4all.com/SaravananSubramanian) to your site. I just wanted =
to mention that these pages are slightly out of date, and I would like =
to refresh them with the latest version. Let me know how I should go =
about doing this.

Thanks for your time

Regards

Saravanan Subramanian=20
=20
ssu...@at...=20
http://www.attcanada.net/~ssubramanian=20
Phone - 306 790-7232=20
Mobile - 306 596-1665=20
DELPHI.JBUILDER(Java).XML.HL7.DICOM & ORACLE DEVELOPMENT

Re: Workaround Re: [Phpwiki-talk] Yesterday CVS snapshot

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

> So the problem may be narrowed down to the code which parses plugins on 
> non-new markup pages. No idea how to fix it :( but at least it's 
> working.

My fault.  I'll work on it now...

Thanks for identifying the problem, Carsten.

Re: [Phpwiki-talk] Bug fix for removepage.php

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

Thanks for the patch (and the repeated kicks), Oliver.

> Cause: removepage.php looks for the actual page name by using
> $request->getArg, therefore in HTTP_POST_VARS when hitting the "Remove
> the page now" button.

Yes, but not quite.  $Request is a WikiRequest, and the constructor
for WikiRequest fills in 'pagename' from some other sources if it's
not in HTTP_POST_VARS.  (If USE_PATH_INFO is true, 'pagename' gets
filled in from PATH_INFO --- the bug you're reporting only shows
up when USE_PATH_INFO is off...)

> Another possibility could be to merge HTTP_POST_VARS and HTTP_GET_VARS
> in Request(), any comment on this?

In general, I think that's a bad idea.  For security reasons, one should
ignore GET args on POST requests, I think.

In this case (deducing pagename), though, I think that's the best way
to fix the problem...

There's an asymmetry between USE_PATH_INFO and !USE_PATH_INFO.
When making a POST request with USE_PATH_INFO, the pagename
can (and should, I think) be communicated through the request
URL (via PATH_INFO).  When making a POST request without
USE_PATH_INFO, this can't be done --- if we want to allow the
pagename to be communicated in the URL, GET args is the only
way...  (This only applies to pagename --- other query args,
of course, cannot be communicated through PATH_INFO...)

So (shortly) I'm going to fix WikiRequest::_deducePagename() 
(in main.php) so that it'll be able to figure out pagename from
HTTP_GET_VARS...

> Could this relate to the search functions not working on (some?) 
> systems whith USE_PATH_INFO=true? There was also missing the name of 
> the search page...

It might be related to other problems with USE_PATH_INFO=false, but I
doubt it has to do with USE_PATH_INFO=true problems.  Of course, I've been
wrong before...

Jeff

[Phpwiki-talk] PHPWiki package for Debian

[Matthew P. <mj...@ie...>]

For those of you who run a PHPWiki under Debian GNU/Linux, you may be
interested in a package for PHPWiki which has recently been added to the
archive.  Since I'm the maintainer, I'd obviously like to see it as widely
used as possible.  Hopefully the inclusion of this package will ease the
maintenance burden for Debian admins just a little bit.


-- 
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16

[Phpwiki-talk] Bug fix for removepage.php

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

Hello All,

on Wednesday I posted this, maybe with an improper subject. Would nice to 
have some feedback.

Using PHPWiki 1.3.3, "Remove the page now" says "Someone has edited the 
page!..." or deletes HomePage if the version number of HomePage is 
accidentally identical to the version of the page to be deleted.

Cause: removepage.php looks for the actual page name by using
$request->getArg, therefore in HTTP_POST_VARS when hitting the "Remove the 
page now" button.

But HTTP_POST_VARS does not contain the page name (from the URI), at least 
on my system. So the HomePage is referenced.

To fix it, I inserted another hidden field in the remove form:

HTML::input(array('type' => 'hidden',
                  'name' => 'pagename',
                  'value' => $page->getName())),

It works, but I don't know whether $page->getName() is the best 
approach since I have little knowledge about the interplay of all the 
stuff.

Another possibility could be to merge HTTP_POST_VARS and HTTP_GET_VARS in 
Request(), any comment on this?

Could this relate to the search functions not working on (some?) 
systems whith USE_PATH_INFO=true? There was also missing the name of 
the search page...

Oliver

-- 
Oliver Betz, Muenchen

Re: [Phpwiki-talk] How to submit bug fixes?

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

Joby Walker wrote: 

> I think there is a bug list, but everyone just posts it here.  'diff
> -u' format is best.

I also thought that posting in this list is the right choice, especially 
because I'm not really a PHP programmer ("embedded" stuff in C and asm is 
my job) and some expert should look at it before using. 

Since there was no feedback to my posting I thought that I made something 
wrong. Well, I try again with another subject. 

Oliver 
-- 
Oliver Betz, Muenchen

Re: [Phpwiki-talk] How to submit bug fixes?

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

I think there is a bug list, but everyone just posts it here.  'diff -u' 
format is best.

jbw

Oliver Betz wrote:
> Hello All,
> 
> where is the right place to post a suggestion for a bug fix?
> 
> Any special procedures to observe?
> 
> Oliver

Re: [Phpwiki-talk] Troubles with PhpWiki recently developed

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

Johnny,

1) The error is caused when a variable is assumed to be an object of a 
particular type, but for some reason it isn't (probably a null).  Sounds 
  like it might have been a bad write (note there is no pagedata).

Does it fail on this page or all pages?

2) The error message says exactly where the files are:
/home/mark/public_html/phpwiki/lib/Template.php line 212
/home/mark/public_html/phpwiki/lib/WikiDB.php line 536

Which version of phpwiki are you using?  Without that it is pretty hard 
to figure out what is happending or you could post +/- 10 lines around 
the lines in question.

jbw

Johnny L. Wales wrote:
> Hiya!
> 
> We've been using phpwiki here for quite some time. We really like
> it. But, someone was trying to do something or other (what, exactly, they
> were doing is a little fuzzy) and somehow broke it in such a way that
> everytime we go to one particular keyword, it produces the following
> error:
> lib/WikiDB.php:536: Warning[2]: Assertion failed
> 
> Fatal error: Call to a member function on a non-object in
> /home/mark/public_html/phpwiki/lib/Template.php on line 212
> 
> So, I need to know a couple things:
> 
> 1. What might cause that error?
> 2. How can I figure out where all the files are stored on my installation? 
> 
> We're using a Mysql backend, but when I try to look at the offending
> record, I see the following:
> 
> +-----+-------------+------+----------+
> | id  | pagename    | hits | pagedata |
> +-----+-------------+------+----------+
> | 862 | WebraryTags |   11 |          |
> +-----+-------------+------+----------+
> 1 row in set (0.00 sec)
> 
> Which looks just like a non-offending page:
> 
> +-----+------------+------+----------+
> | id  | pagename   | hits | pagedata |
> +-----+------------+------+----------+
> | 678 | Tech Talks |  251 |          |
> +-----+------------+------+----------+
> 1 row in set (0.00 sec)
> 
> The person who broke it said he was trying to add some ! before keywords
> to make them not be links. He'd add a few !, hit preview, add a few more,
> hit preview, etc. Then, it suddenly broke and won't un-break in any way we
> can come up with.
> 
> Any ideas?
> 
> Thanks!
> 

[Phpwiki-talk] How to submit bug fixes?

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

Hello All,

where is the right place to post a suggestion for a bug fix?

Any special procedures to observe?

Oliver
-- 
Oliver Betz, Muenchen

[Phpwiki-talk] Suggestion on a 1.3 task

[Johnny L. W. <jo...@ma...>]

I was looking around the sourceforge page and noticed that there's an open
task to write a robots.txt file which will prevent a few pages from being
indexed. 

Maybe instead, we should include tags like this on pages we don't want
indexed:
<META NAME="ROBOTS" CONTENT="NOINDEX">

And, if you want the robot to stop following links on this page, you add
this to it:
<META NAME="ROBOTS" CONTENT="NOFOLLOW">

That should get everything you need to do done, right?


-- 
Johnny Wales
Book Systems, Inc.

[Phpwiki-talk] Troubles with PhpWiki recently developed

[Johnny L. W. <jo...@ma...>]

Hiya!

We've been using phpwiki here for quite some time. We really like
it. But, someone was trying to do something or other (what, exactly, they
were doing is a little fuzzy) and somehow broke it in such a way that
everytime we go to one particular keyword, it produces the following
error:
lib/WikiDB.php:536: Warning[2]: Assertion failed

Fatal error: Call to a member function on a non-object in
/home/mark/public_html/phpwiki/lib/Template.php on line 212

So, I need to know a couple things:

1. What might cause that error?
2. How can I figure out where all the files are stored on my installation? 

We're using a Mysql backend, but when I try to look at the offending
record, I see the following:

+-----+-------------+------+----------+
| id  | pagename    | hits | pagedata |
+-----+-------------+------+----------+
| 862 | WebraryTags |   11 |          |
+-----+-------------+------+----------+
1 row in set (0.00 sec)

Which looks just like a non-offending page:

+-----+------------+------+----------+
| id  | pagename   | hits | pagedata |
+-----+------------+------+----------+
| 678 | Tech Talks |  251 |          |
+-----+------------+------+----------+
1 row in set (0.00 sec)

The person who broke it said he was trying to add some ! before keywords
to make them not be links. He'd add a few !, hit preview, add a few more,
hit preview, etc. Then, it suddenly broke and won't un-break in any way we
can come up with.

Any ideas?

Thanks!

-- 
Johnny Wales
Book Systems, Inc.

Re: [Phpwiki-talk] GroupWikiPage

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

> A solution to both is "pagetype" in its own field in $page_tbl (or if it
> 
> is the consensus a meta-data entry).  A single small int would resolve 
> the issue:
> 
> 0 - WIKI_PAGE    # Standard Wiki Page
> 1 - GROUP_PAGE   # Group page with list of members
> 2 - USER_PAGE    # User Homepage with Meta-data containing password
> 3 - ADMIN_PAGE   # ? not sure just brainstorming for potential
> 
> This would enable quick identification (field would be faster than 
> meta-data), provide better security, and well...make things clearer.

That, of course, would require back-end changes as well as requiring
some new UI to allow editing of the page type.  (I.e. you can't change
a page type just by editing the page in the normal way --- or at least
you'd have to fix things so that you can....)

If you're willing to go that far, then it's probably better to just
stick with separate group dbs, as originally suggested.  (I.e. the
main point of cramming the group information into wiki pages was to
avoid backend changes, and to avoid having to implement a group
management UI...)


As you point out: so long as the GroupDatabase (and UserDatabase(s))
are implemented as standalone objects, all of the implementation
details can be cleanly changed later should someone feel the
need....

>>2) It looks like a non-homepage can be compromised and turned into a 
>>homepage by adding a CategoryHomepage and then trying to login with that
>>name.

I think in Reini's current design, user password verification can from
from a number of sources (LDAP, IMAP, seperate SQL db, or data stored
in UserPage).  Still, there is a single user namespace.   So the problem
is a little more complicated (and insidious) since users can be created
by processes completely unrelated to WikiPage creation/modification...
I.e. it's not clear to me that all valid users necessarily even have
a UserPage.  The only unique user identifier we have is the username.
(Iff two users have the same username, they are the same user.)
There may or may not be a wikipage with that name, and, even if there
is, it may or may not be that users UserPage.

Is that right Reini?

Re: [Phpwiki-talk] Exporting a wiki site

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

Ben,

Check the very end of the PhpWikiAdmin page.

jbw

Benjamin Smith wrote:
> Is there a pre-existing script or method to "export" a wiki site, and convert 
> it into standard HTML? 
> 
> -Ben 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] Exporting a wiki site

[Benjamin S. <be...@ef...>]

Is there a pre-existing script or method to "export" a wiki site, and convert 
it into standard HTML? 

-Ben 

Re: [Phpwiki-talk] GroupWikiPage

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

Jeff Dairiki wrote:
>>2) It looks like a non-homepage can be compromised and turned into a 
>>homepage by adding a CategoryHomepage and then trying to login with that
>>name.
> 
> Okay.  Maybe the CategoryHomepage idea is a bad one...  Let's fallback
> (for the sake of discussion) to detecting user pages by the presence
> of user meta-data.
> 
>>4) Without the "Group" magic word a homepage can be a grouppage as well,
>>which means that user A could not link to user B's homepage without 
>>adding B to A's group.  Which seems overlimiting...
> 
> True.  One solution is "don't do that".  ("Doctor, doctor...")
> (Another solution would be not to allow that: ignore any groups which
> have the same name as a user.)

A solution to both is "pagetype" in its own field in $page_tbl (or if it 
is the consensus a meta-data entry).  A single small int would resolve 
the issue:

0 - WIKI_PAGE    # Standard Wiki Page
1 - GROUP_PAGE   # Group page with list of members
2 - USER_PAGE    # User Homepage with Meta-data containing password
3 - ADMIN_PAGE   # ? not sure just brainstorming for potential

This would enable quick identification (field would be faster than 
meta-data), provide better security, and well...make things clearer.

jbw

Re: [Phpwiki-talk] Trouble installing with Postgres

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

Have you created the database tables using /schemas/pgsql.sql (or whateve=
r its=20
called)?

Lawrence


On Wednesday 16 Oct 2002 9:40 pm, Benjamin Smith wrote:
> Want to install phpwiki 1.3.x and having trouble doing so.
>
> Server is RH 7.1, PGSQL 7.1, apache 1.3.26. Database user/pw combinatio=
n
> has been made "ldapwiki/password", database named "ldapwiki".
>
> I've edited index.php so that array "DBParams" is:
>
> $DBParams[dbtype]=3D'SQL';
> $DBParams[dsn]=3D'pgsql://ldapwiki:password@localhost/ldapwiki';
>
> And I get the below error message in my browser. Any idea why?
>
>
> ############################### ERROR
> lib/WikiDB/backend/PearDB.php:680: Fatal[256]: wikidb_backend_pgsql: fa=
tal
> database error
>
>     * DB Error: no such table
>     * (LOCK TABLE phpwiki_page [nativecode=3DERROR: Relation 'phpwiki_p=
age'
> does not exist
>     * ])
> *
>
>
> Fatal PhpWiki Error
>
> lib/WikiDB/backend/PearDB.php:680: Fatal[256]: wikidb_backend_pgsql: fa=
tal
> database error
>
>     * DB Error: no such table
>     * (LOCK TABLE phpwiki_page [nativecode=3DERROR: Relation 'phpwiki_p=
age'
> does not exist
> * ])
> ############################### /ERROR

Re: [Phpwiki-talk] Trouble installing with Postgres

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

Hmm... Looks like you are actually connecting...

try:

1) psql -U postgres ldapwiki
2) \d

explanation:
1) Should connect you as the postgres user to your database.
2) \d switch lists all objects.

"phpwiki_page" is not a standard name for a table (normally "page") did 
you make this change?

jbw

Benjamin Smith wrote:
> Want to install phpwiki 1.3.x and having trouble doing so. 
> 
> Server is RH 7.1, PGSQL 7.1, apache 1.3.26. Database user/pw combination has 
> been made "ldapwiki/password", database named "ldapwiki". 
> 
> I've edited index.php so that array "DBParams" is: 
> 
> $DBParams[dbtype]='SQL'; 
> $DBParams[dsn]='pgsql://ldapwiki:password@localhost/ldapwiki'; 
> 
> And I get the below error message in my browser. Any idea why? 
> 
> 
> ############################### ERROR 
> lib/WikiDB/backend/PearDB.php:680: Fatal[256]: wikidb_backend_pgsql: fatal 
> database error
> 
>     * DB Error: no such table
>     * (LOCK TABLE phpwiki_page [nativecode=ERROR: Relation 'phpwiki_page' 
> does not exist
>     * ])
> *
> 
> 
> Fatal PhpWiki Error
> 
> lib/WikiDB/backend/PearDB.php:680: Fatal[256]: wikidb_backend_pgsql: fatal 
> database error
> 
>     * DB Error: no such table
>     * (LOCK TABLE phpwiki_page [nativecode=ERROR: Relation 'phpwiki_page' 
> does not exist
> * ])
> ############################### /ERROR 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] Trouble installing with Postgres

[Benjamin S. <be...@ef...>]

Want to install phpwiki 1.3.x and having trouble doing so. 

Server is RH 7.1, PGSQL 7.1, apache 1.3.26. Database user/pw combination has 
been made "ldapwiki/password", database named "ldapwiki". 

I've edited index.php so that array "DBParams" is: 

$DBParams[dbtype]='SQL'; 
$DBParams[dsn]='pgsql://ldapwiki:password@localhost/ldapwiki'; 

And I get the below error message in my browser. Any idea why? 


############################### ERROR 
lib/WikiDB/backend/PearDB.php:680: Fatal[256]: wikidb_backend_pgsql: fatal 
database error

    * DB Error: no such table
    * (LOCK TABLE phpwiki_page [nativecode=ERROR: Relation 'phpwiki_page' 
does not exist
    * ])
*


Fatal PhpWiki Error

lib/WikiDB/backend/PearDB.php:680: Fatal[256]: wikidb_backend_pgsql: fatal 
database error

    * DB Error: no such table
    * (LOCK TABLE phpwiki_page [nativecode=ERROR: Relation 'phpwiki_page' 
does not exist
* ])
############################### /ERROR