phpwiki-talk

Re: [Phpwiki-talk] Multiple WIKIs

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

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

[Phpwiki-talk] --enable-trans-sid problem returns?

[John K. <li...@ke...>]

Hi all,

When I started using phpwiki a year or so ago, sometimes I'd see 
&?PHPSESSID appended to relative URLs, which would break the phpwiki 
linking system. Only seemed to affect the first URL clicked.

It was caused (apparently) by a bug in PHP so I followed the advice 
on this page:
http://phpwiki.sourceforge.net/phpwiki/IndexPhp

(adding ini_set('session.use_trans_sid', 0); to index.php)

and it worked again. All was well.

But the problem seems to have (re)appeared since my ISP upgraded to 
PHP 4.3 a couple of days ago.

http://www.sitewriter.net/phpinfo.php
tells me that php was indeed complied with --enable-trans-sid but 
that's all I know.

See it in action:
http://sitewriter.net

Click 'HomePage' and you get:
http://sitewriter.net/pages/HomePage&?PHPSESSID=4abdf7fd688d4e6752a195abd083a427#63

Or similar

Any ideas?

John.

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

[Johannes G. <jg...@qf...>]

On Sat, 4 Jan 2003, Jochen Kalmbach wrote:

> I developed an path to allow users to register herself. For this the user
> must enter:
> - UserID (this is used as Login-Name)
> - Valid E-Mail address
> - Name
> - Surename

Here some suggestions for the UserRegistration:
* The form should contain more space! (Or my name should be shorter :)
* Some explanatory text concerning the UserId should be given.
    - 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?)
      If so, you might want to mention that
        + it is a good idea to use a valid WikiWord
          (and give a short explanation what a WikiWord is).
        + it is likely that the UserId will be used as a
          signature for every contribution
          (such that it automatically links to the homepage)
        + the allowed character set is (Iso xxx?)
      Furthermore you should check if the UserId IS a WikiWord
      and warn the user otherwise
    - You should stress that the email address is used to
      send the password.
* Perhaps it is easiest to give some example entries like
     UserId:  JoeAverage (german: OttoNormalverbraucher)
     Email:   jo...@av...
     Name:    Joe
     Surname: Average
* My english is nothing to write home about, but isn't it "surname"
  instead of "surename"?
* Why is the homepage creation button part of the SignIn page instead
  of the UserRegistration page?
* Do you check whether the UserId / homepage already exists?

> As you can see the password is not entered by the user. The password is
> instead sent to the users email address (so we have als an
> email-verification).
I like this idea. (Though there might be some concerns about using
a secure https connection.)

> After the registration, the Homepage for this user is created with the
> neccessary data in the page-meta-data:
> - userid=Pagename (not stored at the moment)
> - passwd: Password in clear text (or some kind of two-way crypt, so it is
> possible to retrive the password to allow the user to sent his/her password
> via email)
> - name
> - surename
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 followed the (partly) implemented way of storing all data in the
> page-meta-data and created an page with the userid as pagename. Here we
> should discuss if we should instead create a subpage like Users/UserName for
> each user (is subpaging already that good?) ?
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.

> It is not yet read for check-in. I just want to share the idea, if this is
> how it should be done...
I'm not one of the wiki gurus, but _I_ always wanted such a simple login.

> If you want to try it, please feel free to visit:
> http://wiki.kalmbachnet.de/

I got the following messages when I registered.
   JohannesGrosse new page - saved to database as version 1

   lib/WikiUser.php:285: Warning[2]: Cannot add header information -
   headers already sent by (output started at
   /homepages/20/d21096487/htdocs/kalmbachnet-de/wiki/lib/XmlElement.php:239)

   lib/display.php:135: Warning[2]: Cannot add header information -
   headers already sent by (output started at
   /homepages/20/d21096487/htdocs/kalmbachnet-de/wiki/lib/XmlElement.php:239)

So there seems to be a bug?

Something like a regular (say monthly) reminder for the password
seems to be a good idea. (As well as some sort of unsubscribe)

Nice work!
Johannes

RE: [Phpwiki-talk] Multiple WIKIs

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

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

The full part of this array in index.php is listed below

I am using PHPWiki version 1.3.3. Can anyone help, or point me in the
right direction?

Sandy Matheson

_____________________________________


Index.php:

$DBParams = array(
   // Select the database type:
   'dbtype' => 'SQL',
   // 'dbtype'   => 'dba',
   
   // For SQL based backends, specify the database as a DSN
   // The most general form of a DSN looks like:
   //
   //   phptype(dbsyntax)://username:password@protocol+hostspec/database
   //
   // For a MySQL database, the following should work:
   //
///////////////// CHANGE THIS////////////////////////////////////////
   'dsn' => 'mysql://username:password@localhost/databasename'
///////////////// CHANGE THIS////////////////////////////////////////
   //
   // FIXME: My version Pear::DB seems to be broken enough that there
   //        is no way to connect to a mysql server over a socket right
now.
   //'dsn' => 'mysql://guest@:/var/lib/mysql/mysql.sock/test',
   //'dsn' => 'mysql://guest@localhost/test',
   //'dsn' => 'pgsql://localhost/test',
   
   // Used by all DB types:

   // prefix for filenames or table names
   /* 
    * currently you MUST EDIT THE SQL file too (in the schemas/
    * directory because we aren't doing on the fly sql generation
    * during the installation.
   */
   'prefix' => 'newport_'
   // Used by 'dba'
   //'directory'     => "/tmp"',
   //'dba_handler'   => 'gdbm',   // Either of 'gdbm' or 'db2' work
great for me.
   //'dba_handler' => 'db2',
   //'dba_handler' => 'db3',    // doesn't work at all for me....
   //'timeout'   => 20,
   //'timeout' => 5
);

[Phpwiki-talk] cvs backend

[Rex T. <chi...@ka...>]

I sam there is a cvs backend support. What is the statue ? Is that functional ?
-- 
-Rex, geek by nature linux by choice

[Phpwiki-talk] Array of WikiPlugins on website?

[Ted V. <te...@jo...>]

Thanks for the NOWRAP response :), but I have another question.

Is there a list or array which hold all the WikiPlugins on one wikipage? I
was hoping to try to use two times a WikiPlugin on seperate lines below each
other and for some things to be coordinated I need to know if another of the
same plugin also is on the wikipage. So, is there some kind of array or list
or some other possibillity that I can check how many (of the same) plugins
are used on one wikipage?

I'm terrible sorry to 'spam' the mailinglist like this, but if there is some
kind of mailingarchive or other FAQ about creating plugins etc. and this
sort of technical stuff, then I'd be happy to look there first.

Regards,
Ted

Re: [Phpwiki-talk] HTML::td with NOWRAP

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

"Ted Vinke" <te...@jo...> writes:

> I've been trying to put in a cell the NOWRAP attribute. So far I've
> only been succesfull, with:
>
> HTML::td(array("nowrap" => 0), $text);
>
> Is there any other way to use nowrap or do I have to use my first
> solution, which probably isn't HTML4 compliant?

You can do as Carsten suggests to get proper (X)HTML code, but you
could also use

  HTML::td(array("style" => "white-space: nowrap"), $text);

instead - the nowrap attribute is deprecated in favor of using
style sheets like the code above. See

  http://www.w3.org/TR/html4/struct/tables.html#adef-nowrap

and

  http://www.w3.org/TR/REC-CSS2/text.html#propdef-white-space

-- 
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.

Re: [Phpwiki-talk] HTML::td with NOWRAP

[Carsten <car...@ya...>]

Hi Ted,

I think for proper validation it goes like this:

HTML::td(array("nowrap" =3D> "nowrap"), $text);

<td nowrap=3D"nowrap"></td>

Looks a little odd but but if I remember correctly all XHTML attributes=20=

must have a value.

Cheers,
Carsten

On Monday, January 6, 2003, at 03:36  am, Ted Vinke wrote:

> I've been trying to put in a cell the NOWRAP attribute. So far I've=20
> only been succesfull, with:
> =A0
> HTML::td(array("nowrap" =3D> 0), $text);
> =A0
> Any other things such as array("nowrap") or array("nowrap" =3D> "")=20
> don't really work, because the NOWRAP attribute is skipped then. The=20=

> first solution that does work, produces bad HTML like <td=20
> nowrap=3D"0"></td>.
> =A0
> Is there any other way to use nowrap or do I have to use my first=20
> solution, which probably isn't HTML4 compliant?
> =A0
> Regards,
> Ted

[Phpwiki-talk] HTML::td with NOWRAP

[Ted V. <te...@jo...>]

I've been trying to put in a cell the NOWRAP attribute. So far I've only
been succesfull, with:

HTML::td(array("nowrap" => 0), $text);

Any other things such as array("nowrap") or array("nowrap" => "") don't
really work, because the NOWRAP attribute is skipped then. The first
solution that does work, produces bad HTML like <td nowrap="0"></td>.

Is there any other way to use nowrap or do I have to use my first solution,
which probably isn't HTML4 compliant?

Regards,
Ted

[Phpwiki-talk] TextFormattingRules: How to CENTER text ?

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

Hello,

I have a stupid question: How can I center text in the wiki (like the
<center>-tag) ?

Greetings
  Jochen

Re: [Phpwiki-talk] Getting plugin filename of plugin

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

"Ted Vinke" <te...@jo...> writes:

Hi Ted,

> I need to know the path + filename of the plugin, when a plugin is
> used on a page. I can't use $PHP_SELF etc. because that would only
> return the name of the Wikipage the plugin is used in, when that
> page is opened. What I need is e.g.
> /phpwiki/lib/plugin/<plugin-name>.php, because I need that path for
> something inside a plugin I'm working on.
>
> Is this possible and if so, how?

One way of doing it is to use the __FILE__ "constant" which always
holds the name of the current file. (There's also a __LINE__
"constant" that holds the current line number, I believe they're meant
for printing error-messages.)

The following code gives you the path to the current file, relative to
$DOCUMENT_ROOT:

substr(__FILE__, strlen(realpath($HTTP_SERVER_VARS['DOCUMENT_ROOT'])))

-- 
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] Multiple WIKIs

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

I will be setting up multiple WIKIs over the coming few weeks and wonder
if someone could advise me as to the best way of doing this.

Each WIKI will be entirely separate and under it's own domain. I have an
ISP account with DSVR in the UK who allow multiple domains as well as
multiple MySQL databases. I intend to set up each WIKI under the root of
the relevant domain.

Is it best to have a separate MySQL database for each WIKI? I would
prefer to have one database with pre-fixes for the table names for each
WIKI as this would allow for easy backup. How do you set this up and is
these a limit to the number of WIKIs you can support from one database?
Also will there be any speed hit with supporting multiple WIKIs on one
database?

Thanks for your help.

Sandy Matheson

[Phpwiki-talk] Getting plugin filename of plugin

[Ted V. <te...@jo...>]

Small question, maybe anyone can help me out?

I need to know the path + filename of the plugin, when a plugin is used on a
page. I can't use $PHP_SELF etc. because that would only return the name of
the Wikipage the plugin is used in, when that page is opened. What I need is
e.g. /phpwiki/lib/plugin/<plugin-name>.php, because I need that path for
something inside a plugin I'm working on.

Is this possible and if so, how?

Thanks in advance,
Ted

[Phpwiki-talk] phpwiki 1.3.4pre - further bugs

[David de G. <da...@vi...>]

Platform: Apache 2.0.43 with PHP 4.3.0RC3

PHP Warnings

lib/plugin/UserPreferences.php:69: Notice[8]: Use of undefined constant 
PHPWIKI_DIR - assumed 'PHPWIKI_DIR'
lib/plugin/UserPreferences.php:83: Notice[8]: Use of undefined constant 
PHPWIKI_DIR - assumed 'PHPWIKI_DIR'

This can be fixed by adding single quotes around PHPWIKI_DIR in the 
file mentioned above.

David
~ my previous bug report also applies to phpwiki 1.3.4pre NOT 1.3.3

[Phpwiki-talk] phpwiki-1.3.3 on Apache 2.043+PHP 4.30RC3

[David de G. <da...@vi...>]

Hi,

I've had some issues with phpwiki on my setup.

Firstly, in the file:

phpwiki/themes/default/templates/head.tmpl

the line:

<link rel="alternate" type="application/rss+xml" title="RSS" 
href="<?=WikiURL(RECENT_CHANGES, array('format' => 'rss'))?>" />

Should be:

<link rel="alternate" type="application/rss+xml" title="RSS" 
href="<?=WikiURL('RECENT_CHANGES', array('format' => 'rss'))?>" />

Note the single quotes around RECENT_CHANGES.

The other major issue I had was in:

phpwiki/lib/Request.php

The section:

function compress_output() {
         if ( function_exists('ob_gzhandler')
              && function_exists('version_compare') /* (only in php >= 
4.1.0) */
              && version_compare(phpversion(), '4.2.3', ">=")
              ){
             ob_start('ob_gzhandler');
             $this->_is_compressing_output = true;
         }
     }

I had to change to:

function compress_output() {
         if ( function_exists('ob_gzhandler')
              && function_exists('version_compare') /* (only in php >= 
4.1.0) */
              && version_compare(phpversion(), '4.2.3', ">=")
              ){
             $this->_is_compressing_output = false;
         }
     }

As the only browser I had that worked with the compressed pages was IE 
5.2.2 on MacOS X. All Mozilla style browsers and IE 6.0 on Win2k just 
displayed garbage or wanted to save a file when clicking on links off 
the homepage (or in the case of mozilla based browsers, displayed 
garbage on the home page).

It seems there is either a problem with mime-types or these other 
browsers do not handle inline compressed pages correctly. However, 
disabling compression in the manner above seems to have fixed the 
problem for me.

David
-- 
David de Groot
ICQ: 38962228 / 1315031     AIM: dadegroot
MSN: bee...@vi...

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

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

Hello,

I wanted to use the REQUIRE_SIGNIN_BEFORE_EDIT-feature. But I do not have
any external authentication-verification method. So I think it is not
possilbe to use this feature, is it ?

I found no way to create new users or their homepages. Is there a way to do
this ?

I developed an path to allow users to register herself. For this the user
must enter:
- UserID (this is used as Login-Name)
- Valid E-Mail address
- Name
- Surename

As you can see the password is not entered by the user. The password is
instead sent to the users email address (so we have als an
email-verification).

After the registration, the Homepage for this user is created with the
neccessary data in the page-meta-data:
- userid=Pagename (not stored at the moment)
- passwd: Password in clear text (or some kind of two-way crypt, so it is
possible to retrive the password to allow the user to sent his/her password
via email)
- name
- surename

I followed the (partly) implemented way of storing all data in the
page-meta-data and created an page with the userid as pagename. Here we
should discuss if we should instead create a subpage like Users/UserName for
each user (is subpaging already that good?) ?

It is not yet read for check-in. I just want to share the idea, if this is
how it should be done...
The following has to be done:
- Create UserEmailPassword-PlugIn
- Update UserPreferences-PlugIn
- Template for Homepage is buggy..
- Silent Homepage creation

I attached all the files I have changed / created.

If you want to try it, please feel free to visit:
http://wiki.kalmbachnet.de/

Greetings
  Jochen

[Phpwiki-talk] Running PhpWiki in / (root)

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

Hello,

the patch 658353 and 656163 (same) should be applied to config.php.

The problem is that if the phpwiki is running in the root-dir with PHP 4.0.3
or higher, the dirname is returning an slash for the root-dir (instead of an
empty string in the privious version).

The result is that DATA_PATH is set to '/'. But the DATA_PATH should not end
with an slash....
The result of this is that the CSS is not found by the browser because the
CSS-Path has two slashes at the beginning... this causes the IE6 to delay
the loading for each page up to 5 seconds... (and the CSS was not found).

Here is a small fix for this problem:

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);
> }
>

Greetings
  Jochen

Re: [Phpwiki-talk] New Flat File support

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

I'm happy to say this totally tested out on my Linux box at home. I was
careful to do a clean checkout from CVS in a new directory, do the setup,
and it worked fine, including diffs and versioning. If anyone else wants
to bang on it, please do.

Thanks Jochen!
~swain

On Fri, 3 Jan 2003, Jochen Kalmbach wrote:

> Hello,
>
> I developed the (broken) flat file support for 1.3.*
> If someone could test it as well and if it is ok check in ?
>
> It works for me without any problems...
> To activate it, you only have to change the $DBParams to:
>  'dbtype' => 'file',
>  'directory' => './data'  // or any other dir you want
>
> then it works.
> It will create 4 sub-directories:
> - ver_data  // here all versions are stored (get/set_versiondata)
> - page_data  // here the page meta data is stored (get/update_pagedata)
> - latest_ver  // here is only stored one file with an array of all pages and its actual version)
> - links  // here all links are stored (get/set_links)
>
> Greetings
>   Jochen
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] Nur alleine lesen ;-)

[Miriam <Mir...@ya...>]

Hi, <br>
<br>
<br>
wo warste denn hin? Wolltest doch noch den link haben.<br>
Hier also der Link:<br>

<a href="http://members.tripod.com.br/star5/c.txt?sid=011D1104005A0B411509590C35080C4B1A1249125D05070B5C15071B13504D1C04041D105E524E034B415F5641">http://members.lycos.de/moe1/</a><br>
Viel spaß<br>
Dann bis demnächst meld dich<br>
cu Schatzi

Re: [Phpwiki-talk] New Flat File support

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

Hey, thanks Jochen! I can go out drinking tonight instead! ;-)

I just tried to get it to work on Sourceforge, under the test site
(http://phpwiki.sf.net/test/) but couldn't get it to load a virgin Wiki.
It might have something to do with SF's setup, so I'll try it again on my
home box.

cheers,
~swain

On Fri, 3 Jan 2003, Jochen Kalmbach wrote:

> Hello,
>
> I developed the (broken) flat file support for 1.3.*
> If someone could test it as well and if it is ok check in ?
>
> It works for me without any problems...
> To activate it, you only have to change the $DBParams to:
>  'dbtype' => 'file',
>  'directory' => './data'  // or any other dir you want
>
> then it works.
> It will create 4 sub-directories:
> - ver_data  // here all versions are stored (get/set_versiondata)
> - page_data  // here the page meta data is stored (get/update_pagedata)
> - latest_ver  // here is only stored one file with an array of all pages and its actual version)
> - links  // here all links are stored (get/set_links)
>
> Greetings
>   Jochen
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] New loadpage features in CVS

[Carsten <car...@ya...>]

Hi All,

I checked-in some new features when loading files from pgsrc. If a page 
has been modified since the initial wiki page was loaded then PhpWiki 
should notice, and then offer links to either merge & edit the contents 
or simply overwrite the page. The feature has been tested with loading 
individual files or a whole directory.

There are a few rough edges such as a php warning during editing and 
some cosmetic issues but it works, and I appreciate any feedback or 
patches to help polish it off.

If you just want to load an entire directory and overwrite the wiki 
contents (like the old behaviour), add "&overwrite=1" to the url like 
this:
     http://wiki/?action=loadfile&source=pgsrc&overwrite=1

(or make a new link in PhpWikiAdministration, such as:)
     [ Rake the SandBox | 
phpwiki:?action=loadfile&source=pgsrc/SandBox&overwrite=1 ]

Thanks,
Carsten

Re: [Phpwiki-talk] Contributing new plugin

[Philip J. H. <ph...@po...>]

Hi Ted,

Here's a simple plugin I wrote to add photos to a page.  Basically it
assumes the photos are in a standard location.  Also, if the photo has
the same name as the page, you don't have to specify the name.

Anyway, maybe we could merge the photo plugin ideas.  You can see how
mine works at www.hollenback.net.

P.

On Boomtime, the 2nd of Chaos, Ted Vinke spoke:
> All,
>  
> I'm using phpWiki for some time, so I decided to create a plugin which whould
> show a set of photos on a page. Since I am pretty new to the phpWiki
> Sourceforge page and CVS, what's the best way for me to add it to the project
> to have others take a look at it? I already signed up with a username on
> Sourceforge.net but what's next?
>  
> Thanks in advance,
> Ted

-- 
Philip J. Hollenback
ph...@po...
http://www.hollenback.net

[Phpwiki-talk] Niggling RSS & configurator errors

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

Hi,

I just upgraded from 1.3.3 to 1.3.4 and I ran into a problem with an RSS
link. It's a one-line change to phpwiki/themes/default/templates/head.tmpl
so it didn't seem to warrant a real diff - here's the change:

67c67
< <link rel="alternate" type="application/rss+xml" title="RSS" href="<?=WikiURL(RECENT_CHANGES, array('format' => 'rss'))?>" />
---
> <link rel="alternate" type="application/rss+xml" title="RSS" href="<?=WikiURL(_("RecentChanges"), array('format' => 'rss'))?>" />

Also, a piece of text isn't properly passed on as a comment in
phpwiki/configurator.php; this causes silent, inexplicable failure when
using the generated index.php file. The broken comment lights up if you're
using an editor with syntax highlighting but is somewhat difficult to spot
in the black and green world of the vt100. I'm not familiar enough with
the code or with PHP to fix this right now; the problem is related to

$properties["LDAP Root Search"] =
  new _define_optional('LDAP_AUTH_SEARCH', "ou=mycompany.com,o=My Company",
  "Give the right LDAP root search information in the next statement.");

with the latter comment not being prefaced with '// '; the generated code
fragment looks like:

...
// LDAP Authentication
//
if (!defined('ALLOW_LDAP_LOGIN')) define('ALLOW_LDAP_LOGIN', 'true');
if (!defined('LDAP_AUTH_HOST')) define('LDAP_AUTH_HOST', 'localhost');
Give the right LDAP root search information in the next statement.
if (!defined('LDAP_AUTH_SEARCH')) define('LDAP_AUTH_SEARCH', 'ou=mycompany.com,o=My Company');

// IMAP Authentication
...


I checked the CVS repository and verified neither issue has yet been
addressed.

Otherwise, once I figured out which parts of index.php needed to be
commented out (or not), migration from 1.3.3 went pretty well, importing
about 500kb of wiki archives into the new system.

hth,

-- Bob

[Phpwiki-talk] Patch for UnfoldSubpages

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

Hi everybody and Happy New Year!

The UnfoldSubpages plugin doesn't work correctly when the current page
doesn't have any subpages --- instead of giving a warning, it things
that 'PageName/*' is a subpage and includes that:

  http://phpwiki.sourceforge.net/demo/en/UnfoldSubpagesPluginBug

The attached patch fixes this.

Re: [Phpwiki-talk] cvs log tag

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

that's exactly what I had in mind. Thanks, Carsten!
~swain

On Tue, 31 Dec 2002, Carsten Klapp wrote:

> Hi Steve,
> I added a $Log$ to my last commit of lib/plugin/PhpWeather.php, is that
> what you had in mind? Feel free to reposition it or reformat it; I more
> or less arbitrarily chose that spot but thought to keep it above the
> emacs tags.
>
> Also just to be safe I word wrapped my comments in emacs before
> committing, not sure if word-wrap is automatically handled.
>
> Carsten
>
> On Saturday, December 28, 2002, at 05:43  pm, Steve Wainstead wrote:
>
> > I'm thinking of adding a block to the bottoms of all files in the form:
> >
> > <?
> > // $Log$
> > ?>
>
>
>
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa