phpwiki-talk

[Phpwiki-talk] Rookie question

[Julia G. <Jul...@tp...>]

Please indulge a rookie with a deadline and a huge gap in server technology
knowledge...I have downloaded phpwiki and set up a test wiki for a project
and now need to launch the app on a new web site for a professional COP.  I
need the app on another server - not the test server - may I simply move it
(drag it onto the public server) or must I download a whole 'nother
installation onto the new server?  And then configure it and just copy over
the design interface?  I appreciate the forum and any advice.  I am pretty
much a front-end designer without much backend support.

Julia Gregory
Jul...@tp...

Re: [Phpwiki-talk] config in db

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

Oliver Betz schrieb:
> Reini Urban wrote:
>>Why not storing the index.php configuration in the database, table 
>>config, editable only by the admin?
> 
> because it would be less transparent. As long as the config is in a 
> plain text file, I can:
> 
> - modify it without special tools,
> - look at it (check it) as a whole,
> - compare different configs with a text diff tool and
> - merge settings e.g. when changing more thn one Wiki.
> 
> I guess there are more reasons.
> 
> Hiding configs in databases is one of the the disadvantages of the 
> windows way.
> 
> As long as the config is php, one can add also special processing if 
> he/she wants.

Persuaded.
But I would like to seperate the config from the startup file. 
lib/config sanifies the config settings, so PHPWIKI_DIR."/config.php" 
would be fine.

>>This is much easier to install and maybe easier to maintain then the 
> 
> Maintenance is harder, IMO.
> 
> In which manner do you think the installation will be easier than 
> now?

Most of the local apache/php settings could be calculated automatically.
One should only define if e.g. USE_PATH_INFO = true or false, and the 
appropriate VIRTUAL_PATH, DATA_PATH settings can be calculated.
Also applied .htaccess samples

Same for database and authorization settings, which depend on the 
available libraries and services.

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

Re: [Phpwiki-talk] config in db

[Bob A. <apt...@cy...>]

Hi,

On Mon, 26 Jan 2004 09:05:49 +0100 "Oliver Betz" <ob...@de...> wrote:

> Reini Urban wrote:
> 
> > Why not storing the index.php configuration in the database, table 
> > config, editable only by the admin?
> 
> because it would be less transparent. As long as the config is in a 
> plain text file, I can:
> 
> - modify it without special tools,
> - look at it (check it) as a whole,
> - compare different configs with a text diff tool and
> - merge settings e.g. when changing more thn one Wiki.
> 
> I guess there are more reasons.

FWIW, eGroupware allows you to change its configuration from within the
application (e.g. read config.php, make changes, then save the changes
along with a backup of the original configuration.) With proper
directory permissions and good authentication this shouldn't be too
difficult.

> Hiding configs in databases is one of the the disadvantages of the 
> windows way.
> 
> As long as the config is php, one can add also special processing if 
> he/she wants.
> 
> > This is much easier to install and maybe easier to maintain then the 
> 
> Maintenance is harder, IMO.

I don't know if my experience is typical but I spend most of my effort
trying to initially configure a PHP/MySQL application. Once it's
installed and running I rarely have to mess with it (not counting
administrative tasks like setting permissions, ACLs, etc. -- but that's
not the case we're talking about here.)

> In which manner do you think the installation will be easier than 
> now?

I'd use eGroupware as an example, though I don't think PhpWiki is all
that difficult to set up compared to similar applications (try sorting
out Tiki's permissions sometime - gruesome!)

-- Bob

Re: [Phpwiki-talk] config in db

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

Reini Urban wrote:

> Why not storing the index.php configuration in the database, table 
> config, editable only by the admin?

because it would be less transparent. As long as the config is in a 
plain text file, I can:

- modify it without special tools,
- look at it (check it) as a whole,
- compare different configs with a text diff tool and
- merge settings e.g. when changing more thn one Wiki.

I guess there are more reasons.

Hiding configs in databases is one of the the disadvantages of the 
windows way.

As long as the config is php, one can add also special processing if 
he/she wants.

> This is much easier to install and maybe easier to maintain then the 

Maintenance is harder, IMO.

In which manner do you think the installation will be easier than 
now?

Oliver

[Phpwiki-talk] =?ISO-2022-JP?B?GyRCTCQ+NUJ6OS05cCIoJDRNOztxQ1ckNyReJDkbKEI=?=

[<sun...@ya...>]

<Ž–‹ÆŽÒ><‘—MŽÒ>
‡ŠƒTƒ“ƒtƒ@ƒCƒiƒ“ƒX
ƒ[ƒ‹‚Ì•K—v‚È‚¢•û‚Í
sun...@ya...
‚܂ŁB

‡ŠƒTƒ“ƒtƒ@ƒCƒiƒ“ƒX‚Å‚·B
‘S‘‘¦“úƒXƒs[ƒh—ZŽ‘B
‚P–œ‰~`‚P‚O‚O–œ‰~ˆÈã‰Â”\‚Å‚·B
Å¬ŒÀ‚Ì‹à—˜‚ʼn^—p‚Å‚«‚Ü‚·B
“Œ‹ž“s’mŽ–”F‰ÂÁ”ïŽÒ‹à—Z‚Å‚·
‚²—ZŽ‘‚²Šó–]‚Ì•û‚Í‚±‚¿‚ç‚Ü‚Å
http://www.interq.or.jp/cool/webmail/sunfaina
‚¨“d˜b‚Å‚àŽó‚¯•t‚¯‚¢‚½‚µ‚Ü‚·B
0359501686(‘ã)
‚¨˜l‚сBŠF—l‚̃AƒhƒŒƒX‚ÍŽûWƒ\ƒtƒg‚ðŠˆ—p‚µA
ŽûW‚³‚¹‚Ä’¸‚«‚Ü‚µ‚½B

[Phpwiki-talk] pending updates

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

$ ssh -v  cvs.phpwiki.sf.net cvs commit
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to cvs.phpwiki.sf.net [66.35.250.207] port 22.
debug1: connect to address 66.35.250.207 port 22: Connection refused
ssh: connect to host cvs.phpwiki.sf.net port 22: Connection refused

cvs is down again for one hour now.
I cannot wait anymore for my pending updates today,
I cannot even do a diff. I'll try tommorrow again.

It will fix the following issues:

* changed stored pref representation as before.
   the array of objects is 1) bigger and 2)
   less portable. If we would import packed pref
   objects and the object definition was changed, PHP would fail.
   This doesn't happen with an simple array of non-default values.
* use $prefs->retrieve and $prefs->store methods, where retrieve
   understands the interim format of array of objects also.
* simplified $prefs->get() and fixed $prefs->set()
* added $user->_userid and class '_WikiUser' portability functions
* fixed $user object ->_level upgrading, mostly using sessions.
   this fixes yesterdays problems with loosing authorization level.
* fixed WikiUserNew::checkPass to return the _level
* fixed WikiUserNew::isSignedIn
* added explodePageList to class PageList, support sortby arg
* fixed UserPreferences for WikiUserNew
* fixed WikiPlugin for empty defaults array
* UnfoldSubpages: added pagename arg

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

Re: [Phpwiki-talk] Test site is broken

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

Ah, /test/ !
It was me, but I was looking in the demo dir to fix the index.php which 
gets broken on every index.php commit.

I'll wait until cvs.phpwiki.sf.net lets me in again and fix it asap.
Everything works fine for me now.


Steve Wainstead schrieb:
> The test site is down this morning:
> 
> *Fatal error*: Cannot instantiate non-existent class: wikiuser in 
> */home/groups/p/ph/phpwiki/htdocs/test/lib/loadsave.php* on line *796*
> 
> URL:
> http://phpwiki.sourceforge.net/test/
> 
> Just a reminder that the test site is a daily build-and-smoke test.. 
> every morning (5:55am EST) a cron job drops/creates all tables and does 
> a clean CVS checkout of all PhpWiki source code. The first person to hit 
> the URL causes the database to load.
> 
> I should set up a way to forward the cron job output to the talk list.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Test site is broken

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

The test  site is down this morning:

Fatal error: Cannot instantiate non-existent class: wikiuser in 
/home/groups/p/ph/phpwiki/htdocs/test/lib/loadsave.php on line 796

URL:
http://phpwiki.sourceforge.net/test/

Just a reminder that the test site is a daily build-and-smoke test.. 
every morning (5:55am EST) a cron job drops/creates all tables and does 
a clean CVS checkout of all PhpWiki source code. The first person to 
hit the URL causes the database to load.

I should set up a way to forward the cron job output to the talk list.

~swain

[Phpwiki-talk] daily demo cvs update?

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

How is our daily cvs up to the demo site done?
I see no CVS subdirs, so I cannot fix index.php beforehand.
Or is it disabled anyway?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] config in db

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

Joby Walker schrieb:
> I agree completely.
> 
> There are just far too many config settings to continue the way we are 
> going. We can also use the database keep historical config settings to 
> allow for the roll back of configuration settings.  It should help 
> simplify the config/* files (which I need to get back to...).

Ok. But before I do the config stuff (which I really want to do now, 
because I don't dare to commit the new index.php for my new config 
settings, which requires a manual hack in the demo site after the daily 
automatic checkout), I'll implement proper page permissions.

I already changed phpwiki.sf.net/demo/index.php to reallow USE_PATH_INFO 
and all the supported languages, even if the database got raided.

The current new user scheme is quite strict.
e.g. previously ALLOW_ANON_USER = false meant that anon users cannot 
edit, but may browse. With ENABLE_USER_NEW and ALLOW_ANON_USER = false 
he may even not browse which is needed to disable browse PagePermissions 
for a certain user.
So I will implement PagePermissions to get rid of ALLOW_ANON_USER = 
false, which is quite annoying and check permissions per page resp. 
action and user and optionally group.

> Reini Urban wrote:
>> Hi (Joby)
>> Why not storing the index.php configuration in the database, table 
>> config, editable only by the admin?
>>
>> This is much easier to install and maybe easier to maintain then the 
>> current file based solution. then we will be able to have a tiny 
>> index.php. lib/config.php will then load and verify the config 
>> settings, using config/*
>>
>> The only problem I see is that without working database connection one 
>> cannot edit the config...
>> maybe use a single dba/gdbm/sqlite/flat-file file therefore.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] SiteMap regular expression exclude list

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

Thanks,

Finally I debugged my cygwin openssh problem with the cvs server. Sigh!

It's applied to the current cvs and should be in tomorrows nightly tarball
   http://phpwiki.sf.net/nightly/phpwiki.nightly.tar.gz
and at the demo site
   http://phpwiki.sf.net/demo/

Alec Thomas schrieb:
> This is a patch against phpwiki-1.3.7 allows Perl regular expressions
> in SiteMap exclude lists.
> eg.
> 
> 	<?plugin SiteMap
> 		page=SwapOff
> 		direction=forward
> 		exclude=WikiWikiWeb,(?:Category|Topic).* noheader=1
> 	?>
> 
> It is backwards compatible unless old exclude lists, and therefore Wiki
> page names, contain regular expression characters.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] SiteMap regular expression exclude list

[Alec T. <li...@sw...>]

Hello,

This is a patch against phpwiki-1.3.7 allows Perl regular expressions
in SiteMap exclude lists.

eg.

	<?plugin SiteMap
		page=SwapOff
		direction=forward
		exclude=WikiWikiWeb,(?:Category|Topic).* noheader=1
	?>

It is backwards compatible unless old exclude lists, and therefore Wiki
page names, contain regular expression characters.

Regards,
Alec

--
Evolution: Taking care of those too stupid to take care of themselves.

[Phpwiki-talk] SF.net CVS is offline

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

http://sitedocs.sourceforge.net/status/support_sitestatus.html

(  2004-01-23 10:06:09 - Project CVS Service )   Developer CVS access will be 
offline for 2004-01-23, continuing in to the weekend, to permit the resync of 
data to complete; it was previously determined that developer CVS access had a 
severe impact on the speed of our data resync. Developer CVS access will be 
restored immediately after the sync completes. Your patience is appreciated. 
Questions and concerns may be directed to the SF.net team via Support Request.

jbw

Re: [Phpwiki-talk] stacked or strict or pre-defined password method order?

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

Me too, I can't even get a cvs update to work.

jbw

Reini Urban wrote:
> PS: maybe it's just me, but the cvs.sf.net ssh connection is very 
> unstable in the last weeks, and I cannot do
> cvs up, cvs diff or cvs commit lib/WikiUserNew.php.
> 
> and the host keys did change almost every day, which is a pain with 
> openssh.
> 

[Phpwiki-talk] Need to host child porn, illegal content, Spam advert site

[<ip...@en...>]

Need to host child porn, illegal content, Spam advert site? Try www.hopone.net you will be able to host anything you desire.

You can get fresh stolen dumps here:

http://www.shadowcrew.com/phpBB2/viewtopic.php?t=636

Credit cards with cvv2 information are available here:

http://www.shadowcrew.com/phpBB2/viewtopic.php?t=409

Our site will be usefull for the those who want to wash their money also :) (If you don't want to pay taxes or you need to buy something illegal like weapons or drugs).

Fresh paypal accounts here:

http://www.shadowcrew.com/phpBB2/viewtopic.php?t=553

Only using our site you can get every detail of any US citizen including SSN number:

http://www.shadowcrew.com/phpBB2/viewtopic.php?t=701

Fresh eBay accounts for a low price available as well:

http://www.shadowcrew.com/phpBB2/viewtopic.php?t=290


You can order by phone: : +1-703-547-2000.


Best regards,
www.shadowcrew.com

Re: [Phpwiki-talk] config in db

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

I agree completely.

There are just far too many config settings to continue the way we are going. 
We can also use the database keep historical config settings to allow for the 
roll back of configuration settings.  It should help simplify the config/* files 
(which I need to get back to...).

jbw

Reini Urban wrote:

> Hi (Joby)
> Why not storing the index.php configuration in the database, table 
> config, editable only by the admin?
> 
> This is much easier to install and maybe easier to maintain then the 
> current file based solution. then we will be able to have a tiny 
> index.php. lib/config.php will then load and verify the config settings, 
> using config/*
> 
> The only problem I see is that without working database connection one 
> cannot edit the config...
> maybe use a single dba/gdbm/sqlite/flat-file file therefore.

Re: [Phpwiki-talk] stacked or strict or pre-defined password method order?

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

Since I liked all solutions I implemented all auth methods and policies, 
with the correct auth method dispatchers.

It worked okay, until I disallowed ALLOW_ANON_USER (and/or ALLOW_BOGO_USER).
since then we have no user object and therefore no pref object.
This will need some more work.

I added yet another auth policy "old", which mimics the current 
behaviour, and tries to be smart with the given auth options and 
available php functions.

Attached is the corresponding index.php excerpt, and the new classes, 
without the minor neccessary main.php changes.
developers: please review it.

PS: maybe it's just me, but the cvs.sf.net ssh connection is very 
unstable in the last weeks, and I cannot do
cvs up, cvs diff or cvs commit lib/WikiUserNew.php.

and the host keys did change almost every day, which is a pain with openssh.

Reini Urban schrieb:
> Hi
> I'm just finishing the new wikiuser authcode and came to this question:
> 
> In the current code the authentification methods are "stacked", that 
> means, that the methods are searched in a predefined search order
> (e.g. Anon or Bogo or HomePage password => ldap => imap => http_auth).
> 
> The first method which returns true is taken. False is only returned if 
> all defined methods will fail.
> 
> With my new code we allow even more auth methods:
>   internal db, external db, file
> 
> Now how should the admin configure his authentification:
> 1)  Should he be able to define the search order?
> 2)  Should he be able to define stacked (policy c) or strict (policy b) 
> or pre-defined method order (policy a)?
> 
> The problem is that the user may exist with the current method but the 
> password is wrong, which brings him to the next method. This might not 
> be wished for certain auth methods were the username and password must 
> match and no other methods may be tried if the username exists in the 
> databse but with the wrong password. For example the database password 
> is wrong, but a file password matches is ok.
> 
> Currently the order of first three methods is fixed:
>     Anon if defined, Bogo if defined, User if defined.
> Those three methods are stacked.
> 
> With the new methods in the new auth classes (called if 
> ALLOW_USER_PASSWORDS is defined and the previous methods failed) one 
> could define policy c: a stacked scheme ("try next method if it fails"), 
> or policy b: a stricter scheme ("check user and if she exists the 
> password, on failure try no other methods").
> To make thing even more complicate my current code makes use of only one 
> pre-defined external auth method (policy a), which simply upgrades the 
> user class in the constructor, and not in the checkUser() or 
> UserExists() methods.
> 
> How to define the auth policies in index.php?
> 
> One could easily define a new config variable like
>   define('FAIL_ON_WRONG_PASSWORD',true);
> which defines the strict scheme, and if not defined
> the stacked scheme will be used.
> The simple problem is that then we will have to define one more method 
> for all user classes:
>   $user->UserExists():
> Currently we need only ->checkPass() and optionally ->storePass().
> 
> The code for a simple predefined scheme, (not-stacked) scheme is now 
> ready, were only one auth method is predefined, for all users.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] config in db

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

Hi (Joby)
Why not storing the index.php configuration in the database, table 
config, editable only by the admin?

This is much easier to install and maybe easier to maintain then the 
current file based solution. then we will be able to have a tiny 
index.php. lib/config.php will then load and verify the config settings, 
using config/*

The only problem I see is that without working database connection one 
cannot edit the config...
maybe use a single dba/gdbm/sqlite/flat-file file therefore.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] stacked or strict or pre-defined password method order?

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

For actual authentication, I think we should avoid the stacked system.  But we 
probably want to keep the stacking of Anon and Bogo if they are defined.

jbw

Reini Urban wrote:

> Hi
> I'm just finishing the new wikiuser authcode and came to this question:
> 
> In the current code the authentification methods are "stacked", that 
> means, that the methods are searched in a predefined search order
> (e.g. Anon or Bogo or HomePage password => ldap => imap => http_auth).
> 
> The first method which returns true is taken. False is only returned if 
> all defined methods will fail.
> 
> With my new code we allow even more auth methods:
>   internal db, external db, file
> 
> Now how should the admin configure his authentification:
> 1)  Should he be able to define the search order?
> 2)  Should he be able to define stacked (policy c) or strict (policy b) 
> or pre-defined method order (policy a)?
> 
> The problem is that the user may exist with the current method but the 
> password is wrong, which brings him to the next method. This might not 
> be wished for certain auth methods were the username and password must 
> match and no other methods may be tried if the username exists in the 
> databse but with the wrong password. For example the database password 
> is wrong, but a file password matches is ok.
> 
> Currently the order of first three methods is fixed:
>     Anon if defined, Bogo if defined, User if defined.
> Those three methods are stacked.
> 
> With the new methods in the new auth classes (called if 
> ALLOW_USER_PASSWORDS is defined and the previous methods failed) one 
> could define policy c: a stacked scheme ("try next method if it fails"), 
> or policy b: a stricter scheme ("check user and if she exists the 
> password, on failure try no other methods").
> To make thing even more complicate my current code makes use of only one 
> pre-defined external auth method (policy a), which simply upgrades the 
> user class in the constructor, and not in the checkUser() or 
> UserExists() methods.
> 
> How to define the auth policies in index.php?
> 
> One could easily define a new config variable like
>   define('FAIL_ON_WRONG_PASSWORD',true);
> which defines the strict scheme, and if not defined
> the stacked scheme will be used.
> The simple problem is that then we will have to define one more method 
> for all user classes:
>   $user->UserExists():
> Currently we need only ->checkPass() and optionally ->storePass().
> 
> The code for a simple predefined scheme, (not-stacked) scheme is now 
> ready, were only one auth method is predefined, for all users.

Re: [Phpwiki-talk] stacked or strict or pre-defined password method order?

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

Reini Urban wrote:

> In the current code the authentification methods are "stacked", that 
> means, that the methods are searched in a predefined search order
> (e.g. Anon or Bogo or HomePage password => ldap => imap => http_auth).

I still didn't understand how to create a home page password and how 
to store a password there...

> The first method which returns true is taken. False is only returned if 
> all defined methods will fail.
> 
> With my new code we allow even more auth methods:
>    internal db, external db, file

What means "file" - a textual password file?

I hope that there will be a method working without sql, since many 
(cheap) hosting services don't offer sql - one of the reasons I use 
PhpWiki.

> Now how should the admin configure his authentification:
> 1)  Should he be able to define the search order?
> 2)  Should he be able to define stacked (policy c) or strict (policy b) 
> or pre-defined method order (policy a)?

I guess a combined method will rarely be necessary. If there is 
already some kind of authentification, why shouldn't _all_ accounts 
use it? But it wouldn't hurt, if it's safe:

> The problem is that the user may exist with the current method but the 
> password is wrong, which brings him to the next method. This might not 

IMHO if the user was found with the first method, no other methods 
should be tried.

Regarding the implementation, I don't know enough about PHP to 
contribute something useful.

[...]

> The code for a simple predefined scheme, (not-stacked) scheme is now 
> ready, were only one auth method is predefined, for all users.

This would be fine for most cases, IMHO.

Oliver

[Phpwiki-talk] bug: Russian string

[Tony L. <la...@is...>]

Spotted what seems to be a very strange bug. 
Confirmed that Russian small letters "Ye" and "l", 
input together (Ye + l) makes the system generate 
<u></u> on either side.  
I was able to offset it by putting ~ in front. 
Very strange. 


-- 
Tony Laszlo
irc://irc.freenode.net/issho
http://www.issho.org/LaszloBlog

[Phpwiki-talk] stacked or strict or pre-defined password method order?

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

Hi
I'm just finishing the new wikiuser authcode and came to this question:

In the current code the authentification methods are "stacked", that 
means, that the methods are searched in a predefined search order
(e.g. Anon or Bogo or HomePage password => ldap => imap => http_auth).

The first method which returns true is taken. False is only returned if 
all defined methods will fail.

With my new code we allow even more auth methods:
   internal db, external db, file

Now how should the admin configure his authentification:
1)  Should he be able to define the search order?
2)  Should he be able to define stacked (policy c) or strict (policy b) 
or pre-defined method order (policy a)?

The problem is that the user may exist with the current method but the 
password is wrong, which brings him to the next method. This might not 
be wished for certain auth methods were the username and password must 
match and no other methods may be tried if the username exists in the 
databse but with the wrong password. For example the database password 
is wrong, but a file password matches is ok.

Currently the order of first three methods is fixed:
     Anon if defined, Bogo if defined, User if defined.
Those three methods are stacked.

With the new methods in the new auth classes (called if 
ALLOW_USER_PASSWORDS is defined and the previous methods failed) one 
could define policy c: a stacked scheme ("try next method if it fails"), 
or policy b: a stricter scheme ("check user and if she exists the 
password, on failure try no other methods").
To make thing even more complicate my current code makes use of only one 
pre-defined external auth method (policy a), which simply upgrades the 
user class in the constructor, and not in the checkUser() or 
UserExists() methods.

How to define the auth policies in index.php?

One could easily define a new config variable like
   define('FAIL_ON_WRONG_PASSWORD',true);
which defines the strict scheme, and if not defined
the stacked scheme will be used.
The simple problem is that then we will have to define one more method 
for all user classes:
   $user->UserExists():
Currently we need only ->checkPass() and optionally ->storePass().

The code for a simple predefined scheme, (not-stacked) scheme is now 
ready, were only one auth method is predefined, for all users.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Problems with phpwiki

[Tony L. <la...@is...>]

On Tue, 20 Jan 2004 17:58:26 +0100
"Joaquin Ayllon Moreno" <ja...@re...> wrote:

> I have downloaded a module Phpwiki for Postnuke from http://stuff.kling.nu

That module is a bit buggy. 
Best to use the forum at that site. Last time I looked, there weren't many answers for the questions being raised, though. :(
You might also look for the older module. You can see it functioning at http://www.issho.org/ among other places. 
It also has problems and is not being maintained, apparently. But use what you can get to work, right? :)

Good Luck!

-- 
Tony Laszlo
irc://irc.freenode.net/issho
http://www.issho.org/LaszloBlog

Re: [Phpwiki-talk] Q: Best way to upgrade from 1.3.3 to current?

[Bob A. <apt...@cy...>]

Hi,

[responding back on-list]
On Tue, 20 Jan 2004 11:46:54 +0100 "Oliver Betz" <ob...@de...> wrote:

> Bob Apthorpe wrote:
> 
> > I'm moving my wiki from one machine to another and two problems arise
> > when restoring straight from a wikidb.dump. First, I don't want to
> > overwrite parts of the new (empty) wiki, especially the admin pages,
> 
> you could merge them locally. When using Windows, have a look at 
> "Beyond Compare".

I just dumped the fresh (new) wiki's pages, unzipped the old wiki's
archive, listed the two directories and fed those lists through comm
(yet another unix tool that does one-and-only-one job well. Took me
years to find it though...) to eliminate duplicates, then destructively
imported only the new files (see below.) I had to manually edit two
pages; otherwise everything moved over just fine.

> > documentation, etc. Second, restoring from the wiki dump only pulls in
> > the first version of each page, leaving the most recent revisions to
> 
> If you have a complete ZIP dump 
> (/PhpWikiAdministration?action=zip&include=all), all history 
> information is included.

Yes, and the problem was that only the first page would be imported;
everything else conflicted with an existing entry and needed manual
intervention.

> Carsten Klapp posted December 2003 how to patch PhpWiki to accept the 
> complete page data.
> 
> Without patching anything, you can try to add add an "overwrite=1" 
> query argument when uploading the ZIP file. It should still work.

Another nice person refreshed my memory of Carsten's post off-list. I
patched WikiForm, added a revised version of the plugin to the admin
page and everything imported beautifully. My new task is to sort out why
the MacOSX theme is somewhat unhappy under Opera. This is based on a
user report; I haven't used Opera in a while and CSS is mostly foreign
to me, so it may take a while to sort out.

Thanks again to everyone who responded,

-- Bob

[Phpwiki-talk] (no subject)

[Daniel <am...@in...>]