phpwiki-talk

Re: [Phpwiki-talk] creating users

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

On Sun, 2003-01-26 at 05:30, Jochen Kalmbach wrote:
> > I am testing this code.  I see one problem.  Can I "authticate" current
> > users who signed in via BOGO?
> 
> You should be able to use the BOGO login, but then you have no
> authentication...

That what I was asking.  I was trying to add this to a current site. 
There are already users there (few).  I was trying to autehticate
existing users.

Even if I run separate code, that would be fine (prefer not to run
direct SQL, but I can handle that too).

> 
> > And I get an error when ... NewUser:
> > Parse error: parse error in
> > /home/httpd/html/wiki/clients/alert2/lib/Template.php(117) : eval()'d
> > code on line 2
> 
> This is a well known bug. The problem is that the current "homepage.tmpl" is
> not valid.
> Simple create your own and it will work...
> 

Can you email a working default home.  I am not sure what is broken in
the page (and its only 13 lines long!).


Thanks.

> Greetings
>   Jochen
-- 
Zot O'Connor

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

Re: [Phpwiki-talk] auto /Calendar, /Preferences, CreateHomePageCB (was Re: do subpages work?)

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

Those subpages work if they would exist.
But they are not automatically created. Maybe they should?

The <User>/Preferences subpage is just a shorthand for the 
UserPreferences Plugin.

Jochen Kalmbach schrieb:
>>I don't see the need for each user to have their own preferences page
>>anymore, the preferences are actually now stored in the database in the
>>user's page. People can just use the common UserPreferences page to
>>change their settings.
> 
> This is right. We only need the common UserPreferences-Page, because
> every user has an own homepage. So we also removed the
> "create homepage" button.
> But this page also needs some update...

Well, it's not sure that every user has it's own homepage.
if so it would be easy to get at his preference data.

>>Having said the above, I also think we should eliminate the "Create
>>HomePage" checkbox (which also doesn't work yet) upon Sign In.
> 
> This is already removed in the patches.

Hmm. The optional "Create HomePage" button is not bad.
(if it would work).

>>If someone decides to "stay" at a wiki they can create their own home
>>page,
> As you said. The homepage is already created. So they can only modify
> his/her page.
> 
>>it's fun and an opportunity to practice WikiMarkup for new users,
>>quick to do for experienced Wiki

> The actual patches are at
> http://wiki.kalmbachnet.de/userdata/kajo0011/phpwiki-UserManagement-v4.zip
> (full files)

Thanks, I'll try to commit these.
Unfortunately I had a lot of work to do in the last months.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] wiki 1.3.4 (fwd)

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

---
                  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
---------- Forwarded message ----------
Date: Thu, 23 Jan 2003 18:11:54 -0500
From: Matthew Kingston <Mat...@ro...>
To: sw...@pa...
Subject: wiki 1.3.4

Hi,

I'm the current wikimeister for the Peace and Environment Resource
Centre in Ottawa, Ontario. We've been using phpWiki for some time now
and have found it quite useful so thanks a lot for the work you've done
to make it happen.

Recently I decided to upgrade to version 1.3.4 (from version 1.3.3)
because I liked some of the features that you have added. But shortly
after installing it (it's went up yesterday, came down today) we noticed
that quite a number of pages were reverting to earlier versions. As if,
it seems, that the content of some old version of the page replaced the
content current version (which still has the correct date/author) as the
archive is cleaned. I thought I should let you know about this, since it
seems like a fairly serious bug. The only code modifications we've done
from your 1.3.4 release was a change to BlockParser.php (attached) to
provide old style tables in new markup (which you're free to use if
you'd like.)

Matt Kingston

Re: [Phpwiki-talk] Not recognize USE_PATH_INFO = false

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

> The only problem was a 5-8
> second delay for loading pages

This is a well known bug (at least since 12.12.02)... if you have your wiki
not in an subfolder of your domain, then the CSS-path is sent wrong to the
browser. The browser then tries to load this css (with an invalid domain
path). This takes 2-8 seconds).

No one of the developer is able to check this in...

So you have to fix it by yourself:

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

[Phpwiki-talk] Not recognize USE_PATH_INFO = false

[Robin C. <rsc...@gt...>]

Hi,

I installed phpwiki v.1.3.4 a few weeks ago - made some minor
adjustments and everything worked great. The only problem was a 5-8
second delay for loading pages (using PEAR + MYSQL). It worked fine with
the USE_PATH_INFO set to false (ie. links would be created using
index.php?pagename=HomePage, etc.)

Before I started troubleshooting the speed problems, I wanted to start
with a clean slate - so I removed all the phpwiki files and reinstalled
it using the exact same tarball I used a few weeks earlier.  Now I can't
get the links to work (they create the index.php/HomePage,  and no I
don't want to use this function).  I've set USE_PATH_INFO to false in
the index.php (and anywhere else I could find it.)  I've tried
everything I can think of to make it work - but to no avail.  Any
thoughts?  How could I trouble shoot this (I'm still learning PHP)

Server:  RH 8.0, Apache 2.0.40, php 4.2.3 (remained unchanged from prior
install)

TIA
Robin

Re: [Phpwiki-talk] creating users

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

> I am testing this code.  I see one problem.  Can I "authticate" current
> users who signed in via BOGO?

You should be able to use the BOGO login, but then you have no
authentication...

> And I get an error when ... NewUser:
> Parse error: parse error in
> /home/httpd/html/wiki/clients/alert2/lib/Template.php(117) : eval()'d
> code on line 2

This is a well known bug. The problem is that the current "homepage.tmpl" is
not valid.
Simple create your own and it will work...

Greetings
  Jochen

Re: [Phpwiki-talk] PhpWiki enhancements and a humble request for some feedback...

[Rui C. <rui...@ac...>]

On Saturday, Jan 25, 2003, at 00:30 Europe/Lisbon, Joby Walker wrote:

> Rui,
>
> We always welcome new developers.  I'm pretty new myself...

I can contribute my code (and layouts/theme/templates), as soon as I 
can remove the embarassing bits.
  :)

> More comments inline:
>
> Rui Carmo wrote:
>> Some of the customization was done via plugins, and you can see a 
>> (very) brief description of the SeeAlso and DotGraph plugins here:
>> http://mac.against.org/space/SeeAlso
>
> Is this the changing gradient links at the bottom?

Yep. Everything2 has them for a couple years now. That's SeeAlso, which 
is currently a patched BackLinks with some (slightly broken) filtering. 
Bit heavy (I've limited it to 20 links), might need to be cached. I've 
also modified the getPageLinks(?) functions to parse included pages and 
add them to the link list (that's the really heavy part).

>> http://mac.against.org/space/DotGraph
>
> Very nice most definately welcome.

Basically a VisualWiki that lets you write the GraphViz code inline. 
Has some problems with bad graphs (error messages don't print) and 
caching (caching is done in function of the plugin arguments, not an 
MD5 hash of anything between <?plugin <-> ?>, which is the proper way 
IMHO)

>> 1) CamelCase
>
> You can change the PCRE for WikiWords in index.php (currently there) 
> to something impossible so that nothing matches.

Yep, my point was more along the lines of contributing my users' 
feedback. I can't remember if I had to change anything to get the 
case-insensitive [link] matches, though (but then, it's getting late 
here).

>> 2) HTML (or simplified HTML) markup
>
> This has been a frequent request, but it is just a horrible idea.  The 
> point of the wiki syntax is to force standardization across the entire 
> wiki, and it prevents a page from rendering broken.  If you introduce 
> HTML everywhere then you end up with some very broken wikis.

Not if you parse/reparse it into XML. That would also allow for some 
preprocessing of IncludePages and similar plugins, leading to better 
performance ;)

>> 3) File attachments (and Wiki markup to refer to them)
>
> Aren't uploads already in 1.3.4?  Haven't paid much attention to that 
> side...

Yeah, but just uploading files to a directory (which seems to be the 
basic functionality currently in CVS AFAIK) doesn't cut it... Too many 
issues regarding filenames, collisions, access levels, etc.

>> 4) ACLs.
>
> We are already working on a Unix style User,Group,Other (rwx) 
> Permissions
>
> http://phpwiki.sourceforge.net/phpwiki/PagePermissions

Yep. I was just wondering if it was in the code somewhere. I started 
off from 1.3.2 stable, and pecking through CVS wasn't very 
enlightenting as to what the current state of affairs might be.

>> 5) Comments. Not inline comments (Wiki editing), but distinct entries 
>> attached to a parent node. It comes right alongside ACLs as a base 
>> requirement. I've toured the alpha Wiki, and I've seen some 
>> interesting things there, but it feels like it should be an intrinsic 
>> thing - people are wary of editing other people's work and breaking 
>> something.
>
> Not sure what you mean here.  SubPages have been added...

Hmmm... this (http://snipsnap.org/comments/SnipSnap-war) is pretty much 
it. note the simple layout and emphasis on the comment author's name. 
SubPages sort of works, but feels a bit odd (I have plenty of naive 
users to show these things to, and usability-wise, SubPages is tricky 
to grasp). I might have a go at hacking a nice layout into it. :)

>> 6) XML.
>
> Not a very good idea.  If we store the WikiPages as XML, then we will 
> have to convert from XML to WikiSyntax for an edit.  Providing an XML 
> data port should be sufficient.  This can be looked at again (it has 
> been mentioned many times), but IMHO there are higher priorities.

Well, that's a matter of belief systems :)

I don't see any issues with converting/reconverting, provided the 
converter is lenient enough. I've been mostly concerned with the 
parsing and the built-in PHP/XML functions, but nothing usable has come 
out (yet - we use XML and SOAP extensively, so it's just a matter of 
time).

I'm also toying with the idea of using XML and XPath to build a fully 
XML-based Wiki (Cocoon springs to mind as a base), but I haven't had 
much time to investigate (nor does it make much sense with so many Wiki 
frameworks around).

>> 7) CVS - not as a backend, but as an integrated tool.
>
> We do offer integrated diffs and versioning, which can be in a real db 
> rather than the file structure (huge plus). So I am not sure of the 
> advantage.

No no no, not as versioning. :) A CVS backend to a Wiki is not to be 
underestimated, but that's not what I was getting at.

Picture this: You have a RecentChanges-like page that tracks CVS 
commits. Commit comments can (easily) contain WikiLinks, hence 
providing direct links to Wiki nodes. Instant progress tracking ;)

Check this out: http://cvs.cvstrac.org/timeline

>> The main PhpWiki has a rather sketchy feature roadmap.
>
> Yeah... some organization would be nice, but my priorities:
>
> 1) New configuration system
> 2) User Authentication system
> 3) Group Authentication system
> 4) PagePermissions
>
> jbw
>

Seems OK to me. But why Group Auth? PagePermissions would be the same 
issue, no? :)

Is there any info on the database schema changes for those?

R.

Re: [Phpwiki-talk] PhpWiki enhancements and a humble request for some feedback...

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

Rui,

We always welcome new developers.  I'm pretty new myself...

More comments inline:

Rui Carmo wrote:
> Some of the customization was done via plugins, and you can see a (very) 
> brief description of the SeeAlso and DotGraph plugins here:
> 
> http://mac.against.org/space/SeeAlso

Is this the changing gradient links at the bottom?

> http://mac.against.org/space/DotGraph

Very nice most definately welcome.

> 1) CamelCase 

You can change the PCRE for WikiWords in index.php (currently there) to 
something impossible so that nothing matches.

> 2) HTML (or simplified HTML) markup

This has been a frequent request, but it is just a horrible idea.  The 
point of the wiki syntax is to force standardization across the entire 
wiki, and it prevents a page from rendering broken.  If you introduce 
HTML everywhere then you end up with some very broken wikis.

> 3) File attachments (and Wiki markup to refer to them) 

Aren't uploads already in 1.3.4?  Haven't paid much attention to that 
side...

> 4) ACLs. 

We are already working on a Unix style User,Group,Other (rwx) Permissions

http://phpwiki.sourceforge.net/phpwiki/PagePermissions

> 5) Comments. Not inline comments (Wiki editing), but distinct entries 
> attached to a parent node. It comes right alongside ACLs as a base 
> requirement. I've toured the alpha Wiki, and I've seen some interesting 
> things there, but it feels like it should be an intrinsic thing - people 
> are wary of editing other people's work and breaking something.

Not sure what you mean here.  SubPages have been added...

> 6) XML. 

Not a very good idea.  If we store the WikiPages as XML, then we will 
have to convert from XML to WikiSyntax for an edit.  Providing an XML 
data port should be sufficient.  This can be looked at again (it has 
been mentioned many times), but IMHO there are higher priorities.

> 7) CVS - not as a backend, but as an integrated tool. 

We do offer integrated diffs and versioning, which can be in a real db 
rather than the file structure (huge plus). So I am not sure of the 
advantage.

> The main PhpWiki has a rather sketchy feature roadmap.

Yeah... some organization would be nice, but my priorities:

1) New configuration system
2) User Authentication system
3) Group Authentication system
4) PagePermissions

jbw

Re: [Phpwiki-talk] installing PHPwiki

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

Sorry Peter,

index2.php should only have 53 or so lines (but it isn't used), 
index.php is much longer.

But since you have index2.php you're using 1.3.4.

It looks like your link generation is off.  By default, they should look 
similar to:

http://experience.lds.com/wiki/index.php/ReleaseNotes

You might want to follow the PrettyWiki instructions:

http://phpwiki.sourceforge.net/phpwiki/PrettyWiki

jbw

Peter VanDijck wrote:
> index.php only has 53 lines?
> 
> Joby Walker wrote:
> 
>>It is in the index.php file ~line 80.
>>
>>jbw
>>
>>Peter VanDijck wrote:
>>
>>>I'm trying to figure that out :) Where can I find that? I looked at the
>>>files explaining install, mysql install, changelog, the homepage but
>>>they don't mention version?
>>>
>>>Joby Walker wrote:
>>>
>>>
>>>>Peter,
>>>>
>>>>Always glad to have someone new.
>>>>
>>>>Which version of PHPWiki did you install?
>>>>
>>>>jbw
>>>>
>>>>Peter VanDijck wrote:
>>>>
>>>>
>>>>>Hi,
>>>>>Great code! The install went fine (on FreeBSD with PHP4.02 and mySQL).
>>>>>But the links all go to the same indexpage, for example:
>>>>>http://experience.lds.com/wiki/index.php?ReleaseNotes goes to the same
>>>>>index.php page as index.php without a query string. Any ideas?
>>>>>Peter
>>>>>
>>>>>
>>>>>-------------------------------------------------------
>>>>>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

[Phpwiki-talk] PhpWiki enhancements and a humble request for some feedback...

[Rui C. <rui...@ac...>]

Hello,

Apologies for the long subject line. I tend to add summaries to 
everything these days. :)
Also, apologies for the rather long(ish) message, which we can break 
down into separate threads as discussion (hopefully) progresses.

First off, I've been fiddling with PhpWiki for a while now. After three 
months of not-very-subtle hacks, I now have a customized version up at 
http://mac.against.org that draws heavily from things like 
http://everything2.com and http://snipsnap.org.

Some of the customization was done via plugins, and you can see a 
(very) brief description of the SeeAlso and DotGraph plugins here:

http://mac.against.org/space/SeeAlso
http://mac.against.org/space/DotGraph

I've in fact been considering moving to SnipSnap - hence the URL 
structure I'm using - but have decided to stick around for a while and 
figure out where PhpWiki is heading and how I could contribute.

I've also deployed a modified version of my personal Wiki inside my 
company, where it's being used for software/process modelling (hence 
DotGraph) and project documentation (hence SeeAlso). Initial feedback 
was very encouraging, but there were several interesting issues and 
requirements that I came across and that I would like to have the 
list's opinion on:

1) CamelCase is extremely confusing to some people. Square brackets are 
easy to grasp, however, which is interesting. Of special note was the 
fact that coding standards (thisIsAModuleName) sprung "?" all over the 
place when posting code fragments, but that is a separate issue.

Yes, I know it's traditional. I've used Wikis for a while now, but only 
with techies. Case-insensitive bracketed links seem to work better 
(we're Portuguese, so cultural background must have some bearing on 
this that I've yet to grasp).

2) HTML (or simplified HTML) markup, with <code>/<pre> blocks exempt 
from parsing and "normal" headings, tables, etc. And not just for 
normal markup - RawHtml is  extremely useful for inserting HTML form 
mock-ups inside the Wiki, enabling developers to quickly show to 
prospective users what the project will look like, etc., but is fiddly 
to use (oh, yes, normal users abhore plugin syntax...)

3) File attachments (and Wiki markup to refer to them) are of paramount 
importance. I'm considering storing them in the database (an attachment 
becoming a Wiki "node" in its own right) and using something along the 
lines of {inline: NodeName} to refer to them. I was wondering what work 
was being done along these lines, and I've seen some recent posts 
concerning this, but have yet to fetch the code and see how this was 
handled.

Coding this would consist essentially of changing the database schema 
to hold the node mimetype alongside the content, doing some extra 
testing in getCurrentRevision(?) and suchlike and implementing a 
view.php URL handler.

(A wanton hack like serialize()ing stuff into the current database 
schema seems to work, but I've yet to do more than a couple 
experiments.)

4) ACLs. Not just user login (I will probably have to integrate our 
Wiki with an LDAP directory, but Apache can sort that out for me), but 
the ability for any given user to lock a page to prevent users on the 
same privilege level from changing it. It can probably be a Unix-like 
Owner-Group-All field, but I'd like to know what people's opinions are 
on this. User management (which is implied) is done outside the box.

5) Comments. Not inline comments (Wiki editing), but distinct entries 
attached to a parent node. It comes right alongside ACLs as a base 
requirement. I've toured the alpha Wiki, and I've seen some interesting 
things there, but it feels like it should be an intrinsic thing - 
people are wary of editing other people's work and breaking something.

6) XML. Oooh. OK, this one is tricky, in the sense that yes, you can 
generate XML from Wiki markup (and I'm quite fond of the current 
XmlElement module, which seems well thought out), but the idea of 
actually storing XML instead of Wiki markup (and converting between the 
two whenever necessary) has sprung to mind. It makes a lot of sense, 
and would ensure the content is reusable if we have to re-render/import 
it/swap it with other systems. What do the developers think of this?

7) CVS - not as a backend, but as an integrated tool. CVStrac 
(http://cvs.cvstrac.org) has merged CVS, issue management and a (very 
usable) Wiki, and the idea is very appealing. Have there been any 
efforts along these lines? Issue management is also very interesting, 
but we have other tools for that.

These were the recurring issues (and some of that can be seen in my 
http://mac.against.org/space/mac.2003-01-20 node...), and I'd love to 
know what other people think.

Again, sorry for the long(ish) post, but scouring the mailing-list 
archives was not very useful in terms of understanding where PhpWiki 
stands where most of these issues are concerned, and the main PhpWiki 
has a rather sketchy feature roadmap.

So I just had to ask. :)

Best Regards,

Rui Carmo

Re: [Phpwiki-talk] creating users

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

I am testing this code.  I see one problem.  Can I "authticate" current
users who signed in via BOGO?

And I get an error when going from AllUsers to a NewUser:

Parse error: parse error in
/home/httpd/html/wiki/clients/alert2/lib/Template.php(117) : eval()'d
code on line 2

putting an error_log in front the code is  and a few date stamps, I
tracked it down to to printing the browse.tmpl, in the call to
_print($CONTENT)

<?php // -*-html-*- ?>
<!-- $Id: browse.tmpl,v 1.22 2002/02/19 23:00:26 carstenklapp Exp $ -->

<?php if (! $revision->isCurrent()) { ?>
  <p><strong><?php $this->_print(_("Note:"));?></strong>
     <?php $this->_print(_("You are viewing an old revision of this
page."));?>
  <?php $this->_print( Button('browse', _("View the current version"),
$page));?>.
  </p>
<?php } ?>

<?php $this->_print($CONTENT);?>

<div id="actionbar" class="toolbar">
<hr class="printer" noshade="noshade" />
<p class="editdate"><?php $this->_print(
$Theme->getLastModifiedMessage($revision) );?></p>


<br><!-- $Id: browse.tmpl,v 1.22 2002/02/19 23:00:26 carstenklapp Exp $
-->


<div class="wikitext"><p><br />
<b>Parse error</b>:  parse error in <b>/home/httpd/html/wiki/clients/alert2/lib/Template.php(117) : eval()'d code</b> on line <b>2</b><br /></p>
</div>

So it seems the call to _print($CONTENT) is now failing.



On Mon, 2003-01-13 at 12:01, Jochen Kalmbach wrote:
> 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" />
-- 
Zot O'Connor

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

Re: [Phpwiki-talk] installing PHPwiki

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

Peter,

Always glad to have someone new.

Which version of PHPWiki did you install?

jbw

Peter VanDijck wrote:
> Hi,
> Great code! The install went fine (on FreeBSD with PHP4.02 and mySQL).
> But the links all go to the same indexpage, for example:
> http://experience.lds.com/wiki/index.php?ReleaseNotes goes to the same
> index.php page as index.php without a query string. Any ideas?
> Peter
> 
> 
> -------------------------------------------------------
> 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

[Phpwiki-talk] installing PHPwiki

[Peter V. <pva...@ld...>]

Hi,
Great code! The install went fine (on FreeBSD with PHP4.02 and mySQL).
But the links all go to the same indexpage, for example:
http://experience.lds.com/wiki/index.php?ReleaseNotes goes to the same
index.php page as index.php without a query string. Any ideas?
Peter

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib WikiGroup.php,1.1,1.2

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

Guess this was done automatically -- cool.

jbw

Joseph (Joby) Walker wrote:
> Update of /cvsroot/phpwiki/phpwiki/lib
> In directory sc8-pr-cvs1:/tmp/cvs-serv18351/lib
> 
> Modified Files:
> 	WikiGroup.php 
> Log Message:
> Replaced tabs with four spaces
> 
> 
> Index: WikiGroup.php
> ===================================================================
> RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiGroup.php,v
> retrieving revision 1.1
> retrieving revision 1.2
> diff -u -2 -b -p -d -r1.1 -r1.2
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
> allow you to extend the highest allowed 128 bit encryption to all your 
> clients even if they use browsers that are limited to 40 bit encryption. 
> Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> _______________________________________________
> phpwiki-checkins mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-checkins

Re: [Phpwiki-talk] Re: auto /Calendar, /Preferences, CreateHomePageCB (was Re: do subpages work?)

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

Chip Rosenthal wrote:
> I'm new here, so pardon me if this is not an appropriate question ...
> but is there any discipline on this project that prevents broken code
> from being checked into CVS?  I keep running into non-functional or
> incompletely implemented functions that (IMO) really shouldn't be in a
> released codebase.  It's been quite frustrating.

This is always an appropriate question.

I try to check out new checkins and I am sure others do too, but it 
happens...  The entire user system has been in flux and we really need 
to discuss architecture so we're not just commiting new features ad hoc. 
  I really think we need to nail down that part of the system before we 
get to making/fixing the user experience (this is still a development 
release).

I have just committed the Group interface (lib/WikiGroup.php) for Group 
membership determination.  It is pretty well documented so it should be 
pretty obvious what is happening. I'd like people to check it out for 
comments and corrections.  Sorry it is so delayed (I promissed this back 
in October).

If we can get the UserAuthentication, PagePermissions and UserGroups 
straightened out a lot of these User Experience issues will be easier.

http://phpwiki.sourceforge.net/phpwiki/UserAuthentication
http://phpwiki.sourceforge.net/phpwiki/PagePermissions
http://phpwiki.sourceforge.net/phpwiki/UserGroups

jbw

Re: [Phpwiki-talk] auto /Calendar, /Preferences, CreateHomePageCB (was Re: do subpages work?)

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

Hi Carsten,

> I don't see the need for each user to have their own preferences page
> anymore, the preferences are actually now stored in the database in the
> user's page. People can just use the common UserPreferences page to
> change their settings.

This is right. We only need the common UserPreferences-Page, because
every user has an own homepage. So we also removed the
"create homepage" button.
But this page also needs some update...

> Having said the above, I also think we should eliminate the "Create
> HomePage" checkbox (which also doesn't work yet) upon Sign In.

This is already removed in the patches.

> If someone decides to "stay" at a wiki they can create their own home
> page,

As you said. The homepage is already created. So they can only modify
his/her page.

> it's fun and an opportunity to practice WikiMarkup for new users,
> quick to do for experienced Wikizens.

That´s right.

The actual patches are at
http://wiki.kalmbachnet.de/userdata/kajo0011/phpwiki-UserManagement-v4.zip
(full files)

I cannot do an diff, because the pserver access is most of the time down...

Greetings
  Jochen

[Phpwiki-talk] Re: auto /Calendar, /Preferences, CreateHomePageCB (was Re: do subpages work?)

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

On Fri, Jan 17, 2003 at 08:44:10AM -0500, Carsten wrote:
> These don't work for me either, I think they were supposed to be 
> automatically created. Otherwise subpages work great.

Okay -- thank! -- I think I get it now ... I see there is code in the
WikiUser->createHomepage() method that is supposed to create these
... but on inspection I don't think this could have ever worked.

I'm new here, so pardon me if this is not an appropriate question ...
but is there any discipline on this project that prevents broken code
from being checked into CVS?  I keep running into non-functional or
incompletely implemented functions that (IMO) really shouldn't be in a
released codebase.  It's been quite frustrating.

> Having said the above, I also think we should eliminate the "Create 
> HomePage" checkbox (which also doesn't work yet) upon Sign In.

I agree ... *especially* with Jochen's new UserRegistration function.
The home page should be created when the user registers.  If they are
doing a bogologin, then I don't see any reason to create one.

Anyway, it now appears to me the current homepage template doesn't work
and hasn't been used, and so it won't cause any problems to replace it
with one that supports the new UserRegistration function.  Would folks
agree?

-- 
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] Laptop Plamtop Mumbai Rs.17300 & other useful items

[mylaptop <myl...@in...>]

LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+VGhpcyBtZXNzYWdl
IHdhcyBzZW50IGJ5IEV4cHJlc3MgRGlyZWN0IEVtYWlsIEJsYXN0ZXIgVjUuMSwgPGJyPnlv
dSBjYW4gZG93bmxvYWQgaXQgZnJvbTogPGEgaHJlZj0iaHR0cDovL3d3dy5mYXN0YnVsa2Vt
YWlsLmNvbSI+d3d3LmZhc3RidWxrZW1haWwuY29tPC9hPjxicj5FeHByZXNzIERpcmVjdCBF
bWFpbCBCbGFzdGVyIGlzIGEgcG93ZXJmdWwgZW1haWwgbWFya2V0aW5nIHRvb2whITxicj4t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPjxicj48IWRvY3R5cGUg
aHRtbCBwdWJsaWMgIi0vL3czYy8vZHRkIGh0bWwgNC4wIHRyYW5zaXRpb25hbC8vZW4iPg0K
PGh0bWw+DQo8aGVhZD4NCiAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29u
dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KICAgPG1ldGEgbmFtZT0i
QXV0aG9yIiBjb250ZW50PSJ2QGJiLmNvbSI+DQogICA8bWV0YSBuYW1lPSJHRU5FUkFUT1Ii
IGNvbnRlbnQ9Ik1vemlsbGEvNC43OSBbZW5dIChXaW45ODsgVSkgW05ldHNjYXBlXSI+DQog
ICA8dGl0bGU+TUFTU19FTUFJbF9IVE1MX0xBUFRPUDwvdGl0bGU+DQo8L2hlYWQ+DQo8Ym9k
eT4NCiZuYnNwOw0KPGNlbnRlcj4NCjxwPjxmb250IGZhY2U9IkFyaWFsIE5hcnJvdyI+PGZv
bnQgY29sb3I9IiMwMDAwMDAiPjxmb250IHNpemU9LTE+YWxzbyAtb3RoZXImbmJzcDsNCnZl
cnkgdXNlZnVsJm5ic3A7Jm5ic3A7IGF1dG9tYXRpb24gLSBnYWRnZXRzLSAvIGl0ZW1zLSBm
b3IgaG9tZS8gb2ZmaWNlPC9mb250PjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0i
QXJpYWwgTmFycm93Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGZvbnQgc2l6ZT0tMT5zZWUm
bmJzcDsNCmF0Jm5ic3A7Jm5ic3A7Jm5ic3A7IHd3dy5ib21iYXlzZXJ2aWNlLmNvbTwvZm9u
dD48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9IkFyaWFsIEJsYWNrIj48Zm9udCBj
b2xvcj0iI0ZGOTkwMCI+PGZvbnQgc2l6ZT0rMj5MQVBUT1ANCi0gUEFMTVRPUCAuLjwvZm9u
dD48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9IkFyaWFsIE5hcnJvdyI+PGZvbnQg
Y29sb3I9IiNGRjk5MDAiPjxmb250IHNpemU9KzI+LTwvZm9udD48Zm9udCBzaXplPSsxPnBk
YS1pcGFxLQ0KcG9ja2V0IHBjLSB0YWJsZXQgcGMgLSBoYW5kIGhlbGQgcGMgPXNtYWxsIGxh
cHRvcC0gZXRjLjwvZm9udD48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9IkFyaWFs
IEJsYWNrIj48Zm9udCBjb2xvcj0iIzMzNjZGRiI+VVNFRCZuYnNwOyBORVcmbmJzcDsNCi0g
QlVZIFNFTEw8L2ZvbnQ+PGZvbnQgY29sb3I9IiNGRjAwMDAiPiA8L2ZvbnQ+PGZvbnQgY29s
b3I9IiMwMENDMDAiPlNFUlZJQ0VTDQo8L2ZvbnQ+PGZvbnQgY29sb3I9IiM2NkZGOTkiPkZS
T00NCk1VTUJBSTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2si
Pjxmb250IGNvbG9yPSIjQ0M2NkNDIj5BTFNPLSZuYnNwOyZuYnNwOyZuYnNwOw0KPC9mb250
PjwvZm9udD48Yj48Zm9udCBmYWNlPSJBcmlhbCBOYXJyb3ciPjxmb250IHNpemU9LTE+PGZv
bnQgY29sb3I9IiMwMDAwMDAiPkFMTCZuYnNwOyZuYnNwOyZuYnNwOw0KQUNDRVNTT1JJRVMm
bmJzcDsgZm9yJm5ic3A7Jm5ic3A7IGxhcHRvcCZuYnNwOyZuYnNwOyBwYWxtdG9wJm5ic3A7
IC0gVVANCkdSQURFJm5ic3A7IDwvZm9udD48Zm9udCBjb2xvcj0iI0ZGNjY2NiI+YWxzbzwv
Zm9udD48L2ZvbnQ+PC9mb250PjwvYj4NCjxicj48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+
PGZvbnQgY29sb3I9IiMzM0NDRkYiPlJFQURZJm5ic3A7IC0gPC9mb250PjwvZm9udD48Yj48
Zm9udCBmYWNlPSJBcmlhbCBOYXJyb3ciPjxmb250IGNvbG9yPSIjMDAwMDAwIj48Zm9udCBz
aXplPSsyPlAxLQ0KUDItIFAzJm5ic3A7PC9mb250Pjxmb250IHNpemU9LTE+Jm5ic3A7ID0m
bmJzcDsgTEFQVE9QIEFWQUlMQUJMRSA8L2ZvbnQ+PC9mb250PjwvZm9udD48L2I+PGZvbnQg
ZmFjZT0iQXJpYWwgQmxhY2siPjxmb250IGNvbG9yPSIjMzNDQ0ZGIj4uDQo8L2ZvbnQ+PGZv
bnQgY29sb3I9IiNGRjk5RkYiPmF0Jm5ic3A7IEJlc3QgQmFyZ2FpbiBQcmljZTwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiNGRkNDMzMiPjxmb250IGZhY2U9IkFyaWFsIEJs
YWNrIj5DT01QQVEgPSZuYnNwOyA8L2ZvbnQ+PGI+PGZvbnQgZmFjZT0iQXJpYWwgTmFycm93
Ij48Zm9udCBzaXplPSsyPklQQVENCi08L2ZvbnQ+PGZvbnQgc2l6ZT0tMT4mbmJzcDsmbmJz
cDsgUEFMTVRPUCAtJm5ic3A7PC9mb250PjwvZm9udD48L2I+PC9mb250PjxiPjxmb250IGZh
Y2U9IkFyaWFsIE5hcnJvdyI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxmb250IHNpemU9LTE+
DQpBVkFJTEFCTEUtIE5FVyA9IEFUIEJFU1QgUFJJQ0UuPC9mb250PjwvZm9udD48L2ZvbnQ+
PC9iPg0KPGJyPjxmb250IGZhY2U9IkFyaWFsIEJsYWNrIj48Zm9udCBjb2xvcj0iI0ZGMDAw
MCI+cG9ja2V0Jm5ic3A7IHBjPC9mb250Pjxmb250IGNvbG9yPSIjRkZDQ0NDIj4tDQo8L2Zv
bnQ+PC9mb250Pjxmb250IGZhY2U9IkFyaWFsIE5hcnJvdyI+PGZvbnQgY29sb3I9IiMwMDAw
MDAiPndpdGgNCmJ1aWx0IGluIC1rZXlib2FyZCA9bW9kZW0tc3Bla2VyLW1pYy08L2ZvbnQ+
PC9mb250Pg0KPGJyPjxmb250IGZhY2U9IkFyaWFsIE5hcnJvdyI+PGZvbnQgY29sb3I9IiMw
MDAwMDAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KMjAg
bWItIHdpdGggZXhwYW5zaW9uIHNsb3Qgb2YgcGNtYy0gZGVza3RvcCBjb25uZWN0aW9uIGRv
Y2tpbmcgc3RhdGlvbjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwgTmFy
cm93Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+Y29tcGFxJm5ic3A7IG1ha2UtJm5ic3A7DQpt
YW51YWwtIGNkIC1jaGFyZ2VyIGV0Yy4mbmJzcDsmbmJzcDsgSEFORCB3cml0aW5nJm5ic3A7
IG9uJm5ic3A7Jm5ic3A7DQpTQ1JFRU48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9
IkFyaWFsIE5hcnJvdyI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlJTLjE3MzAwIChVU0VEKTwv
Zm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siPjxmb250IGNvbG9y
PSIjMzNDQ0ZGIj5iZXN0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpmb3ImbmJzcDsmbmJz
cDsmbmJzcDsgPiZuYnNwOyB0aW1lJm5ic3A7IG1hbmFnZW1lbnQgJmFtcDsmbmJzcDsmbmJz
cDsmbmJzcDsNCnBlcnNvbm5lbCBtYW5hZ2VtZW50PC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBmYWNlPSJBcmlhbCBOYXJyb3ciPjxmb250IGNvbG9yPSIjMDAwMDAwIj5mb3IgcGljJm5i
c3A7IC8gZGV0YWlscw0KPiZuYnNwOyZuYnNwOyBodHRwOi8vd3d3Lm11bWJhaXNldmEuY29t
LzIwbWIuaHRtbDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2si
Pjxmb250IGNvbG9yPSIjMDBDQzAwIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2ZvbnQ+PC9m
b250Pg0KPGJyPjxiPjxmb250IGZhY2U9IkFyaWFsLEhlbHZldGljYSI+PGZvbnQgY29sb3I9
IiMwMDAwMDAiPnd3dy5tdW1iYWlzZXZhLmNvbSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOw0KJmFtcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd3d3LmJvbWJheXNlcnZpY2UuY29tPC9m
b250PjwvZm9udD48L2I+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siPjxmb250IHNp
emU9LTE+PGZvbnQgY29sb3I9IiNGRjY2MDAiPmJlJm5ic3A7Jm5ic3A7DQpmZWVsJm5ic3A7
Jm5ic3A7IGZyZWUmbmJzcDsmbmJzcDsmbmJzcDsgdG8gY2FsbDwvZm9udD48Zm9udCBjb2xv
cj0iIzMzMzNGRiI+DQosPC9mb250PjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0i
QXJpYWwgQmxhY2siPjxmb250IGNvbG9yPSIjMzMzM0ZGIj48Zm9udCBzaXplPS0xPmZvciZu
YnNwOyZuYnNwOw0KbW9yZSZuYnNwOyBkZXRhaWxzJm5ic3A7ID0mbmJzcDsgcHJpY2UmbmJz
cDsgbGlzdCZuYnNwOyAvIHJlYWR5IHN0b2NrPC9mb250PjwvZm9udD48L2ZvbnQ+DQo8YnI+
PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siPjxmb250IGNvbG9yPSIjMDAwMDAwIj5UZWxlLSBN
dW1iYWkgLSAoOTEtMDIyKSZuYnNwOw0KMjU2NzU3NzA8L2ZvbnQ+PC9mb250Pg0KPGJyPjxi
Pjxmb250IGZhY2U9IkFyaWFsIE5hcnJvdyI+PGZvbnQgY29sb3I9IiMwMENDMDAiPjxmb250
IHNpemU9LTE+KA0KVElNRSZuYnNwOyAxMiZuYnNwOyBUTyBOSUdIVCAxMiAtJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7ID4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
DQpURUxFLSBMSU5FIFRSQU5TRkVSIFRPIE1PQklMRS0gQUZURVIgT0ZGSUNFIEhSUy4gKTwv
Zm9udD48L2ZvbnQ+PC9mb250PjwvYj4NCjxicj48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+
PGZvbnQgY29sb3I9IiNGRjY2MDAiPmVtYWlsLTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg
ZmFjZT0iQXJpYWwsSGVsdmV0aWNhIj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+bGFwdG9wQGJv
bWJheXNlcnZpY2UuY29tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7PC9mb250PjxiPjxmb250IGNvbG9yPSIjRkY2NjY2Ij4NCj09PSAmYW1wOzwv
Zm9udD48L2I+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9IkFyaWFsLEhlbHZldGljYSI+PGZv
bnQgY29sb3I9IiNGRjY2NjYiPmNjJm5ic3A7IGNvcHkmbmJzcDsNCi1mb3Igc2FmZSZuYnNw
OyBzaWRlID4mbmJzcDs8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiPiZuYnNwOyZuYnNw
OyBteWxhcHRvcEBpbmRpYXRpbWVzLmNvbSZuYnNwOyZuYnNwOw0KPC9mb250PjxiPjxmb250
IGNvbG9yPSIjRkY2NjY2Ij4mYW1wOzwvZm9udD48L2I+PGZvbnQgY29sb3I9IiMwMDAwMDAi
PiZuYnNwOyZuYnNwOyZuYnNwOw0KZHJhc2h0aUBldGgubmV0PC9mb250PjwvZm9udD4NCjxi
cj48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgY29sb3I9IiNDQzMzQ0MiPjxmb250
IHNpemU9LTE+d2UgYWxzbyZuYnNwOw0KYnV5ID4+PC9mb250PjwvZm9udD48L2ZvbnQ+DQo8
YnI+PGZvbnQgZmFjZT0iQXJpYWwgTmFycm93Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGZv
bnQgc2l6ZT0rMT4tIHVzZWQmbmJzcDsmbmJzcDsNCm5ldyZuYnNwOyBsYXB0b3AmbmJzcDsg
cGFsbXRvcCAuIHBkYS0gdGFibGV0IHBjLSBoYW5kIGhlbGQ8L2ZvbnQ+PC9mb250PjwvZm9u
dD4NCjxicj48Zm9udCBmYWNlPSJBcmlhbCBOYXJyb3ciPjxmb250IGNvbG9yPSIjMDAwMDAw
Ij48Zm9udCBzaXplPSsxPmRpZ2l0YWwNCmNhbWVyYSZuYnNwOyBwcm9qZWN0b3IgZXRjLiZu
YnNwOyByZWd1bGFyPC9mb250PjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJp
YWwgQmxhY2siPjxmb250IGNvbG9yPSIjRkY5OTAwIj48Zm9udCBzaXplPSsxPmhlbHAmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsNCnN1Z2dlc3QmbmJzcDsgLS0mbmJzcDsgYWR2aWNlJm5i
c3A7IHlvdXImbmJzcDsgLTwvZm9udD48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9
IkFyaWFsIE5hcnJvdyI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxmb250IHNpemU9KzE+b2Zm
aWNlDQpzdGFmZiAvIGZyaWVuZHMmbmJzcDsmbmJzcDsgLyZuYnNwOyZuYnNwOyByZWxhdGl2
ZXMmbmJzcDsmbmJzcDsgYnkgaW5mb3JtaW5nJm5ic3A7Jm5ic3A7DQp0aGlzJm5ic3A7Jm5i
c3A7IHVzZWZ1bCZuYnNwOyZuYnNwOyAtLSBsYXB0b3AmbmJzcDsgcGFsbXRvcCZuYnNwOyZu
YnNwOw0KaW5mb3JtYXRpb248L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxicj48Yj48Zm9udCBm
YWNlPSJBcmlhbCBOYXJyb3ciPjxmb250IGNvbG9yPSIjRkY2NjY2Ij48Zm9udCBzaXplPSsx
PkVWRU4mbmJzcDsNCllPVSZuYnNwOyBDQU4mbmJzcDsgUFJFU0VSVkUmbmJzcDsgVEhJUyZu
YnNwOyBJTkZPUk1BVElPTi0tJm5ic3A7IFlPVVImbmJzcDsmbmJzcDsNCkZVVFVSRSZuYnNw
OyBORUVEPC9mb250PjwvZm9udD48L2ZvbnQ+PC9iPg0KPGJyPjxmb250IGZhY2U9IkFyaWFs
IEJsYWNrIj48Zm9udCBjb2xvcj0iIzMzRkYzMyI+PGZvbnQgc2l6ZT0rMT5tYWtlJm5ic3A7
DQpmYXN0Jm5ic3A7IC0mbmJzcDsgYWNjdXJhdGUmbmJzcDsmbmJzcDsgLSBtYW5hZ2VtZW50
IC8gUFJPR1JFU1M8L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJBcmlh
bCBOYXJyb3ciPjxmb250IGNvbG9yPSIjMDAwMDAwIj48Zm9udCBzaXplPSsxPmJ5Jm5ic3A7
DQp1c2luZyZuYnNwOyBsYXRlc3QmbmJzcDsgdGVjaG5vbG9neSZuYnNwOyZuYnNwOyAtIGxh
cHRvcC0mbmJzcDsmbmJzcDsmbmJzcDsNCnBhbG10b3AmbmJzcDsgLSBub3cmbmJzcDsgYXZh
aWxhYmxlJm5ic3A7IGF0IGFmZm9yZGFibGUmbmJzcDsgcHJpY2UuPC9mb250PjwvZm9udD48
L2ZvbnQ+DQo8YnI+PGI+PGZvbnQgZmFjZT0iQXJpYWwgTmFycm93Ij48Zm9udCBjb2xvcj0i
IzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5CRUFUJm5ic3A7DQpUSEUmbmJzcDsgQ09NUEVUSVRJ
T04gLyZuYnNwOyBDT01QRVRJVE9SPC9mb250PjwvZm9udD48L2ZvbnQ+PC9iPg0KPGJyPjxm
b250IGZhY2U9IkFyaWFsIEJsYWNrIj48Zm9udCBjb2xvcj0iIzMzQ0NGRiI+PGZvbnQgc2l6
ZT0rMT5zYXZlJm5ic3A7DQptb25leSAtJm5ic3A7IHJlZHVjZSZuYnNwOyZuYnNwOyB0ZW5z
aW9uIC8gaGVhZGFjaGU8L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJB
cmlhbCBOYXJyb3ciPjxmb250IGNvbG9yPSIjMDAwMDAwIj48Zm9udCBzaXplPSsxPmJ1eSZu
YnNwOyZuYnNwOw0KdXNlZCZuYnNwOyZuYnNwOyZuYnNwOyAvJm5ic3A7IHJlY3ljbGVkJm5i
c3A7IC0gaXRlbXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCmF0Jm5ic3A7IGxvdyZuYnNw
OyBhZmZvcmRhYmxlJm5ic3A7IHByaWNlPC9mb250PjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv
bnQgZmFjZT0iQXJpYWwgTmFycm93Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PGZvbnQgc2l6
ZT0rMT5tYWtlJm5ic3A7DQpjaGFuZ2UmbmJzcDsgLSB0aW1lJm5ic3A7IHRvJm5ic3A7IHRp
bWUtJm5ic3A7IGRhaWx5Jm5ic3A7IG5ldyZuYnNwOyAtDQppdGVtcyAvIG1vZGVscyAvIHRl
Y2hub2xvZ3kgYXZhaWxhYmxlJm5ic3A7IGluIHRoZSBtYXJrZXQmbmJzcDsgYXQmbmJzcDsN
CmxvdyZuYnNwOyBwcmljZTwvZm9udD48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9
IkFyaWFsIEJsYWNrIj48Zm9udCBjb2xvcj0iI0ZGQ0MwMCI+PGZvbnQgc2l6ZT0rMT5yZWFs
Jm5ic3A7DQpoYXJkJm5ic3A7IGZhY3Q8L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBmYWNlPSJBcmlhbCBOYXJyb3ciPjxmb250IGNvbG9yPSIjMDAwMDAwIj48Zm9udCBzaXpl
PSsxPmRhaWx5Jm5ic3A7DQpwcmljZSZuYnNwOyBvZiZuYnNwOyBsYXB0b3AgY29tcHV0ZXJz
Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSZuYnNwOyBjb21pbmcmbmJzcDsNCmRvd248L2ZvbnQ+
PC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgY29s
b3I9IiNDQzY2Q0MiPjxmb250IHNpemU9KzE+aXRzJm5ic3A7DQpsaWtlLTwvZm9udD48L2Zv
bnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9IkFyaWFsIE5hcnJvdyI+PGZvbnQgY29sb3I9
IiMwMDAwMDAiPjxmb250IHNpemU9KzE+Y2hhbmdpbmcmbmJzcDsmbmJzcDsNCm1vYmlsZSZu
YnNwOyBwaG9uZSZuYnNwOyBtb2RlbHMgLSB2ZXJ5IHNpeCBtb250aHMgLSB1c2UmbmJzcDsm
bmJzcDsgbmV3Jm5ic3A7DQptb2RlbHM8L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgY29sb3I9IiNDQzY2Q0MiPjxmb250IHNpemU9
KzE+aXRzIGxpa2U8L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJBcmlh
bCBOYXJyb3ciPjxmb250IGNvbG9yPSIjMDAwMDAwIj48Zm9udCBzaXplPSsxPmJ1eWluZyZu
YnNwOyZuYnNwOw0Kb25lIHllYXImbmJzcDsgIiZuYnNwOyB1c2VkJm5ic3A7IHplbiZuYnNw
OyBjYXIiJm5ic3A7IC0mbmJzcDsgZnJvbSZuYnNwOw0KYSAiIHBlcnNvbi4iJm5ic3A7ICgg
d2hvIGlzIGdvaW5nJm5ic3A7IGZvciZuYnNwOyZuYnNwOyAiZm9yZCAiIC8gTWVyY2VkZXMN
CiIgKTwvZm9udD48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+PGZvbnQgZmFj
ZT0iQXJpYWwgQmxhY2siPjxmb250IGNvbG9yPSIjMDBDQzAwIj5pdHMmbmJzcDsNCm5vdCBt
ZWFuJm5ic3A7IHRoYXQgPjwvZm9udD48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwgTmFycm93
Ij48Zm9udCBjb2xvcj0iIzAwMDAwMCI+Jm5ic3A7DQp6ZW4mbmJzcDsgY2FyJm5ic3A7IGlz
Jm5ic3A7IGRlZmVjdGl2ZSZuYnNwOyBvciZuYnNwOyBiYWQ8L2ZvbnQ+PC9mb250PjwvZm9u
dD4NCjxicj48Yj48Zm9udCBmYWNlPSJBcmlhbCBOYXJyb3ciPjxmb250IGNvbG9yPSIjRkY2
NjAwIj48Zm9udCBzaXplPSsxPmp1c3RpZnkmbmJzcDsNCj4mbmJzcDsmbmJzcDsgeW91ciZu
YnNwOyB1c2UgLSBidWRnZXQ8L2ZvbnQ+PC9mb250PjwvZm9udD48L2I+DQo8YnI+PGZvbnQg
c2l6ZT0rMT48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgY29sb3I9IiNGRkNDMzMi
PmV2ZW4gYWZ0ZXImbmJzcDsNCnVzaW5nJm5ic3A7PC9mb250PjwvZm9udD48Zm9udCBmYWNl
PSJBcmlhbCBOYXJyb3ciPjxmb250IGNvbG9yPSIjMDAwMDAwIj4mbmJzcDsmbmJzcDsNCnNp
eCZuYnNwOyBtb250aHMgLyBvbmUmbmJzcDsmbmJzcDsgeWVhciZuYnNwOyB5b3UgY2FuIGFs
c28mbmJzcDsgY2hhbmdlDQp0aGUmbmJzcDsmbmJzcDsgbW9kZWwmbmJzcDsgb2YmbmJzcDsg
bGFwdG9wIC8gcGFsbXRvcDwvZm9udD48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9
KzE+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siPjxmb250IGNvbG9yPSIjMzNGRjMzIj5idXkg
YXQ8L2ZvbnQ+PC9mb250Pjxmb250IGZhY2U9IkFyaWFsIE5hcnJvdyI+PGZvbnQgY29sb3I9
IiMwMDAwMDAiPiZuYnNwOyZuYnNwOw0KbG93Jm5ic3A7IHByaWNlIC0mbmJzcDs8L2ZvbnQ+
PC9mb250Pjxmb250IGZhY2U9IkFyaWFsIEJsYWNrIj48Zm9udCBjb2xvcj0iI0ZGOTkwMCI+
DQomYW1wOzwvZm9udD48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwgTmFycm93Ij48Zm9udCBj
b2xvcj0iIzAwMDAwMCI+IGF0Jm5ic3A7DQp0aGUmbmJzcDsgdGltZSZuYnNwOyBvZiZuYnNw
OyBzZWxsaW5nLSA+PC9mb250PjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJp
YWwgTmFycm93Ij48Zm9udCBzaXplPSsxPjxmb250IGNvbG9yPSIjMDAwMDAwIj5yZWR1Y2Um
bmJzcDsNCnlvdXImbmJzcDsmbmJzcDsgbG9zcyA+Jm5ic3A7IGNvdmVyJm5ic3A7IGFsbW9z
dCZuYnNwOyBzYW1lJm5ic3A7IHByaWNlJm5ic3A7DQpldmVuIGFmdGVyIHVzaW5nJm5ic3A7
IHRoZSA8L2ZvbnQ+PGZvbnQgY29sb3I9IiMzMzY2RkYiPiIgdXNlZCBsYXB0b3AgLw0KcGFs
bXRvcCZuYnNwOyAiPC9mb250PjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJp
YWwgTmFycm93Ij48Zm9udCBjb2xvcj0iI0ZGNjYwMCI+PGZvbnQgc2l6ZT0rMT4iJm5ic3A7
DQp3aGVyZSZuYnNwOyZuYnNwOyBuZWVkbGUmbmJzcDsmbmJzcDsgY2FuIGRvIHRoZSZuYnNw
OyB3b3JrJm5ic3A7ID4mbmJzcDsNCnRoZW4mbmJzcDsmbmJzcDsgdGhlcmUmbmJzcDsgaXMm
bmJzcDsgbm8gbmVlZCZuYnNwOyB0byZuYnNwOyBidXkgc3dvcmQNCiI8L2ZvbnQ+PC9mb250
PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJBcmlhbCBOYXJyb3ciPjxmb250IGNvbG9yPSIj
RkY2NjAwIj48Zm9udCBzaXplPSsxPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS48L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxicj48Zm9udCBmYWNlPSJBcmlhbCBO
YXJyb3ciPjxmb250IGNvbG9yPSIjMDAwMDAwIj48Zm9udCBzaXplPSsxPmlmIHlvdSZuYnNw
Ow0KaGF2ZSZuYnNwOyB3b3JrJm5ic3A7Jm5ic3A7IG9mJm5ic3A7Jm5ic3A7Jm5ic3A7IGxh
cHRvcC0gZm9yPC9mb250PjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwg
TmFycm93Ij48Zm9udCBjb2xvcj0iIzAwOTkwMCI+PGZvbnQgc2l6ZT0rMT5zdGFmZg0KLyZu
YnNwOyZuYnNwOyBtYXJrZXRpbmcmbmJzcDsgLyBkYXRhIC8mbmJzcDsgZ3JhcGhpY3MgLyBw
cmVzZW50YXRpb25zJm5ic3A7DQovJm5ic3A7IGRldmVsb3BtZW50PC9mb250PjwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwgTmFycm93Ij48Zm9udCBjb2xvcj0iIzAw
OTkwMCI+PGZvbnQgc2l6ZT0rMT5mYXggLw0KZW1haWwgLyZuYnNwOyZuYnNwOyBpbnRlcm5l
dCZuYnNwOyAvIGRhdGEmbmJzcDsgc2VjcmVjeSZuYnNwOyAvIGFjY291bnRpbmcmbmJzcDsN
Ci8mbmJzcDsgbWFuYWdlbWVudCZuYnNwOyZuYnNwOyAvIGluZm9ybWF0aW9uJm5ic3A7Jm5i
c3A7IGF2YWlsYWJpbGl0eTwvZm9udD48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGZhY2U9
IkFyaWFsIE5hcnJvdyI+PGZvbnQgY29sb3I9IiMwMDk5MDAiPjxmb250IHNpemU9KzE+YXV0
bw0KY2FkJm5ic3A7Jm5ic3A7IC8gd2ViIGRldmVsb3BtZW50IC8gdmIuIHNvZnR3YXJlJm5i
c3A7IC8gbWFjaGluZSZuYnNwOw0KdGVzdGluZyBhdXRvbWF0aW9uJm5ic3A7Jm5ic3A7IC8g
Y29udGFjdCZuYnNwOyBtYW5hZ2VtZW50IC88L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxicj48
Zm9udCBmYWNlPSJBcmlhbCBOYXJyb3ciPjxmb250IGNvbG9yPSIjMDA5OTAwIj48Zm9udCBz
aXplPSsxPmxldHRlcg0Kd3JpdGluZyAvIGVudGVydGFpbm1lbnQgLyBzb25ncyAvIG1vdmll
Jm5ic3A7IC8mbmJzcDsmbmJzcDsgdmlnaWxhbmNlIC8NCnF1YWxpdHkgY29udHJvbCZuYnNw
OyZuYnNwOyBtYW5hZ2VtZW50Jm5ic3A7IC88L2ZvbnQ+PC9mb250PjwvZm9udD4NCjxwPjxm
b250IGZhY2U9IkFyaWFsIE5hcnJvdyI+PGZvbnQgY29sb3I9IiMwMDk5MDAiPjxmb250IHNp
emU9KzE+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLjwvZm9udD48L2Zv
bnQ+PC9mb250PjwvY2VudGVyPg0KDQo8cD48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L2Jv
ZHk+DQo8L2h0bWw+DQogICAg

Re: [Phpwiki-talk] PHPWiki and existing databases

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

Yes, it would work.  Your app would just have to include the appropriate=20
.php files and use the classes and functions.  Though if you have to=20
include lib/main.php you'll run into it wanting to run PHPWiki.  It is=20
planned to move the main() call to index.php (once we get all of the=20
local configuration out of index.php).

jbw

Mazloumi wrote:
> Dear PHPWiki-Team,
>=20
> =20
>=20
> i was wondering wether you see a chance to use PHPWiki on the backend o=
f=20
> an existing application that is developed with PHP/mysql. I want to=20
> allow the program to have the responsibility to create and to delete th=
e=20
> content but to use PHPWiki als the version control interface for=20
> modifications and for retrieving a requested version. Do you think it i=
s=20
> possible to integrate PHPWiki for such a purpose? Like any request to=20
> retrieve/edit an existing content from the database is dipatched to PHP=
Wiki.
>=20
> =20
>=20
> Thank you very much for any idea.
>=20
> =20
>=20
> Best wishes,
>=20
> nima
>=20
> =20
>=20
> ___________________________________________________
> *Dipl.-Kfm. Nima Mazloumi*                              =20
>=20
> Universit=E4t Mannheim
> Lehrstuhl f=FCr ABWL und Industrie, insbesondere Produktionswirtschaft =
und=20
> Controlling - Prof. Dr. Hoitsch
> Lehrstuhl f=FCr Wirtschaftsinformatik III - Prof. Dr. Schader
>=20
> L13,15
> Raum 421
> 68131 Mannheim
> Tel. +49 (0)621-181-3460 (office)
> Fax. +49 (0)621-181-1643
> Handy: +49-(0)-177-5757277
> Email: maz...@wi...=20
> <mailto:maz...@wi...>
> ___________________________________________________
>=20
> =20
>=20

[Phpwiki-talk] PHPWiki and existing databases

[Mazloumi <maz...@de...>]

Dear PHPWiki-Team,
=20
i was wondering wether you see a chance to use PHPWiki on the backend of
an existing application that is developed with PHP/mysql. I want to
allow the program to have the responsibility to create and to delete the
content but to use PHPWiki als the version control interface for
modifications and for retrieving a requested version. Do you think it is
possible to integrate PHPWiki for such a purpose? Like any request to
retrieve/edit an existing content from the database is dipatched to
PHPWiki.
=20
Thank you very much for any idea.
=20
Best wishes,
nima
=20
___________________________________________________=20
Dipl.-Kfm. Nima Mazloumi                               =20
Universit=E4t Mannheim
Lehrstuhl f=FCr ABWL und Industrie, insbesondere Produktionswirtschaft =
und
Controlling - Prof. Dr. Hoitsch
Lehrstuhl f=FCr Wirtschaftsinformatik III - Prof. Dr. Schader
L13,15
Raum 421
68131 Mannheim=20
Tel. +49 (0)621-181-3460 (office)
Fax. +49 (0)621-181-1643
Handy: +49-(0)-177-5757277
Email: maz...@wi...
___________________________________________________=20
=20

[Phpwiki-talk] auto /Calendar, /Preferences, CreateHomePageCB (was Re: do subpages work?)

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

Hi Chip, (and All),

These don't work for me either, I think they were supposed to be 
automatically created. Otherwise subpages work great.

It would be nice to get the automatic Calendar subpage working, and 
IMHO it should only be created when someone visits that page.

I don't see the need for each user to have their own preferences page 
anymore, the preferences are actually now stored in the database in the 
user's page. People can just use the common UserPreferences page to 
change their settings.

Having said the above, I also think we should eliminate the "Create 
HomePage" checkbox (which also doesn't work yet) upon Sign In. If 
someone decides to "stay" at a wiki they can create their own home 
page, it's fun and an opportunity to practice WikiMarkup for new users, 
quick to do for experienced Wikizens.

Carsten

On Wednesday, January 15, 2003, at 04:49  pm, Chip Rosenthal wrote:

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

RE: [Phpwiki-talk] Fonts Query and Slow WIKI

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

Thanks for this, the code below has resolved the problem.
 
Sandy
 
-----Original Message-----
From: Jochen Kalmbach [mailto:Jo...@Ka...] 
Sent: 16 January 2003 18:36
To: Sandy Matheson
Subject: Re: [Phpwiki-talk] Fonts Query and Slow WIKI
 
Hello again,
 
sorry that I attached the whole file.
The only changes you have to do is (in 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] Fonts Query and Slow WIKI

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

Hello Sandy,

the problem is an bug in config.php...
Attachted is the corrected version.

The probem is that if the wiki is installed in the root-dir of the server,
then the CSS-Link is wrong... so the Web-Browser tries to load this CSS-file
but cannot find the server. The browser takes an very long time 2-5 sec. to
discover that the server for the CSS-files does not exist.

Greetings
  Jochen
  ----- Original Message -----
  From: Sandy Matheson
  To: Php...@li...
  Sent: Thursday, January 16, 2003 6:33 PM
  Subject: [Phpwiki-talk] Fonts Query and Slow WIKI


  I have recently set up a new WIKI based on my customised version of PHPiki
1.3.3 and come up with a very odd problem. On the original test site the
font used by the WIKI is Arial, however on the new site it uses Times New
Roman. I have checked everything that I can think of and no difference.



  I have even deleted both, emptied the MySQL databases, and then
re-installed exactly the same code and the problem is still there!



  The other problem is that the new site loads very slowly, despite the fact
that they are based on the same virtual server and have tables on the same
MySQL database using differing prefixes????



  The two sites are:



  Original test site: http://www.diocese.dsvr.co.uk/wiki2/index.php



  New site: http://www.newportparish.org.uk/index.php



  Any ideas gratefully accepted, I am slowly tearing out my hair!



  Sandy Matheson

[Phpwiki-talk] Fonts Query and Slow WIKI

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

I have recently set up a new WIKI based on my customised version of
PHPiki 1.3.3 and come up with a very odd problem. On the original test
site the font used by the WIKI is Arial, however on the new site it uses
Times New Roman. I have checked everything that I can think of and no
difference.
 
I have even deleted both, emptied the MySQL databases, and then
re-installed exactly the same code and the problem is still there!
 
The other problem is that the new site loads very slowly, despite the
fact that they are based on the same virtual server and have tables on
the same MySQL database using differing prefixes????
 
The two sites are:
 
Original test site: http://www.diocese.dsvr.co.uk/wiki2/index.php
 
New site: http://www.newportparish.org.uk/index.php
 
Any ideas gratefully accepted, I am slowly tearing out my hair!
 
Sandy Matheson

[Phpwiki-talk] (Á¤º¸) Àü¿ë¼± »ç¿ë°ü·Ã Á¦¾ÈÀÔ´Ï´Ù. ²À °ËÅäÇØ ÁÖ¼¼¿ä.

[iton <jc...@it...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>☎ 메일송신자정보입니다.</title>
<meta name="GENERATOR" content="Namo WebEditor v4.0">
</head>
<body>
<p align="center"><IMG height=850 src="http://www.iton.co.kr/img/krline.PNG" width=726 border=0>&nbsp;</p>
<P align=center><font size="2" face="돋움">☎ 메일 송신자정보입니다.<BR>사명:아이티온(Kr-Line Sales Pro), 관련문의:전창범 팀장, 
TEL:973-5178(代), FAX:975-5182<BR>위치:중랑구 묵동 187-10(2층), 송신자 메일: </font><U><FONT 
color=#0000ff size="2" face="돋움"><A href="mailto:jc...@it...">jc...@it...</A></FONT></U><font size="2" face="돋움">, 
홈피:<A href="http://www.iton.co.kr">www.iton.co.kr</font></A></P>
<P align=center><font size="2" face="돋움">☞본 메일은 정보통신부 권고사항에 의거 제목에 "(광고)"라고 표시된 광고메일입니다.<BR>수신을 원치않으시면 
수신거부를 클릭하시면 수신 거부처리가 이루어집니다.<BR>( If you don't want this type of information or 
e-mail, please click the 'refuse)<BR><center><a href='http://itnsoft.com/~mailtouch/user/touch.cgi?cmd=refuse_view&usercode=figjdqjm-iiolml-Ddigi&group=50&name=&mail=php...@li...'><img src='http://itnsoft.com/~mailtouch/user/mail-refuse.gif' border=0)></center></font></P></body>
</html>