phpwiki-talk

[Phpwiki-talk] do subpages work?

[Chip R. <ch...@un...>]

Is [ChipRosenthal/Preferences] or [ChipRosenthal/Calendar] supposed to
do something?  On my wiki they show up as undefined pages.

-- 
Chip Rosenthal * ch...@un... * http://www.unicom.com/
"Why look back in anguish when we can look forward to the future
with cynicism?" * http://www.unicom.com/chrome/a/000029.html

Re: [Phpwiki-talk] User Management (Registration / Authentication and File uploads)

[Chip R. <ch...@un...>]

On Wed, Jan 15, 2003 at 09:12:22PM +0100, Jochen Kalmbach wrote:
> You can get the code from: http://wiki.kalmbachnet.de/ (or directly from
> http://wiki.kalmbachnet.de/userdata/kajo0011/phpwiki-UserManagement-v3.zip)

This is looking really good.  I've got a couple of minor nits that I'll
want to send Jochen a patch for, probably later today.

My biggest remaining concern is the homepage setup.  When the homepage
is generated from the template, it is badly botched.

Two problems.

First, the eval munges the template in several bad ways.  It is
converting angle brackets to character entities, so a call to <plugin>
in the template appears as &gt;plugin&lt; in the homepage source.  Also,
it is collapsing whitespace and removing newlines.  Is there some way
to prevent this sort of thing on expansion?

Second, it creates links to Username/Calendar and Username/Preferences
and that stuff just does not work on my system.  Did it ever work?

It's been very frustrating for me because it seems like there is so
much half-working code checked into CVS.  I keep running into problems,
and I'm never sure whether it is a bug, or just some code that somebody
never finished implementing.

-- 
Chip Rosenthal * ch...@un... * http://www.unicom.com/
"Why look back in anguish when we can look forward to the future
with cynicism?" * http://www.unicom.com/chrome/a/000029.html

[Phpwiki-talk] User Management (Registration / Authentication and File uploads)

[Jochen K. <Jo...@Ka...>]

Hello,

at my Wiki-Test-Homepage I have an improved version of the User-Registration
/ Authentication and File upload (thanx to Chip Rosenthal).

You can get the code from: http://wiki.kalmbachnet.de/ (or directly from
http://wiki.kalmbachnet.de/userdata/kajo0011/phpwiki-UserManagement-v3.zip)

It would be great if someone could also look throu the code and test the
plugins (UserRegistration and UserFileManagement).

Changes are done to:
- index.php: new setting: ALLOW_SELF_REGISTRATION
- config.php: onyl bugfix, has nothing to do with the user-management
- display.php: headers are now sent with "no-cache"; if someone has an
better idea to allow correctly display the pages, after someone logged
in/out
- Request.php: Request_UploadedFile-class now has new method: move
- stdlib.php: fileSet-class now has a new method: getSubDirs
- WikiUser.php: New preferences: firstname, lastname / createUser and
createHomepage corrected
- plugin/_BackendInfo.php: Corrected for 'passwd'-entry
- login.tmpl: Now the optionally link to the UserRegistration page

New files:
- plugin/UserFileManagement.php: Upload and management of user files
- plugin/UserRegistration.php: Self registration for users (if allwowed;
with email verification) and Admin can create user accounts
- pgsrc/UserRegistration
- pgsrc/UserFiles
- themes/default/images/UserFileManagement/back.gif / dir.gif / image3.gif:
Small icons for UserFileManagement-Display
- themes/default/templates/userregistration.tmpl: New form for user
registration

Greetings
  Jochen

Re: [Phpwiki-talk] Planning new configurator for config-dist & config-user

[Matti A. <ma...@ik...>]

Joby Walker wrote:

> Carsten, I can help with this element as well.  And config-local.php is 
> way better than config-user.php.

Another name choice might be config-site.php.

m.

[Phpwiki-talk] WikiDB_Page::isUserPage()

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

In doing some long delayed work on the Group interface I was 
investigating the isUserPage() method of WikiDB_Page.  I think this was 
part of Reini's work on the User Interface (it is used in the 
AllUsers.php plugin).

This just can't be right (lib/WikiDB.php 827):

--------------------------------------------------
     function isUserPage ($include_empty = true) {
         return $this->get('pref') ? true : false;
         if ($include_empty)
             return true;
         $current = $this->getCurrentRevision();
         return ! $current->hasDefaultContents();
     }
--------------------------------------------------

The only line that will get executed is the first "return".  Are the 
others hold overs from an older version or a munged new version?  Should 
probably be:

--------------------------------------------------
     function isUserPage ($include_empty = true) {
         if ($include_empty) {
             $current = $this->getCurrentRevision();
             if ($current->hasDefaultContents()) {
                 return false;
             }
         }
         return $this->get('pref') ? true : false;
     }
--------------------------------------------------

Any objections to me commiting this?

jbw

[Phpwiki-talk] [Patch] Page templates support

[Todd M. <nil...@ne...>]

The attached patch adds page template support to phpwiki when creating a
page.  When you initially edit a page that did not previously exist, it
will check for a templatename parameter.  If it exists, it will use it's
value as a pagename to use for the default content of the page.  It also
does variable substitution on the template page content for {pagename}
and {sourcepage}.

Also in the patch, when viewing a nonexistant page, you see a message
saying the page does not exist, but when editing such a page for the
first time without a template, it defaults to the usual 'Describe
[pagename] here' content.  

A plugin called TemplateForm is also provided, which let's you insert a
form into a page for page creation.  You can specify a particular
template page to use, or let it show a drop down box of templates.

One example using this is Categories.  If you add the following snippet
to the end of CategoryCategory:

=========================================================
--

Create new category:
  <?plugin TemplateForm template=CatTemplate buttontext="Create
Category" ?>
=========================================================

and add the following pages:

CatTemplate:
=========================================================
Pages in category [{pagename}]:
<?plugin BackLinks noheader=1 ?>

Create new page in this category:
  <?plugin TemplateForm template=CatPageTemplate ?>
--
CategoryCategory
=========================================================

CatPageTemplate:
=========================================================
Describe [{pagename}] here.

--
[{sourcepage}]
=========================================================

Now, category creation, and creating pages within a category just became
much simpler.

If this is worth pursuing, other useful features should be easy to add:
* have a DefaultTemplate so you can customize the default content for
new pages for an entire site
* add a template parameter to the Calendar plugin, so you can have
boilerplate for calendar entries.

Comments?

[Note: patch is against current CVS]

-- 
Todd Mokros <nil...@ne...>

Re: [Phpwiki-talk] Planning new configurator for config-dist & config-user

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

Sorry I've been gone for a while (holidays, other work projects).

Carsten, I can help with this element as well.  And config-local.php is 
way better than config-user.php.

Moving the schema into this would be a very good idea since this would 
dramatically ease the install routine and make customizing the tables 
(for multiple wikis) much easier.

My preference would be for:

1) config-valid.php (config/valid.php?) - The ultimate authority with 
the default values and classes to validate new values.  This file would 
not be loaded in the normal operation of PHPWIKI -- only if a 
configuration routine is invoked.
2) config-dist.php (config/dist.php?) - Produced by either the web 
configurator or a cli configurator via the config-valid.php with the 
default values.
3) config-local.php (config/local.php?) - Produced by either the web 
configurator or a cli configurator via the config-valid.php.
4a) configurator.php (config/webconfig.php) - Web based configuration 
tool uses base classes in config-valid.php to produce config-dist.php 
and config-local.php which can be downloaded and then uploaded to the 
proper directory.  This app can be set to show the current 
config-local.php settings or if greater security is desired not include 
those values.
  b) config-cli.php (config/cliconfig.php?) - CLI configuration tool 
uses base classes in config-valid.php to produce config-dist.php and 
config-local.php.

Use of this file will mean that the configurators (4) will not have to 
use PCRE to parse the comments of the config-dist.php to come up with 
the potentially valid values.

Alternately, if it is desired to have config-dist.php be the ultimate 
authority and use PRCE on the comments in config-dist.php.  A 
config-valid.php (or perhaps config-tools.php) would be useful to hold 
classes used to do the PRCE parsing so that both the web and cli 
versions of the configurator don't have to do their own implimentation.

jbw

Carsten Klapp wrote:
> Hi Russ,
> 
> I believe an automated database setup was something the PhpWiki team 
> just never got around to doing... it's a good idea, and off the top of 
> my head I can't think of any reason why it couldn't be added to the 
> configurator. :)
> 
> Carsten
> 
> On Tuesday, January 14, 2003, at 08:17  am, Russ Miller wrote:
> 
>>> I'd like to discuss any plans or ideas you  may have to add the
>>> configurator.php functionality together with the new config system.
>>
>>
>>
>> What is the issue with the configurator running the schema and setting up
>> the DB tables? That would be a nice fix.
>>
>> russ
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: FREE  SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your  SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

RE: [Phpwiki-talk] Multiple WIKIs

[Alexandre D. <al...@co...>]

On Tue, 7 Jan 2003, Sandy Matheson wrote:

> Thanks for the help.
> 
> Index.php now gets through this OK and starts to load, but locks just
> after creating the TextFormattingRules page.
> 
> HOWEVER if I set up an entirely new MySQL database and use the same
> index.php file (i.e. only altering the 'prefix' part as well as
> database, username and password), then everything works fine.

Using prefix in table namespace ? I don't think it's a great idea. Why
don't you  create a new  database ? (For  performance & so  on... It's
also better)

> 
> I can use multiple databases, but backing up will be so much easier with
> one database using PHPMyAdmin. 

I don't know how PHPMyAdmin works.  But we have a multitude of wiki on
the  same machine  and we  have a  comment method  for  expressing the
database name : phpwikidb-XXXX. 

For the backup, we have a  custom script doing a mysqlshow and dumping
all the db starting with phpwikidb-. Clean and working like a charm. 

Have a nice day. 

adulau

-- 
			      Alexandre Dulaunoy -- http://www.foo.be/
  3B12 DCC2 82FA 2931 2F5B 709A 09E2 CD49 44E6 CBCD  ---   AD993-6BONE
"People who fight may lose.People who do not fight have already lost."
							Bertolt Brecht

Re: [Phpwiki-talk] Planning new configurator for config-dist & config-user

[Carsten K. <car...@us...>]

Hi Russ,

I believe an automated database setup was something the PhpWiki team 
just never got around to doing... it's a good idea, and off the top of 
my head I can't think of any reason why it couldn't be added to the 
configurator. :)

Carsten

On Tuesday, January 14, 2003, at 08:17  am, Russ Miller wrote:

>> I'd like to discuss any plans or ideas you  may have to add the
>> configurator.php functionality together with the new config system.
>
>
> What is the issue with the configurator running the schema and setting 
> up
> the DB tables? That would be a nice fix.
>
> russ

Re: [Phpwiki-talk] Planning new configurator for config-dist & config-user

[Russ M. <rm...@no...>]

> I'd like to discuss any plans or ideas you  may have to add the
> configurator.php functionality together with the new config system.


What is the issue with the configurator running the schema and setting up
the DB tables? That would be a nice fix.

russ

Re: [Phpwiki-talk] creating users

[Matti A. <ma...@ik...>]

Jochen Kalmbach wrote:

> If you do the following patches then it [user registration etc.] works.

While I haven't yet had time to test the patches, they sound absolutely 
awesome. I wonder whether they could be added to the CVS?

m.

[Phpwiki-talk] Planning new configurator for config-dist & config-user

[Carsten K. <car...@us...>]

Hi All,

I'd like to discuss any plans or ideas you  may have to add the 
configurator.php functionality together with the new config system. 
This might require a brand new configurator who knows, I am willing to 
put time in there.

Instead of the current self-contained configurator, a new configurator 
could parse the config-dist file eliminating the need to update the 
configurator whenever something is added to index.php (or config-dist).

The configurator would still present the admin with a locally 
accessible the web page for choosing all the config options, but a 
plugin might be possible to hook into the configurator for post-install 
tweaking. Then configurator outputs only the parameters which changed 
from those in config-dist (maybe along with minimal comments) and 
stores them into config-user.php.

Power users can still avoid the configurator if they like, by copying 
what they want from config-dist and paste it into config-user themseves 
for manual modification.

Also a pedantic request to reconsider the filename config-user.php. I 
have no "super" ideas yet, how about config-local?

Carsten

Re: [Phpwiki-talk] creating users

[Jochen K. <Jo...@Ka...>]

Chip Rosenthal wrote:
>
> I'm using phpwiki-1.3.4.  I have ALLOW_USER_LOGIN true, ALLOW_BOGO_LOGIN
> false, and REQUIRE_SIGNIN_BEFORE_EDIT true.
>
> How can the administrative user create user logins?

This is not possible with the actual version...,

If you do the following patches then it works.
Then you have the following features:
- User can register him/herself. The user must enter an valid E-Mail account
to receive the password (you can also disable this at the moment by removing
the plugin: UserRegister.php from the attached zip-file)
- Authenticated users can upload files (only. zip, pdf, jpg, gif, png, txt)
and link to them in any wiki-page
- Administrators can create user accounts (an automatic email is sent to the
user if you want)

All this you can test on: http://wiki.kalmbachnet.de/

Greetings
  Jochen

PS:
The follwoing files are new:
- lib/plugin/UserAdminCreateUser.php
- lib/plugin/UserRegister.php
- lib/plugin/UserFileManagement.php
- pgsrc/AdminCreateUser
- pgsrc/UserRegister

The following patches are needed (all included in the attached file):

Index: config.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/config.php,v
retrieving revision 1.68
diff -r1.68 config.php
260c260,266
< if (!defined('DATA_PATH'))   define('DATA_PATH', dirname(SCRIPT_NAME));
---
> if (!defined('DATA_PATH')) {
>   $temp = dirname(SCRIPT_NAME);
>   if ( ($temp == '/') || ($temp == '\\') )
>     $temp = "";
>   define('DATA_PATH', $temp);
> }
>

Index: display.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/display.php,v
retrieving revision 1.38
diff -r1.38 display.php
66a67,70
>
>     header("Cache-Control: no-cache, must-revalidate");
>     header("Expires: 0");
>
135a140,143
>
>     header("Cache-Control: no-cache, must-revalidate");
>     header("Expires: 0");
>

Index: Request.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/Request.php,v
retrieving revision 1.24
diff -r1.24 Request.php
331a332,335
>
>     function move($dest) {
>         return move_uploaded_file($this->_info['tmp_name'], $dest);
>     }

Index: stdlib.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/stdlib.php,v
retrieving revision 1.132
diff -r1.132 stdlib.php
1009a1010,1013
>     function getSubDirs() {
>         return $this->_subDirList;
>     }
>
1019a1024
>         $this->_subDirList = array();
1037a1043,1046
>             if(filetype($dir . $this->_pathsep . $filename) == 'dir') {
>                 array_push($this->_subDirList, "$filename");
>                 continue;
>             }

Index: WikiUser.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiUser.php,v
retrieving revision 1.29
diff -r1.29 WikiUser.php
36c36,38
<                          'relativeDates' => new _UserPreference_bool()
---
>                          'relativeDates' => new _UserPreference_bool(),
>                          'firstname'     => new _UserPreference(''),
>                          'lastname'      => new _UserPreference('')
136a139,141
>         // to get the homepage we have to set the userid
>         $this->_userid = $userid;
>
264c269
<         if (!$prefs->_prefs and USE_PREFS_IN_PAGE and $this->homePage())
{ // in page metadata
---
>         if (/*!$prefs->_prefs and*/ USE_PREFS_IN_PAGE and
$this->homePage()) { // in page metadata
324c329
<     function createUser ($pref, $createDefaultHomepage = true) {
---
>     function createUser ($pref, $createDefaultHomepage = true, $passwd =
false) {
326a332,334
>             if ($passwd != false) {
>                 $pref->_prefs['passwd'] = $passwd;
>             }
331c339,342
<             $pageinfo = array('pagedata' => array('pref' =>
serialize($pref->_pref)),
---
>             if ($passwd != false) {
>                 $pref->_prefs['passwd'] = $passwd;
>             }
>             $pageinfo = array('pagedata' => array('pref' =>
serialize($pref->_prefs)),
347c358
<         $template = Template('homepage.tmpl',$this->_request);
---
>         $template = Template('homepage',$this->_request);
349,350c360,362
<         $pageinfo = array('pagedata' => array('pref' =>
serialize($pref->_pref)),
<                           'versiondata' => array('author' =>
$this->_userid),
---
>         $versiondata = array('author' => $this->_userid);
>         $pageinfo = array('pagedata' => array('pref' =>
serialize($pref->_prefs)),
>                           'versiondata' => $versiondata,
354a367
>         /* At the moment disabled: Create-Calender and Create-Preferences
373a387
>         */
392c406
<             return true;
---
>             return false;  // FIXME: Empty passwords are not allowed at
the moment!
394,396c408,410
<         if ($stored_passwd == '*')
<             return true;
<         if (!empty($passwd) && crypt($passwd, $stored_passwd) ==
$stored_passwd)
---
>         /*if ($stored_passwd == '*')
>             return true;*/
>         if (!empty($passwd) && ($passwd == $stored_passwd) )
433,435c447,450
< function createUser ($userid, $pref) {
<     $user = new WikiUser ($userid);
<     $user->createUser($pref);
---
> function createUser ($userid, $pref, $passwd = false) {
>     $user = new WikiUser ($userid, WIKIAUTH_USER);
>     $user->createUser($pref, true, $passwd);
>     return $user;

Index: _BackendInfo.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/plugin/_BackendInfo.php,v
retrieving revision 1.19
diff -r1.19 _BackendInfo.php
21a22
>         $this->_request = $request;
78c79
<                 if ($key == 'passwd' and ! $request->_user->isAdmin())
---
>                 if ($key == 'passwd' and !
$this->_request->_user->isAdmin())

Index: login.tmpl
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/themes/default/templates/login.tmpl,v
retrieving revision 1.20
diff -r1.20 login.tmpl
23a24,27
> <hr noshade="noshade" />
> <b>If you want to register you have to click <a
href="<?=WikiURL('UserRegister')?>">here</a></b>.
> <hr noshade="noshade" />
>
39,42d42
< <tr>
<   <td align="right"><?= _("Create Homepage:") ?></td>
<   <td><input type="checkbox" name="auth[homepage]" <?=$checked?> /></td>
< </tr>
70a71,73
>
>
> <hr noshade="noshade" />

[Phpwiki-talk] creating users

[Chip R. <ch...@un...>]

I'm using phpwiki-1.3.4.  I have ALLOW_USER_LOGIN true, ALLOW_BOGO_LOGIN
false, and REQUIRE_SIGNIN_BEFORE_EDIT true.

How can the administrative user create user logins?

-- 
Chip Rosenthal * ch...@un... * http://www.unicom.com/
"Why look back in anguish when we can look forward to the future
with cynicism?" * http://www.unicom.com/chrome/a/000029.html

[Phpwiki-talk] Think I found someof the getDbh problems

[Zot O'C. <zo...@wh...>]

lib/imagecache.php:

     66 function mainImageCache() {
     67     $request = new Request;
     68     //$request->setArg('pagename', deduce_pagename($request));
     69     //$pagename = $request->getArg('pagename');
     70 
     71     // assume that every user may use the cache
     72     global $user; // FIXME: necessary ?
     73 //zot
     74 print "lib/imagecache.php: mainImageCache next<br>\n";
     75     $user = new WikiUser($request, 'ANON_OK');
     76 //zot

This calls WikiUser with a Request, NOT a WikiRequest.

grep -r getDbh *| grep fun
lib/main.php:    function getDbh () {

lib/main.php:
    16  class WikiRequest extends Request {
    17      // var $_dbi;
    18  
    19      function WikiRequest () {
    20          if (USE_DB_SESSION) {
    21              $this->_dbi = $this->getDbh();
...
   126      function getDbh () {
   127          if (!isset($this->_dbi)) {
   128              // needs PHP 4.1. better use $this->_user->...
   129              $this->_dbi = WikiDB::open($GLOBALS['DBParams']);
   130          }
   131          return $this->_dbi;
   132      }

So when the WikiUser call get

lib/WikiUser.php:
    48      function WikiUser ($userid = false, $authlevel = false) {
    49          $this->_request = &$GLOBALS['request'];
    50          $this->_dbi = &$this->_request->getDbh();
    51  

It assumes it is getter a WikiRequest, but here it is getting a Request.

It looks like possibledeflowervirign may fall prey to this error
(thought it did not look like at first glance).

This *might* explain the dbm issues I was seeing.



-- 
Zot O'Connor

http://www.ZotConsulting.com
http://www.WhiteKnightHackers.com

[Phpwiki-talk] FILTER LOTTERY INTERNATIONAL

[danny b. <fi...@ne...>]

FILTER MELENION LOTTERY INTERNATIONAL 

FROM: INTERNATIONAL PROMOTION/PRIZE AWARD DEPT. 


REF: OGS/2311786008/01 
BATCH: 14/011/IPD /NL

RE: @

Sir/Madam

We are pleased to inform you of the result  of
the Lottery Winners International programs held on the
1st of January 2003. Your e-mail address attached to
ticket number 20511465886-629 with serial number
3772-99 drew lucky numbers 7-14-17-23-31-22 which
consequently won in the 2nd category, you have
therefore been approved for a lump sum pay out of
1,000,000.00 Euro. (One Million Euro)
CONGRATULATIONS!!!

Due to mix up of some numbers and names, we ask that
you keep your winning information confidential until
your claims has been processed and your money
Remitted to you. This is part of our security protocol
to avoid double claiming and unwarranted abuse of
this program by some participants. 

All participants were selected through a computer
ballot system drawn from over 100,000 company and
50,000,000 individual email addresses and names from
all over the world. This promotional program takes
place every three year. We hope with part of your winning
you will take part in our end of year 50 million Euro
International lottery. To file for your claim, please
contact our fiducially agent MR TERRY BLAY of the,
NORTH ATLANTIC CONSULTANCY
TEL:+31-612-700-506
FAX:+31-616-908-703
Email: dan...@ma...
Remember, all winning must be claimed not later than
31st of febuary 2003. After this date all unclaimed
funds will be included in the next  stake. Please note
in order to avoid unnecessary delays and complications
please remember to quote your reference number and
batch numbers in all correspondence. Furthermore,
should there be any change of address do inform our
agent as soon as possible. 

Congratulations once more from our members of staff
and thank you for being part of our promotional program.

Note: Anybody under the age of 18 is automatically
disqualified. 

Sincerely yours,

Mrs. Elizabeth Van Bosch
Lottery Coordinator.


  

[Phpwiki-talk] Misc fixes

[Martin G. <gim...@gi...>]

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

[Phpwiki-talk] New plugin: UserFileManagement (upload / rename / delete of user files)

[Jochen K. <Jo...@Ka...>]

Hello,

on my test site (http://wiki.kalmbachnet.de/) I have put my new plugin:
UserFileManagement.

With this plugin every authorized user can upload / rename and delete files
and folders. Of course he/she can only change files, which are uploaded by
him/herself. But he/she can view all other files also.
The files are stored in the normal filesystem (in a special directory). It
should be safe for any attacks...

Unauthorized users can only view the files (at the moment I only check
isSignedIn, which allows also bogo-logins!!!)).
The admin can change all files/dirs.

The user can upload either file by file (10 at a time), or put all the files
in a zip-file and this zip file is unziped on the server to the actual
directory.

To get this work I have to extend some classes:
1. class Request_UploadedFile in Request.php:
  Add the function move($dest)

2. class fileSet
  Add support for retriving sub-directories:
    - Add function getSubDirs()
    - Add some stuff in function fileSet

This is just for discussion. I am not a phpWiki-developer, so it is not
checked in.

Greetings
  Jochen

PS: changes to stdlib.php and Request.php

Index: Request.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/Request.php,v
retrieving revision 1.24
diff -r1.24 Request.php
331a332,335
>
>     function move($dest) {
>         return move_uploaded_file($this->_info['tmp_name'], $dest);
>     }

Index: stdlib.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/stdlib.php,v
retrieving revision 1.132
diff -r1.132 stdlib.php
1009a1010,1013
>     function getSubDirs() {
>         return $this->_subDirList;
>     }
>
1019a1024
>         $this->_subDirList = array();
1037a1043,1046
>             if(filetype($dir . $this->_pathsep . $filename) == 'dir') {
>                 array_push($this->_subDirList, "$filename");
>                 continue;
>             }

Re: [Phpwiki-talk] DBM not owkring with 1.3.4

[Zot O'C. <zo...@wh...>]

Just a quick note.

I tested with postgres and it works there, so this is a DBM issue.

I put a bunch of prints in, and I see where the initial create is
called:

It seems that 

    48      function WikiUser ($userid = false, $authlevel = false) {
    49  print "lib/WikiUser.php: top new WikiUser <BR>\n";
    50          $this->_request = &$GLOBALS['request'];
    51  print "lib/WikiUser.php: before getDb $this->_request <BR>\n";

Calling request calls forces the getDbh, which forces the open with a
'c'.

Then in libn/main .php the deflower line forces the second one.
    717 print "lib/main.php: main: before possiblyDeflowerVirginWiki
<BR>\n";
    718     $request->possiblyDeflowerVirginWiki();
    719 print "lib/main.php: main: after possiblyDeflowerVirginWiki
<BR>\n";


index.php: before main
lib/main.php: main: before main() 
lib/main.php: main: before new WikiRequest(); 
lib/main.php: WikiRequest:top 
lib/main.php: WikiRequest: before Request 


lib/Request.php:240: Warning[2]: Cannot send session cache limiter -
headers already sent (output started at
/home/httpd/html/wiki/clients/plug/index.php:657)


lib/main.php: WikiRequest: after Request 
lib/main.php: WikiRequest: User 
lib/WikiUser.php: top new WikiUser 
lib/WikiUser.php: before getDb Object 
lib/main.php: getDbh !isset 
/nlib/WikiDB.php: open new WikiDB_dba
lib/WikiDB/dba.php: in WikiDB_dba
lib/WikiDB/backend/dba.php: before open 
Zot: this->_file /tmp/wiki_pagedb.gdbm, mode c, this->_handler
gdbmlib/WikiDB/backend/dbaBase.php: new in WikiDB_backend_dbaBase
lib/WikiUser.php: before isa user 
lib/WikiUser.php: bottom new WikiUser 
lib/main.php: WikiRequest: getPreferences 
lib/main.php: WikiRequest: end 
lib/main.php: main: before request->updateAuthAndPrefs() 


lib/WikiUser.php:284: Warning[2]: Cannot add header information -
headers already sent by (output started at
/home/httpd/html/wiki/clients/plug/index.php:657)


lib/main.php: main: before possiblyDeflowerVirginWiki 
lib/main.php: getDbh !isset 
/nlib/WikiDB.php: open new WikiDB_dba
lib/WikiDB/dba.php: in WikiDB_dba
lib/WikiDB/backend/dba.php: before open 
Zot: this->_file /tmp/wiki_pagedb.gdbm, mode c, this->_handler gdbm


-------------------------------------------

When this debuged to pgsql, 

index.php: before main
lib/main.php: main: before main() 
lib/main.php: main: before new WikiRequest(); 
lib/main.php: WikiRequest:top 
lib/main.php: WikiRequest: before Request 


lib/Request.php:240: Warning[2]: Cannot send session cache limiter -
headers already sent (output started at
/home/httpd/html/wiki/clients/plug/index.php:658)


lib/main.php: WikiRequest: after Request 
lib/main.php: WikiRequest: User 
lib/WikiUser.php: top new WikiUser 
lib/WikiUser.php: before getDb Object 
lib/main.php: getDbh !isset 
/nlib/WikiDB.php: open new WikiDB_SQL
lib/WikiUser.php: before isa user 
lib/WikiUser.php: bottom new WikiUser 
lib/main.php: WikiRequest: getPreferences 
lib/main.php: WikiRequest: end 
lib/main.php: main: before request->updateAuthAndPrefs() 


lib/WikiUser.php:284: Warning[2]: Cannot add header information -
headers already sent by (output started at
/home/httpd/html/wiki/clients/plug/index.php:658)


lib/main.php: main: before possiblyDeflowerVirginWiki 
lib/main.php: getDbh !isset 
/nlib/WikiDB.php: open new WikiDB_SQL
lib/WikiUser.php: top new WikiUser 
lib/WikiUser.php: before getDb Object 
lib/WikiUser.php: before isa user 
lib/WikiUser.php: bottom new WikiUser
...

Loading up virgin wiki
...
(HTML)


On Thu, 2003-01-09 at 19:39, Zot O'Connor wrote:
> 1.3.4 is not installing with dbm.
> 
> I have 6-9 1.3.3 installs working, so something has changed.
> 
> I get the dreaded:
> lib/DbaDatabase.php:32: Fatal[256]: driver initialization
> failed
> 
> I tried the local subdir, /tmp etc.
> 
> I think the problem is two attempts to create the file:
> 
> -rw-r--r--   1 nobody   nobody      12288 Jan  9 19:32
> /tmp/wiki_pagedb.gdbm
> 
> Adding a debug line in lib/config.php
> 
>      30         $this->_dba_open_error = false;
>      31         $ErrorManager->pushErrorHandler(new
> WikiMethodCb($this, '_dba_open_error_handler'));
>      32 print "Zot: this->_file $this->_file, mode $mode,
> this->_handler $this->_handler";
>      33         while (($dbh = dba_open($this->_file,
> $mode, $this->_handler)) < 1) {
> 
> I see:
> Zot: this->_file /tmp/wiki_pagedb.gdbm, mode c,
> this->_handler gdbmZot: this->_file /tmp/wiki_pagedb.gdbm,
> mode c, this->_handler gdbm
> 
> [pause]
> lib/DbaDatabase.php:33: Fatal[256]: driver initialization
> failed
> 
> ls -l /tmp/w*
> -rw-r--r--   1 nobody   nobody      12288 Jan  9 19:34
> /tmp/wiki_pagedb.gdbm
> 
> So I assume mode='c' is asking to create the file.  Since
> there are two calls, I assume it is getting the request twice.
> 
> Doing diff from 1.3.3 to 1.3.4 show no changes in the
> lib/Dba*php files.
> 
> So, has anyone else made this work with dbm yet.  Given
> this and the error below, I kinda doubt it.
> 
> 
> 
> 
> BTW there is an error in the assumptions on startup:
> 
> if (ALLOW_USER_LOGIN and empty($DBAuthParams['auth_dsn'])
> and empty($DBAuthParams['auth_user_file'])) {
>     $DBAuthParams['auth_dsn'] = $DBParams['dsn'];
> }
> 
> 
> This never checked if 'dns' was set.  Since I am running
> dbm, this has no purpose.  The index.php by default tries
> to set this.
> 
> Versions:
> php-4.0.4pl1-9
> apache-1.3.14-2.6.2
-- 
Zot O'Connor

http://www.ZotConsulting.com
http://www.WhiteKnightHackers.com

[Phpwiki-talk] (no subject)

[Zot O'C. <zo...@wh...>]

1.3.4 is not installing with dbm.

I have 6-9 1.3.3 installs working, so something has changed.

I get the dreaded:
lib/DbaDatabase.php:32: Fatal[256]: driver initialization
failed

I tried the local subdir, /tmp etc.

I think the problem is two attempts to create the file:

-rw-r--r--   1 nobody   nobody      12288 Jan  9 19:32
/tmp/wiki_pagedb.gdbm

Adding a debug line in lib/config.php

     30         $this->_dba_open_error = false;
     31         $ErrorManager->pushErrorHandler(new
WikiMethodCb($this, '_dba_open_error_handler'));
     32 print "Zot: this->_file $this->_file, mode $mode,
this->_handler $this->_handler";
     33         while (($dbh = dba_open($this->_file,
$mode, $this->_handler)) < 1) {

I see:
Zot: this->_file /tmp/wiki_pagedb.gdbm, mode c,
this->_handler gdbmZot: this->_file /tmp/wiki_pagedb.gdbm,
mode c, this->_handler gdbm

[pause]
lib/DbaDatabase.php:33: Fatal[256]: driver initialization
failed

ls -l /tmp/w*
-rw-r--r--   1 nobody   nobody      12288 Jan  9 19:34
/tmp/wiki_pagedb.gdbm

So I assume mode='c' is asking to create the file.  Since
there are two calls, I assume it is getting the request twice.

Doing diff from 1.3.3 to 1.3.4 show no changes in the
lib/Dba*php files.

So, has anyone else made this work with dbm yet.  Given
this and the error below, I kinda doubt it.




BTW there is an error in the assumptions on startup:

if (ALLOW_USER_LOGIN and empty($DBAuthParams['auth_dsn'])
and empty($DBAuthParams['auth_user_file'])) {
    $DBAuthParams['auth_dsn'] = $DBParams['dsn'];
}


This never checked if 'dns' was set.  Since I am running
dbm, this has no purpose.  The index.php by default tries
to set this.

Versions:
php-4.0.4pl1-9
apache-1.3.14-2.6.2

-- 
Zot O\'Connor

http://www.ZotConsulting.com
http://www.WhiteKnightHackers.com

[Phpwiki-talk] =?ISO-8859-1?Q?CIIA.NET?=

[<car...@th...>]

Dear Sir/Madam,=20
=20
CIIA.NET - US$680=20
=20
Please note that after years, the registration on the domain name=20
CIIA.NET was not renewed, and this domain had become available to regist=
er.=20
=20
Consequently, we have been approached to market this domain name that ha=
s been tracked and registered by a client. As a result, CIIA.NET is now =
available from us for IMMEDIATE transfer.=20
=20
This is a VALUABLE and HIGH PROFILE domain, and we believe that this=20
development could be of genuine interest and benefit to your operation. =
Please note that the domain name market is extremely solid at the moment=
, and similar domains are currently selling on afternic.com, greatdomain=
s.com (domain auction sites) and by domain=20
name brokers, in some cases, for many thousands of US dollars.=20
=20
Please note that transfers take just 15 minutes and are extremely=20
straightforward - absolutely NO technical knowledge required!=20
=20
For our client's peace of mind, we use an escrow service for all=20
transactions, and domains are ALWAYS secured by the buyer prior to us=20
receiving any funds. We pay all fees connected with the escrow process. =20
=20
If you would like to use WWW.CIIA.NET for your online business, please c=
ontact us at your earliest convenience. We will be on hand should you re=
quire any further assistance or information.=20
=20
We thank you for your attention and sincerely apologise if this e-mail=20
has not been of interest to you.=20
=20
Yours sincerely,=20
=20
Caroline=20
Marketing=20
The Portal=20

[Phpwiki-talk] assistance

[RICHARD <pet...@ma...>]

MR=2ERICHARD AKELE=2E

DIRECTOR=2C ACCOUNTS AND AUDIT=2C

NIGERIAN NATIONAL PETROLEUM CORPORATION =28N=2EN=2EP=2EC=2E=29

TELEPHONE=3A 234-1-776 0962

FAX=3A 234-1-759-4725 

 

TRANSFER OF $28=2C600=2C000=3A00 =28TWENTY-EIGHT MILLION SIX

HUNDRED THOUSAND U=2ES=2E DOLLARS=29 ONLY=2E

I got your contact from the Nigerian Chamber of

Commerce & Industry=2E Following this and other

investigations resulting in a good recommendation=2E We

have decided to contact you to help us with the legal

Transfer of US$28=2C600=2C000=2E00 =28Twenty-Eight Million

Six

hundred Thousand United States Dollars=29=2E The amount

stated above resulted from an over-invoiced contract

executed for the Nigerian National Petroleum

Corporation =28N=2EN=2EP=2EC=2E=29 for which the contractors have

been fully paid=2E Because this money was part of the

overall contract sum amounting to close to

=28US$100=2C000=2C000=3A00=29 that has been completed=2E

The said amount has remained dormant and floating in

our Apex Bank=2E Therefore=2C we will raise supplementary

documents to enable us transfer into an account that

is yet to be nominated=2E We need a foreign partner=2C

because as civil servants=2C the code of conduct does

not allow us to operate foreign bank accounts=2E Hence

we solicit for your assistance=2C we are requesting you

to provide us with the help for the safekeeping of

this money until our arrival in your company to

collect our share and decide on investment

possibilities of this money=2E

For your assistance in this transaction=2C we have

unanimously agreed to offer you 30% of this money=2C 5%

will be used in settling any incidental expenses that

may arise and the remaining amount will be for us=2E To

enable the prompt transfer of this money=2C kindly send

to us your personal details=2C contact information &

bank details in full=2E

We look forward to hearing from you and thanking you

for your anticipated cooperation and consideration in

the above subject matter=2E Please be informed that we

would appreciate the handling of this transaction in

a

confidential manner=2E We sincerely advise that you

contact us on the above Telephone and fax numbers to

maintain the confidentiality of the business=2E Sending

e-mail will be appreciated=2E

Yours sincerely=2C

MR=2ERICHARD AKELE=2E

 

[Phpwiki-talk] NEW DoubleGold Game

[Gamesofgold.com <ga...@ga...>]

Hello Gamesofgold Mailing List members.  We would like to introduce our NEW DoubleGold Game

Doublegold is a real-time coin flipping game 

The rules are simple 
 guess coin 'heads' or 'tails' 
 place your bet through our online payment  
 if you guess correctly you win double the amount you bet* 
 the winnings are instantly paid to your account! 
* minus 5% commission 

http://trans-it.net.au/doublegold/index.asp

Thanks, and please remember to visit Gamesofgold.com to find HYIP programs and E-gold Games or advertise your own.

RE: [Phpwiki-talk] Multiple WIKIs

[Sandy M. <mat...@bt...>]

Thanks for the help.

Index.php now gets through this OK and starts to load, but locks just
after creating the TextFormattingRules page.

HOWEVER if I set up an entirely new MySQL database and use the same
index.php file (i.e. only altering the 'prefix' part as well as
database, username and password), then everything works fine.

I can use multiple databases, but backing up will be so much easier with
one database using PHPMyAdmin.

Any ideas?

Thanks,

Sandy

-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Bob
Apthorpe
Sent: 07 January 2003 15:53
To: php...@li...
Subject: Re: [Phpwiki-talk] Multiple WIKIs

On Tue, 7 Jan 2003 12:21:19 -0000
"Sandy Matheson" <mat...@bt...> wrote:

> Not had a reply so I have gone ahead to set up a second WIKI on the
same
> MySQL database and hit a problem.
> 
> I have set up the database tables fine using a prefix of 'newport_'
and
> in index.php I have enabled 'prefix' => 'newport_' on line 228.
> 
> When I access the website to set it up I get the error:
> 
> Parse error: parse error, expecting `')'' in
> /usr/local/home/httpd/vhtdocs/newportparish.org.uk/index.php on line
228

You're missing a comma; strip the comments and all will become clear:

> _____________________________________
> 
> 
> Index.php:
> 
> $DBParams = array(
>    'dbtype' => 'SQL',
>    'dsn' => 'mysql://username:password@localhost/databasename'
>    'prefix' => 'newport_'
> );

Add comma after 'dsn'='mysql...'

hth,

-- Bob


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] Sign-In / User-Registration

[Jochen K. <Jo...@Ka...>]

Hello,

first: thanks for your reply! I appreciated...

But at the beginning I have an additional question:
If I use the login-mechanism, I have a problem with the browser cache! The
browser holds the page too long... If I log out and go to other pages that I
visited, then to page is not fetched anymore and as a result logged-out
username is displayed at the and (Signed in as ...)
How can I solve this problem ?
At the moment I did an:
    header("Cache-Control: no-cache, must-revalidate");
    header("Expires: 0");
in display.php...
Is there a better solution ?


> Here some suggestions for the UserRegistration:
> * The form should contain more space! (Or my name should be shorter :)
Done...

> * Some explanatory text concerning the UserId should be given.
Done...

>     - Is it used as the homepage's name?
>            (You mentioned it below, but if you always do so,
>             then why do you need a homepage creation button?)
I used the existing Login-Template, which had the Homepage-create-checkbox.
But now I removed it because it is not used anywhere.
Done..

>       If so, you might want to mention that
>         + it is a good idea to use a valid WikiWord
Done...

>           (and give a short explanation what a WikiWord is).
I somewhere se an definition of a valid WikiWord, but I could not find it at
the moment...

>         + it is likely that the UserId will be used as a
>           signature for every contribution
>           (such that it automatically links to the homepage)
What do you mean with this ?

>         + the allowed character set is (Iso xxx?)
It must be a valid WikiWord, so this is unnecessary.

>       Furthermore you should check if the UserId IS a WikiWord
>       and warn the user otherwise
How can I check if the word is a valid WikiWord ? Is there a function for
this ?

>     - You should stress that the email address is used to
>       send the password.
Done...

> * Perhaps it is easiest to give some example entries like
Done...

> * My english is nothing to write home about, but isn't it "surname"
>   instead of "surename"?
Sure, you are right... but now I changed it to firstname and lastname

> * Why is the homepage creation button part of the SignIn page instead
>   of the UserRegistration page?
There is no need for this button if the authentication is done via
HomePages... so I removed it at the moment...

> * Do you check whether the UserId / homepage already exists?
Yes.

> I did not look at the source (I will, promised) but I hope you
> used a prefix like "UserIdentity" for the userdata to avoid namespace
> pollution.
I used the existing storage for this: UserPreferences
If you click on the DebugInfo-Button of an homepage you see the structure
how it is stored.

> At the moment, everybody uses global pages for homepages. You should keep
> in mind that a Users/UserName page forces everybody to sign a comment with
> Users/JoeAverage or something like that.
I do not understand...

> I'm not one of the wiki gurus, but _I_ always wanted such a simple login.
I also...

If like you can take a look at my updated page (sorry it is now in
german....)
http://wiki.kalmbachnet.de/

> I got the following messages when I registered.
> So there seems to be a bug?

The problem is that the function for creating the User´s-HomePage is writing
directly to the client and does not buffer it... (or return it).
I have to add an silent-function for hompage creation.

> Something like a regular (say monthly) reminder for the password
> seems to be a good idea. (As well as some sort of unsubscribe)
I want to implement an SendMePassword-Plugin, but for this you have to know
either the UserID or the E-mail address.


More suggestions would be great...

Greetings
  Jochen