phpwiki-talk

RE: [Phpwiki-talk] bug in PhpWik Administration/Replace

[John C. <joh...@ua...>]

Reini,
  I've done that and added the UnfoldSubpages bug and patch as well.

  Could you put a direct link to the sf bugtracker page ont he front phpWiki
page?  I'll start trying to make sure I post a bug report or feature request
to there as well as to the list :-)

Thanks,

John Cole

-----Original Message-----
From: php...@li...
[mailto:php...@li...]On Behalf Of Reini
Urban
Sent: Friday, August 13, 2004 10:24 AM
To: php...@li...
Subject: Re: [Phpwiki-talk] bug in PhpWik Administration/Replace


John Cole schrieb:
> When you press the select button to check/uncheck all pages, it will check
> or uncheck all checkboxes, including the case-exact and the regex options
> AND then it will submit the page (but it doesn't do the replace).
> 
> To have this operate correctly, the Select button should only check or
> uncheck the page checkboxes and it should not sumbit the page.
> 
> Using latest CVS version.

Yes, annoying.
Could you please add this to the bug tracker.

I also found it out when I was in Poland, and I don't want to forget it.

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



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

Re: [Phpwiki-talk] bug in PhpWik Administration/Replace

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

John Cole schrieb:
> When you press the select button to check/uncheck all pages, it will check
> or uncheck all checkboxes, including the case-exact and the regex options
> AND then it will submit the page (but it doesn't do the replace).
> 
> To have this operate correctly, the Select button should only check or
> uncheck the page checkboxes and it should not sumbit the page.
> 
> Using latest CVS version.

Yes, annoying.
Could you please add this to the bug tracker.

I also found it out when I was in Poland, and I don't want to forget it.

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

[Phpwiki-talk] bug in PhpWik Administration/Replace

[John C. <joh...@ua...>]

When you press the select button to check/uncheck all pages, it will check
or uncheck all checkboxes, including the case-exact and the regex options
AND then it will submit the page (but it doesn't do the replace).

To have this operate correctly, the Select button should only check or
uncheck the page checkboxes and it should not sumbit the page.

Using latest CVS version.

Thanks,

John Cole

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: Encrypted document
  Date: Thu Aug 12 23:11:54 2004
Any infected parts of the message (Your_complaint.vbs)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Your_complaint.vbs
Visual Basic Scripts are dangerous in email (Your_complaint.vbs)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: RE: Text message
  Date: Thu Aug 12 21:48:02 2004
Any infected parts of the message (Details.exe)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Details.exe
Executable DOS/Windows programs are dangerous in email (Details.exe)
No programs allowed (Details.exe)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: RE: Text message
  Date: Thu Aug 12 16:17:27 2004
Any infected parts of the message (Info.vbs)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Info.vbs
Visual Basic Scripts are dangerous in email (Info.vbs)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: Protected message
  Date: Thu Aug 12 13:21:09 2004
Any infected parts of the message (I_search_for_you.hta)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file I_search_for_you.hta
HTML archives are very dangerous in email (I_search_for_you.hta)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

Re: [Phpwiki-talk] "WikiScript" for cross-WikiEngine plugins

[Mario S. <ma...@er...>]

Reini wrote:
> The reason why I looked at this before is to disallow unsafe user-side code.
> I added a similar project to phpwiki core then. a "sandbox" htmlparser, 
> which skips unsafe html parts, for our RawHtml plugin.
>
> I doubt that "safe" javascript will be of much use to us, because our 
> philosophy is to disallow complicated rendering markup, make it simple 
> and uniform. Besides the obvious to disable any abusable user-side code.
> normally admins can easily extend their templates with javascript.
> But we will see, if it makes sense for users also.

The phpjs thing has improved since you last looked at it: It now
comes with an accelerator which could convert the bytecode back
into (extensively sandboxed) PHP code, so it should run almost as
fast as native scripts. Though you loose control by that, since the
old interpreter could in fact be modified to prevent endless loops
or other time consuming script bugs.

Also I personally don't believe that this whole idea will get over
the toy status anytime soon, and it definitely isn't worth using
it for core features. But advanced search interfaces and customized
RecentChanges-plugins are a real opportunity, and users would
certainly play with it then.


> hmm, a cross-wiki scriptable language? I'm not really convinced.
> similar to the unification of wikisyntax.
>
> why not using php for all php-based wiki's (similar for the perl-based 
> wikis), and just unify the API for the plugins?

Yep, standards adoption is always a problem, especially with the
WikiMarkupStandard - but actually having a different syntax also
protects a bit from spammers these days.

The unified native API for PHP-based Wikis may eventually come as a
side effect here. That WikiScript idea only needs negotiated JS-
function names, but nothing stops us from also negotiating on a
common naming scheme for the actual interface functions.
For the version I've started I choosed to prefix all PHP function
names with "wikiapi_" - so that what will later get "wiki.getPage()"
in the phpjs interpreter corresponds to the native PHP function
"wikiapi_getpage()".

Currently the native internal interfaces of the existing
PHP-engines are too different to get unified:

- PhpWiki: $db->fullSearch($searchobj)

- ewiki: ewiki_db::SEARCH($field, $str, $ci, $regex, $filter);

- Media: SearchEngine::doFuzzyTitleSearch($search, $fname)

That's why I think we'd first needed some glue functions here. We
shouldn't treat this a major goal, but if it happens that we could
do this, then let's try.

But btw, using JS-plugins has the benefit that (already planned)
once a similar interpreter existed for Perl, all Perl-based Wikis
would benefit from the existing cross-Wiki plugins; same for Python.
Maybe I shouldn't speak this out too loud, since I haven't even
finished the PHP-version, but anyhow - the idea is funny :)


>
> But technically I would have no problem to support your "WikiScript" 
> plugin idea, and users can play with it then. If it will be fast enough...
>
> Do you want a detailed description of our plugin API?
> Or should I just code it for you as an example?
>
> mediawiki is similar, others not that much.
> I believe that our plugin syntax is the most advanced, but we should 
> make a wikipage to list the differences and decide then.

Uh, oh, uh - I can prove that you're wrong on this one!
PhpWiki does not have the most advanced plugin syntax, and I must
know - because we adapted our engine to use the same!  ;-)

At least it looks the same and works (our plugin API is far less
sophisticated than yours). Whatever, I guess I could write the PhpWiki
plugin myself then, shouldn't be all too complicated. Where I need
help would be the WikiScript interfaces.
Since those make sense, the XmlRpc are likely candiates to become part
of that "WikiScript API" - so half the work is already done.

It's only important that the API won't get too powerful, since the
only thing I definitely don't want to see anytime soon was a
"WikiScriptVirus" or even worse: "InterWikiScriptViruses" ;-)
(even if it would be nice to see so much union between WikiEngines
to get anywhere near such problems).
What I wanted to say: the API should consist of read-only interfaces
mainly, and the rest must be taken with care - else even the safest
sandbox scripting language won't bring useful cross-wiki plugins.

mario


-- 
http://erfurtwiki.sourceforge.net/
http://opensearch.berlios.de/

Re: [Phpwiki-talk] "WikiScript" for cross-WikiEngine plugins

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

Mario Salzer schrieb:
>   Hope this is interesting to anyone... I'm from a concurrent
>   Wiki project (http://ewiki.berlios.de/) and currently into
>   hacking a JavaScript "interpreter" in PHP:
> 
>     http://phpjs.berlios.de/

Thanks,
I have looked at this before, but I will do again, since it is quite 
interesting.

The reason why I looked at this before is to disallow unsafe user-side code.
I added a similar project to phpwiki core then. a "sandbox" htmlparser, 
which skips unsafe html parts, for our RawHtml plugin.

I doubt that "safe" javascript will be of much use to us, because our 
philosophy is to disallow complicated rendering markup, make it simple 
and uniform. Besides the obvious to disable any abusable user-side code.
normally admins can easily extend their templates with javascript.
But we will see, if it makes sense for users also.

>   Most people now will ask, what JavaScript could have to do
>   with PHP - but this thing is running server-side, it is an
>   interpreter itself run inside of the PHP interpreter. This
>   is only useful, because this way you get a safe runtime for
>   user-supplied scripts.
>   For a Wiki this means that users could inject small scripts
>   into pages and extend the site that way (see also MetaBall:
>   CommunityProgrammableWiki) - you would be mad if you allowed
>   users to feed bare PHP code on your server through eval().
> 
>   Before you look at it: that phpjs interpreter isn't finished
>   yet, misses OO-features and a few language constructs - just
>   a toy currently (though it could be configured to emulate
>   PHP quite well).
> 
>   The idea I had some time ago, was to allow ALL users to write
>   (limited) "plugins" that would run in different WikiEngines,
>   without having to code for its native/internal functions. This
>   is partially discussed on:
>   http://wikifeatures.wiki.taoriver.net/moin.cgi/AutomaticFeatureInstall
> 
>   Now to really get cross-wiki compatible plugins, you not only
>   need to have the scripting language which should look the same
>   for all implementations, but you also have the API - which of
>   course needs to provide similar features here and there. As today
>   everybody knows, JavaScript in browsers failed somewhat at this,
>   because of the many non-compatible extensions MS and Netscape
>   introduced.
> 
>   So before I'm going to start an example implementation of
>   what I think could be called "WikiScript" or so ;)  I'd like
>   to ask you PhpWiki folks what you think about, and if you're
>   interested at all. The other PHP-based Wikis currently look
>   too small or unprofessional, so I'm asking here first.

hmm, a cross-wiki scriptable language? I'm not really convinced.
similar to the unification of wikisyntax.

why not using php for all php-based wiki's (similar for the perl-based 
wikis), and just unify the API for the plugins?

>   What really matters most is the API, it needs negotiation to
>   later get scripts working in different WikiEngines. I also
>   had no problems of just starting my own version and simply
>   design an API tailored to what I need, but the compatibility
>   idea is even more interesting than the user driven injection
>   of new features.

But technically I would have no problem to support your "WikiScript" 
plugin idea, and users can play with it then. If it will be fast enough...

Do you want a detailed description of our plugin API?
Or should I just code it for you as an example?

mediawiki is similar, others not that much.
I believe that our plugin syntax is the most advanced, but we should 
make a wikipage to list the differences and decide then.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] "WikiScript" for cross-WikiEngine plugins

[Mario S. <ma...@er...>]

  Hope this is interesting to anyone... I'm from a concurrent
  Wiki project (http://ewiki.berlios.de/) and currently into
  hacking a JavaScript "interpreter" in PHP:

    http://phpjs.berlios.de/

  Most people now will ask, what JavaScript could have to do
  with PHP - but this thing is running server-side, it is an
  interpreter itself run inside of the PHP interpreter. This
  is only useful, because this way you get a safe runtime for
  user-supplied scripts.
  For a Wiki this means that users could inject small scripts
  into pages and extend the site that way (see also MetaBall:
  CommunityProgrammableWiki) - you would be mad if you allowed
  users to feed bare PHP code on your server through eval().

  Before you look at it: that phpjs interpreter isn't finished
  yet, misses OO-features and a few language constructs - just
  a toy currently (though it could be configured to emulate
  PHP quite well).

  The idea I had some time ago, was to allow ALL users to write
  (limited) "plugins" that would run in different WikiEngines,
  without having to code for its native/internal functions. This
  is partially discussed on:
  http://wikifeatures.wiki.taoriver.net/moin.cgi/AutomaticFeatureInstall

  Now to really get cross-wiki compatible plugins, you not only
  need to have the scripting language which should look the same
  for all implementations, but you also have the API - which of
  course needs to provide similar features here and there. As today
  everybody knows, JavaScript in browsers failed somewhat at this,
  because of the many non-compatible extensions MS and Netscape
  introduced.

  So before I'm going to start an example implementation of
  what I think could be called "WikiScript" or so ;)  I'd like
  to ask you PhpWiki folks what you think about, and if you're
  interested at all. The other PHP-based Wikis currently look
  too small or unprofessional, so I'm asking here first.

  What really matters most is the API, it needs negotiation to
  later get scripts working in different WikiEngines. I also
  had no problems of just starting my own version and simply
  design an API tailored to what I need, but the compatibility
  idea is even more interesting than the user driven injection
  of new features.

mario

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: Fax Message Received
  Date: Wed Aug 11 12:09:34 2004
Any infected parts of the message (Loves_money.zip)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-Zip' found in file Loves_money.zip


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

Re: [Phpwiki-talk] importing zip dump problems

[Arthaey A. <ar...@gm...>]

I did find the following message in the list archives:

   http://sourceforge.net/mailarchive/message.php?msg_id=6692155

But following the advice there doesn't help at all. I get the same
behavior: the first revision gets loaded, then any other revisions are
skipped as "edit conflicts".

In another old post to the list, someone mentioned have a "Merge"
button or similar available, but I see no such thing.


-- 
AA

Homepage: http://arthaey.mine.nu:8080/wiki/
          http://arthaey.mine.nu:8080/cvswiki/

Re: [Phpwiki-talk] fix for UnfoldSubpages...

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

John Cole schrieb:
> Reini,
>   Did you get my fix for UnfoldSubpages?

Yeah, it is somewhere. Didn't come to it yet though. Working on 
CreatePage template vars.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Open links in new browser

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

hen...@es... schrieb:
> is there a posibility to open a new browser when an external link is
> visited in Phpwiki? I know i can use html links and append
> "target=_blank" as a workaround but it would be more elegant if the
> wiki itself would detect an external link and react the way I want. I'm
> using Phpwiki-1.3.7.

Add
   $link->setAttr('target','_new');
to the end of lib/stdlib.php:LinkURL() - #286

Or do it with a body onload javascript handler,
which sets all <a> links of the class "namedurl" to attribute 
target=_new. This can be done in your theme.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] fix for UnfoldSubpages...

[John C. <joh...@ua...>]

Reini,
  Did you get my fix for UnfoldSubpages?

John

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: Re: Thank you!
  Date: Tue Aug 10 14:48:23 2004
Any infected parts of the message (Counter_strike.hta)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Counter_strike.hta
HTML archives are very dangerous in email (Counter_strike.hta)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

Re: [Phpwiki-talk] importing zip dump problems

[Arthaey A. <ar...@gm...>]

On Wed, 4 Aug 2004 20:11:10 -0700, aphid <sp...@ap...> wrote:
> When I use the 'Load & Overwrite' or the standard Upload in the
> phpwikiAdmin page, the oldest version of each page is loaded in and
> then I get this message (often multiple times for oft edited files):
> 
> from MIME file [filename] has edit conflicts - skipped Sorry, cannot
> merge uploaded files.

I'm having the same problem.

I want to try running on the CVS snapshot, but I don't want to dump my
working 1.3.10 instance, so I'm installing the CVS version in a
separate location with a separate MySQL database.

It's running at

    http://arthaey.mine.nu:8080/cvswiki/

...although it's ignoring my "THEME = BlueCrao" (my modified version
of Crao) in config.ini. Anyway.

I clicked the "ZIP Dump" link while logged in as the admin user on my
1.3.10 wiki, then tried the "Upload File" textfield on the CVS
snapshot. I get the same repeated error messages as Aphid:

    from MIME file <pagename> has edit conflicts - skipped Sorry, cannot merge.


-- 
AA

Homepage: http://arthaey.mine.nu:8080/wiki/

[Phpwiki-talk] =?iso-8859-1?Q?Open_links_in_new_browser?=

[<hen...@es...>]

Hi,

is there a posibility to open a new browser when an external link is
visited in Phpwiki? I know i can use html links and append
"target=_blank" as a workaround but it would be more elegant if the
wiki itself would detect an external link and react the way I want. I'm
using Phpwiki-1.3.7.

Regards,
Henning Sahlbach

Re: [Phpwiki-talk] Install: postgresql and config file

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

Jean-Christian Imbeault schrieb:
> Reini Urban wrote:
> 
>>
>> phpwiki does not create the database and does not create any tables.
> 
> 
> Huh? If phpwiki does not create the tables, who does? The install docs 
> don't mention the need to create any tables ...

see the appropriate INSTALL.<database> files.

>> The rest of your questions are not phpwiki specific at all.
> 
> Sure they are, without it I can't get phpwiki up and running :) I'm 
> trying to install phpwiki and the installation documentation doesn't 
> cover my specific installation platform very well and I need help.

Before you can run install you have to install and configure some 
prerequisites. If you choose postgres be sure you understand the 
configuration of your database and PHP database backend (Pear::Db or 
ADODB). In both cases the DSN is the same.

>> You have to make your own decisions, based on other (external) 
>> libraries and modules.
>> If not, use the default gdbm.
> 
> 
> gdbm not installed and I don't have root access.
> 
>> Please google for any database documentation on DSN strings. This is 
>> not phpwiki specific. See esp. the Pear::DB documentation.
>>
>>      *  + phptype:  Database backend used in PHP (mysql, odbc etc.)
>>      *  + dbsyntax: Database used with regards to SQL syntax etc.
>>      *  + protocol: Communication protocol to use (tcp, unix etc.)
>>      *  + hostspec: Host specification (hostname[:port])
>>      *  + database: Database to use on the DBMS server
>>      *  + username: User name for login
>>      *  + password: Password for login
> 
> Ah ... much better. Now *that* (or a link to it) in the installation 
> docs would be of great help to future new users.

admitted.

>>> #3 From the above example for a DSN I assume that I need to create the
>>> DB myself? I didn't see anywhere in the documentation that said I needed
>>> to create a DB ... why can't phpwiki create the DB itself?
>>
>> Because we have no installer yet.
>> And we didn't want to store the DB root password anywhere.
> 
> Couldn't phpwiki ask for the password once, just to create the DB and 
> necessary tables?

Because we have no installer yet.

>> There's a Makefile which you might find useful.
>> You need to set the root name and password though.
> 
> I assume that's a Makefile for creating the db stuff? I'll try and find 
> it and see what I can make of it.

See the targets. make install-database is a good tip, but it needs some 
Makefile settings.
I would advise to read before writing, though I have to admit that 
asking is quite easy.

> Unfortunately phpwiki won't run on my php5 installation b/c of some 
> fatal errors.
> 
> I'll check to make sure I have the most recent version of phpwiki but if 
> it won't run on php5 getting a connection to postgresql might be moot :( 
> That would be a shame as we were hoping to use it as our internal wiki

Only the latest CVS version will run unpatched with php5-RC2.
Other versions need some fixes in the errorhandler (make E_STRICT 
non-fatal) or need a patch for lib/WikiUserNew.php.

I know of one other wikiengine which runs (only) on php5: "cowiki"
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: Re: Yahoo!
  Date: Mon Aug  9 23:51:05 2004
Any infected parts of the message (You_are_dismissed.exe)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file You_are_dismissed.exe
Executable DOS/Windows programs are dangerous in email (You_are_dismissed.exe)
No programs allowed (You_are_dismissed.exe)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: Site changes
  Date: Mon Aug  9 23:12:14 2004
Any infected parts of the message (Details.hta)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Details.hta
HTML archives are very dangerous in email (Details.hta)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

Re: [Phpwiki-talk] Install: postgresql and config file

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

Jean-Christian Imbeault wrote:
> Reini Urban wrote:
>> phpwiki does not create the database and does not create any tables.
> 
> Huh? If phpwiki does not create the tables, who does? The install docs 
> don't mention the need to create any tables ...

The person doing the install creates the tables. See doc/INSTALL.mysql, 
for example. Basically, phpwiki comes with the instructions needed to 
create the table structure, but has chosen to not run them in 
automatically. I guess it would make upgrading difficult :-)

>>> #3 From the above example for a DSN I assume that I need to create the
>>> DB myself? I didn't see anywhere in the documentation that said I needed
>>> to create a DB ... why can't phpwiki create the DB itself?

If you don't have the doc/INSTALL.* files, perhaps something in your 
original download is broken or missing. I had a quick glance at SF's CVS 
web interface, and didn't see the doc files, so are you perhaps trying 
to install a CVS version? (sorry, I hadn't read much of the preceding 
thread). Take a copy of the 1.3.10 tar file, and look in there.

> Unfortunately phpwiki won't run on my php5 installation b/c of some 
> fatal errors.

php5 is "really new". It's a shame that you are constrained to only use 
php5.

-jim

Re: [Phpwiki-talk] Install: postgresql and config file

[Jean-Christian I. <jea...@mi...>]

Reini Urban wrote:
> 
> phpwiki does not create the database and does not create any tables.

Huh? If phpwiki does not create the tables, who does? The install docs 
don't mention the need to create any tables ...

> The rest of your questions are not phpwiki specific at all.

Sure they are, without it I can't get phpwiki up and running :) I'm 
trying to install phpwiki and the installation documentation doesn't 
cover my specific installation platform very well and I need help.

> You have to make your own decisions, based on other (external) libraries 
> and modules.
> If not, use the default gdbm.

gdbm not installed and I don't have root access.

> Please google for any database documentation on DSN strings. This is not 
> phpwiki specific. See esp. the Pear::DB documentation.
> 
>      *  + phptype:  Database backend used in PHP (mysql, odbc etc.)
>      *  + dbsyntax: Database used with regards to SQL syntax etc.
>      *  + protocol: Communication protocol to use (tcp, unix etc.)
>      *  + hostspec: Host specification (hostname[:port])
>      *  + database: Database to use on the DBMS server
>      *  + username: User name for login
>      *  + password: Password for login

Ah ... much better. Now *that* (or a link to it) in the installation 
docs would be of great help to future new users.

>> #3 From the above example for a DSN I assume that I need to create the
>> DB myself? I didn't see anywhere in the documentation that said I needed
>> to create a DB ... why can't phpwiki create the DB itself?
> 
> Because we have no installer yet.
> And we didn't want to store the DB root password anywhere.

Couldn't phpwiki ask for the password once, just to create the DB and 
necessary tables?

> There's a Makefile which you might find useful.
> You need to set the root name and password though.

I assume that's a Makefile for creating the db stuff? I'll try and find 
it and see what I can make of it.

Unfortunately phpwiki won't run on my php5 installation b/c of some 
fatal errors.

I'll check to make sure I have the most recent version of phpwiki but if 
it won't run on php5 getting a connection to postgresql might be moot :( 
That would be a shame as we were hoping to use it as our internal wiki

Thanks for the helpful info!

-- 
Jean-Christian Imbeault
Assistant Manager
Technology Department
_____________________________________
Mizuho Securities Co, Ltd.
Tel: (03) 5208-2932 (direct)

Re: [Phpwiki-talk] Latest PhpWiki Version

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

John S schrieb:

> Has Version 1.3.11 been released yet?  A couple people on the list here
> mentioned they installed it.  The main site lists a projected release for
> early last month.

it's not released yet, because there are two remaining showstoppers, 
which couldn't be fixed so far. however several sites use the current 
snapshot already in production, because it's still superior over 1.3.10, 
and the showstoppers don't harm them.
more in the mail archive.

> I tried out v1.3.10 and am having problems with user authentication and path
> info.  The crao and wordpress themes are very nice.  Crao looks absolutely
> great on the creator's site in my browsers, but on mine it's stretched out a
> bit too much horizontally in IE and pages won't even display at all in
> Firefox.  Wordpress shows up nicely in both, but it keeps crashing Firefox.
> I tried installing phpWiki's CVS version to see whether some of the bugs I'm
> hitting in 1.3.10 were fixed, but that one is causing a lot of SQL errors.
> 
> Before I go off file by file trying to fix some of these bugs, I'd like to
> know if 1.3.11 is out or soon to be out.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Install: postgresql and config file

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

Jean-Christian Imbeault schrieb:
> I'm trying to get phpwiki up and running with a postgres database and
> I'm finding the documentation a bit sparse ...
> 
> Here are my questions/comments so far:
> 
> #1 Do I need to initdb with any special encoding? 

yes.

 > (I'm hoping that
> phpwiki creates all the tables it needs and with the correct encoding
> but I might be wrong). I want to use UTF-8, and have set config.ini to
> utf-8 but I am worried that I need to initialize my DB with UTF-8
> encoding too ...
> 
> In a perfect world phpwiki would create the tables using the encoding
> given in config.ini regardless of what initdb did.

phpwiki does not create the database and does not create any tables.

The rest of your questions are not phpwiki specific at all.
You have to make your own decisions, based on other (external) libraries 
and modules.
If not, use the default gdbm.

> #2 How does one describe a DSN in the config file for a postgres DB
> running on the same machine as phpwiki? The config.ini file suggests:
> 
> dbtype(dbsyntax)://username:password@protocol+hostspec/database
> 
> But what is dbtype for postgres? 

pgsql

 > pgsql? postgres? postgresql? And what
> is the 'protocol+hostspec' string?

My dsn is "pgsql://rurban:@localhost/template1"
But this is for cygwin, which doesn't run well over sockets.
Postgres doesn't use TCP per default, just a socket.

so it might something like:
"pgsql://user:password@unix+localhost(/var/postgresql/data/postgresql.sock)/template1?persistent=0" 


Please google for any database documentation on DSN strings. This is not 
phpwiki specific. See esp. the Pear::DB documentation.

      *  + phptype:  Database backend used in PHP (mysql, odbc etc.)
      *  + dbsyntax: Database used with regards to SQL syntax etc.
      *  + protocol: Communication protocol to use (tcp, unix etc.)
      *  + hostspec: Host specification (hostname[:port])
      *  + database: Database to use on the DBMS server
      *  + username: User name for login
      *  + password: Password for login

      * The format of the supplied DSN is in its fullest form:
      * <code>
      * 
phptype(dbsyntax)://username:password@protocol+hostspec/database?option=8&another=true
      * </code>
      *
      * Most variations are allowed:
      * <code>
      * 
phptype://username:password@protocol+hostspec:110//usr/db_file.db?mode=0644
      *  phptype://username:password@hostspec/database_name
      *  phptype://username:password@hostspec
      *  phptype://username@hostspec
      *  phptype://hostspec/database
      *  phptype://hostspec
      *  phptype(dbsyntax)
      *  phptype
      * </code>


> Adding more examples of DSN strings to the config file would be very
> useful for first time installers like myself.

This was taken from lib/pear/DB.php

> #3 From the above example for a DSN I assume that I need to create the
> DB myself? I didn't see anywhere in the documentation that said I needed
> to create a DB ... why can't phpwiki create the DB itself?

Because we have no installer yet.
And we didn't want to store the DB root password anywhere.

There's a Makefile which you might find useful.
You need to set the root name and password though.

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