phpwiki-talk Mailing List for PhpWiki (Page 239)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi Lawrence,

On which pages do you see this error?

Also don't forget to rename the plugins in any page markup:

<?plugin walkabout

to

<?plugin PageGroup

Carsten

I haven't been able to access the newwikimarkup wiki for a few days 
now.  Investigations reveal the following in the xhtml source:

<div class="error"><p>lib/WikiPlugin.php:260: Warning[2]: Failed opening 
'lib/plugin/walkabout.php' for inclusion 
(include_path='.:/usr/local/lib/php')</p>
</div>

Something to do with the renaming of Carsten's plugin?

Lawrence

==========NOTICE==========
Internet e-mail is not necessarily secure or reliable.  Please let us know if you would like to establish a secure channel of communication.
This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.
Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.
Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...

> Now I'm confused.  Which way _do_ y'all think is better?

I would prefer that when I hit the back button it goes back to the
version of the page which has my potentially unsaved pages in it.

If I don't want my changes and want to start over I can hit the edit
button instead.  I think this provides more options then the other way
around.

Adam.

On Sat, 2 Feb 2002 15:41:55 -0500 (EST)
"Steve Wainstead" <sw...@pa...> wrote:

> On Sat, 2 Feb 2002, Malcolm Ross Kinsella Ryan wrote:
> 
> > Couldn't the refresh setting on the Edit page be set to zero so that
the> > cached copy is ignored and page is always reloaded when the user
presses> > "Back"? Then going back to an Edit page would be equivalent to
pressing> > "Edit" again, wouldn't it?

Up until a couple of days ago, this is (inadvertently) how 1.3.x behaved.
(When you turn on PHP's session support, it turns out, by default it sends
all kinds of "please don't cache me" HTTP headers which don't get sent
when one doesn't enable sessions.)

I thought this was what you (Malcolm) were initially complaining about.
I certainly prefer (and think safer) the older behavior: that when you
back up to a previous edit form, your (unsaved) changes don't get wiped.  

So a couple of days ago, after Malcolm brought up the subject, I figured
out what was going on and "fixed" it.  The latest CVS code should act like
the old (pre-1.3) PhpWiki: you can back up to a stale edit form without
losing any edits you may have made.

Now I'm confused.  Which way _do_ y'all think is better?

On Sat, 2 Feb 2002, Malcolm Ross Kinsella Ryan wrote:

> Couldn't the refresh setting on the Edit page be set to zero so that the
> cached copy is ignored and page is always reloaded when the user presses
> "Back"? Then going back to an Edit page would be equivalent to pressing
> "Edit" again, wouldn't it?

Yes, this could work. Good idea!

~swain

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

Very cool, Lawrence!

~swain

On Sat, 2 Feb 2002, Lawrence Akka wrote:

> I have checked into cvs a first cut of an ADODB backend.  I've only
> tested this on MySql.  I still have some work to do on error handling
> etc, but it seems to work fine for me.  If you want to try it out, use
> 'dbtype' => 'ADODB' in index.php
>
> Please let me have any comments.  If you can do any benchmarks,
> that would be great.  My impression is that it is faster than PEAR, but
> that's rather unscientific.  In any event, the code needs some tightening
> anyway, so it is likely to prove faster still.
>
> It doesn't suffer from the backslash bug!
>
> Lawrence--------------------------------------------------------
> Confidentiality Notice
>
> The information contained in this e-mail is confidential.  It is for the
> use of the named recipient only.  If you are not the named recipient,
> please destroy and do not disclose the contents of this e-mail
> to any other person, or copy it.  Thank you for your co-operation.
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

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

> I wondered where you'd got to!
=20
:) Hehe, under tons of work

> I haven't yet implemented the CacheExecute facility of=20
ADODB - I will
> probably have a go at it this weekend.
> There are still a few other performance enhancements I could make. =20
> What I have done so far is really a proof of concept only.

Ok, cool, let me know if you have any trouble, for sure I'll help you.

Saludos,

Pablo Roca MS - VFP MVP
La Coru=F1a - Espa=F1a

Hi Bernd,

The user signin is still very basic. For the time being, only the 
administrator has a password. For other users this just allows one to give 
a name which shows in RecentChanges instead of the ip address.

Carsten

On Saturday, February 2, 2002, at 11:13  am, Bernd Duesmann wrote:

> hi,
>
> i am new to wiki. when i set 'REQUIRE_SIGNIN_BEFORE_EDIT' to true. users 
> must fill in username and pass before they can edit. now my question: is 
> it possible for new users to register somewhere? or how get a new user a 
> log and pass? thanks for your help.
>
> regards
> bernd

hi,

i am new to wiki. when i set 'REQUIRE_SIGNIN_BEFORE_EDIT' to true. users 
must fill in username and pass before they can edit. now my question: is 
it possible for new users to register somewhere? or how get a new user a 
log and pass? thanks for your help.

regards
bernd

                           bernd duesmann | http://www.uploaders.de
                           01 77 . 2 82 17 30

hi,

i have my wikiapp now up and running under 
http://www.uploaders.de/uploaderswiki/
but now, when i try to login i get an server error 500. i have found 
some entries in the forum on this topic but no solution. anyone have an 
idea? also when i klick on diff in rescent changes it dosent show the 
differences to the previous document. it simply goes to the startpage.

thanx for your help
regards bernd

                           bernd duesmann | http://www.uploaders.de
                           01 77 . 2 82 17 30

Hi Pablo,

I wondered where you'd got to!

I haven't yet implemented the CacheExecute facility of ADODB - I will 
probably have a go at it this weekend.

There are still a few other performance enhancements I could make.  
What I have done so far is really a proof of concept only.

Lawrence

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>  AODB was up to twice as fast, and subsequent reloads of 
> AllPages seemed 
> quicker. (Is that possible--does it have better cacheing or 
> something?) 
> Mac OS X 10.1.2, mysql-3.23.44, php 4.1, Apache/1.3.22.

> We're talking about less than a quarter of one second of improvment 
> loading AllPages on my system, but it does seem (barely) 
> noticeably faster.
>   I wonder what the speed difference would be like on the SourceForge 
> phpwiki.

Carsten,

In some tests I done ADODB is three times faster than PEAR. I can 
send
this test to any who like.

And yes ADODB can have a cache system, but I guess that Lawrence 
didn't
throw this yet to the CVS, so expect more improvement when this 
cache
system is committed. Am I right Lawerence? Didi you put yet the 
ADODB
cache?

Anyway, ADODB is technically better done than PEAR, and supports 
more
databases.

Right decision Lawrence! Congrats!

Saludos,

Pablo Roca MS - VFP MVP
La Coru=F1a - Espa=F1a

_______________________________________________
Phpwiki-talk mailing list
<EMAIL: PROTECTED>
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

--------------------------------------------------------
Confidentiality Notice

The information contained in this e-mail is confidential.  It is for the
use of the named recipient only.  If you are not the named recipient, 
please destroy and do not disclose the contents of this e-mail
to any other person, or copy it.  Thank you for your co-operation.

I set up the adodb on the alpha server now, for anyone who wants to run 
the speed test there.

ADODB:  http://phpwiki.sourceforge.net/alpha/adodb/AllPages
PEAR:   http://phpwiki.sourceforge.net/alpha/en/AllPages

(Also I noticed that TitleSearchs for adodb aren't working yet, no doubt 
it's in the works somewhere.)

Carsten

> AODB was up to twice as fast, and subsequent reloads of=20
> AllPages seemed=20
> quicker. (Is that possible--does it have better cacheing or=20
> something?)=20
> Mac OS X 10.1.2, mysql-3.23.44, php 4.1, Apache/1.3.22.

> We're talking about less than a quarter of one second of improvment=20
> loading AllPages on my system, but it does seem (barely)=20
> noticeably faster.
>   I wonder what the speed difference would be like on the SourceForge=20
> phpwiki.

Carsten,

In some tests I done ADODB is three times faster than PEAR. I can send
this test to any who like.

And yes ADODB can have a cache system, but I guess that Lawrence didn't
throw this yet to the CVS, so expect more improvement when this cache
system is committed. Am I right Lawerence? Didi you put yet the ADODB
cache?

Anyway, ADODB is technically better done than PEAR, and supports more
databases.

Right decision Lawrence! Congrats!

Saludos,

Pablo Roca MS - VFP MVP
La Coru=F1a - Espa=F1a

Lawrence,

I tested the ADODB by adding a debug argument to the AllPages plugin, 
which tells you how long it took to generate the list.

AODB was up to twice as fast, and subsequent reloads of AllPages seemed 
quicker. (Is that possible--does it have better cacheing or something?) 
Mac OS X 10.1.2, mysql-3.23.44, php 4.1, Apache/1.3.22.

We're talking about less than a quarter of one second of improvment 
loading AllPages on my system, but it does seem (barely) noticeably faster.
  I wonder what the speed difference would be like on the SourceForge 
phpwiki.

Carsten

On Friday, February 1, 2002, at 07:00  pm, Lawrence Akka wrote:

> Please let me have any comments.  If you can do any benchmarks,
> that would be great.  My impression is that it is faster than PEAR, but
> that's rather unscientific.  In any event, the code needs some tightening
> anyway, so it is likely to prove faster still.
>
> It doesn't suffer from the backslash bug!
>
> Lawrence--------------------------------------------------------

On Sat, Feb 02, 2002 at 11:38:00AM +1100, Malcolm Ross Kinsella Ryan wrote:
> 
> Okay. You've lost me now. I'm not that familiar with the code to understand
> this, this question might be totally naive, but here goes:
> 
> Couldn't the refresh setting on the Edit page be set to zero so that the 
> cached copy is ignored and page is always reloaded when the user presses 
> "Back"? Then going back to an Edit page would be equivalent to pressing 
> "Edit" again, wouldn't it? 

Actually, now that I come to test it, I find that on 1.3.2 wikis I _can_
use the Back button. At least with my current browser (Netscape 6.2 on
Win98). It appears to always reload wiki pages. It must have something to
do with the cache configuration. 

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/
  AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-4936

           "He causes his sun to rise on the evil and the good,
           and sends rain on the righteous and the unrighteous." - Matt 5:45

On Sat, Feb 02, 2002 at 11:38:00AM +1100, Malcolm Ross Kinsella Ryan wrote:
> 
> Couldn't the refresh setting on the Edit page be set to zero so that the 
> cached copy is ignored and page is always reloaded when the user presses 
> "Back"? Then going back to an Edit page would be equivalent to pressing 
> "Edit" again, wouldn't it? 

To make it clear, I mean adding the header:

<meta http-equiv="Expires" content="0">

To the edit pages.

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/
  AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-4936

           "He causes his sun to rise on the evil and the good,
           and sends rain on the righteous and the unrighteous." - Matt 5:45

On Fri, Feb 01, 2002 at 02:04:38AM -0500, Steve Wainstead wrote:
> 
> On Fri, 1 Feb 2002, Malcolm Ross Kinsella Ryan wrote:
> 
> > Even after a fair while using wikis, I still find it frustrating that
> > using the back button on my browser does not allow me to go back to an edit
> > page. What is the problem here? Can't we find a way around it?
> 
> This can probably be disabled easily (just kill the test of the version
> numbers) but then you subject yourself to the Lost Update Problem. The
> solution is locking, and WebDAV is the standard to handle this.

Okay. You've lost me now. I'm not that familiar with the code to understand
this, this question might be totally naive, but here goes:

Couldn't the refresh setting on the Edit page be set to zero so that the 
cached copy is ignored and page is always reloaded when the user presses 
"Back"? Then going back to an Edit page would be equivalent to pressing 
"Edit" again, wouldn't it? 

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/
  AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-4936

           "He causes his sun to rise on the evil and the good,
           and sends rain on the righteous and the unrighteous." - Matt 5:45

On Fri, Feb 01, 2002 at 07:52:08AM +0000, John Kershaw wrote:
> At 2:30 pm +1100 1/2/02, Malcolm Ross Kinsella Ryan wrote:
> >Even after a fair while using wikis, I still find it frustrating that
> >using the back button on my browser does not allow me to go back to an edit
> >page. What is the problem here? Can't we find a way around it?
> 
> How does pressing 'Back' differ from pressing 'EditText'? Apart from 
> seeing the preview, which you could add back in if you like?

Well, for one, the 'Back' button is in the same place for every web page.
I am used to using it, without thinking.

But that's beside the point. The question is not "Why can't users use
the controls we provide?" but "How can we provide controls that the 
users can use?"

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/
  AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-4936

           "He causes his sun to rise on the evil and the good,
           and sends rain on the righteous and the unrighteous." - Matt 5:45

I have checked into cvs a first cut of an ADODB backend.  I've only 
tested this on MySql.  I still have some work to do on error handling 
etc, but it seems to work fine for me.  If you want to try it out, use 
'dbtype' => 'ADODB' in index.php

Please let me have any comments.  If you can do any benchmarks, 
that would be great.  My impression is that it is faster than PEAR, but 
that's rather unscientific.  In any event, the code needs some tightening 
anyway, so it is likely to prove faster still.

It doesn't suffer from the backslash bug!

Lawrence--------------------------------------------------------
Confidentiality Notice

The information contained in this e-mail is confidential.  It is for the
use of the named recipient only.  If you are not the named recipient, 
please destroy and do not disclose the contents of this e-mail
to any other person, or copy it.  Thank you for your co-operation.

hi,

after installation the links will be displayed as follows:

http://www.mypage.com/pathto/index.php/pathto%2Findex.php?action=edit

but it should display as followd:

http://www.mypage.com/pathto/index.php?action=edit

what has gone wrong? i have installed phpwiki with mysql as database. 
version of phpwiki is 1.3.2
thanx for your help

regards
bernd

                           bernd duesmann | http://www.uploaders.de
                           01 77 . 2 82 17 30

In message <a05101012b87ff802b66b@[80.0.5.9]>
          John Kershaw <jo...@ke...> wrote:

 > At 2:30 pm +1100 1/2/02, Malcolm Ross Kinsella Ryan wrote:
 > >Even after a fair while using wikis, I still find it frustrating that
 > >using the back button on my browser does not allow me to go back to an edit
 > >page. What is the problem here? Can't we find a way around it?
 > 
 > How does pressing 'Back' differ from pressing 'EditText'? Apart from 
 > seeing the preview, which you could add back in if you like?

"Back" pops an entry off the history stack, anything else adds another
entry on to the stack. The extra clutter makes it harder for those who
like using the ordering in the stack as part of their navigation.

        Anthony

Hi!
I am very interested in the PHP-Wiki project.
My degree dissertation will be about the integration of PHP-
Wiki in PHP-Project (as a component of PHP-Project, look at
http://www.phprojekt.com). It would be very helpful for me
if I could find a contact person from the developers of PHP-
Wiki in order to answer several questions.
 It would be very nice if you could help me. Please write me
 if you agree with that.

First of all I need a description like an ERM of the data modell.

Thanks in advance,
Thomas

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

At 2:30 pm +1100 1/2/02, Malcolm Ross Kinsella Ryan wrote:
>Even after a fair while using wikis, I still find it frustrating that
>using the back button on my browser does not allow me to go back to an edit
>page. What is the problem here? Can't we find a way around it?

How does pressing 'Back' differ from pressing 'EditText'? Apart from 
seeing the preview, which you could add back in if you like?

John.

PS And a big newbie 'Hello' to the list from Leeds, England.
-- 

---------------------------------------------------------
email:  jo...@ke...         phone:      07944 755613
web:     www.kershaw.org    AOL: johnkershaw
---------------------------------------------------------

On Fri, 1 Feb 2002, Malcolm Ross Kinsella Ryan wrote:

> Even after a fair while using wikis, I still find it frustrating that
> using the back button on my browser does not allow me to go back to an edit
> page. What is the problem here? Can't we find a way around it?

This can probably be disabled easily (just kill the test of the version
numbers) but then you subject yourself to the Lost Update Problem. The
solution is locking, and WebDAV is the standard to handle this. WebDAV is
now included in GNOME, OSX, Windows and many other places, and Apache
supports it with mod_webdav (or thereabouts). WebDAV extends the HTTP
protocol with a host of new methods like LOCK, UNLOCK, DELETE, COPY,
MOVE...

There is no native PHP support for Webdav yet, as far as I know. There is
an implementation out there though. But this may not solve your wish to
"go back and edit again" come to think of it.

~swain

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

The page-preview mode available from the edit window is good, but something
needs to be put at the top of the page to make it clear that the edit window
is at the bottom of the page. I just made a change to NewInlineMarkup which
is a very long page. I previewed my changes, but didn't realise that the
edit window was available at the bottom. I bit of going back and forth
was required before I could work out how to save my changes.

Even after a fair while using wikis, I still find it frustrating that 
using the back button on my browser does not allow me to go back to an edit
page. What is the problem here? Can't we find a way around it?

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/
  AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-4936

           "He causes his sun to rise on the evil and the good,
           and sends rain on the righteous and the unrighteous." - Matt 5:45

2000	Jan	Feb	Mar	Apr	May (1)	Jun (103)	Jul (105)	Aug (16)	Sep (16)	Oct (78)	Nov (36)	Dec (58)
2001	Jan (100)	Feb (155)	Mar (84)	Apr (33)	May (22)	Jun (77)	Jul (36)	Aug (37)	Sep (183)	Oct (74)	Nov (235)	Dec (165)
2002	Jan (187)	Feb (183)	Mar (52)	Apr (10)	May (15)	Jun (19)	Jul (43)	Aug (90)	Sep (144)	Oct (144)	Nov (171)	Dec (78)
2003	Jan (113)	Feb (99)	Mar (80)	Apr (44)	May (35)	Jun (32)	Jul (34)	Aug (34)	Sep (30)	Oct (57)	Nov (97)	Dec (139)
2004	Jan (132)	Feb (223)	Mar (300)	Apr (221)	May (171)	Jun (286)	Jul (188)	Aug (107)	Sep (97)	Oct (106)	Nov (139)	Dec (125)
2005	Jan (200)	Feb (116)	Mar (68)	Apr (158)	May (70)	Jun (80)	Jul (55)	Aug (52)	Sep (92)	Oct (141)	Nov (86)	Dec (41)
2006	Jan (35)	Feb (62)	Mar (59)	Apr (52)	May (51)	Jun (61)	Jul (30)	Aug (36)	Sep (12)	Oct (4)	Nov (22)	Dec (34)
2007	Jan (49)	Feb (19)	Mar (37)	Apr (16)	May (9)	Jun (38)	Jul (17)	Aug (31)	Sep (16)	Oct (34)	Nov (4)	Dec (8)
2008	Jan (8)	Feb (16)	Mar (14)	Apr (6)	May (4)	Jun (5)	Jul (9)	Aug (36)	Sep (6)	Oct (3)	Nov (3)	Dec (3)
2009	Jan (14)	Feb (2)	Mar (7)	Apr (16)	May (2)	Jun (10)	Jul (1)	Aug (10)	Sep (11)	Oct (4)	Nov (2)	Dec
2010	Jan (1)	Feb	Mar (13)	Apr (11)	May (18)	Jun (44)	Jul (7)	Aug (2)	Sep (14)	Oct	Nov (6)	Dec
2011	Jan (2)	Feb (6)	Mar (3)	Apr (2)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2012	Jan (11)	Feb (3)	Mar (11)	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov (4)	Dec
2013	Jan	Feb	Mar	Apr (3)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2014	Jan	Feb	Mar	Apr	May (4)	Jun	Jul	Aug	Sep	Oct	Nov (8)	Dec (1)
2015	Jan (3)	Feb (2)	Mar	Apr (3)	May (1)	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec (2)
2016	Jan	Feb (4)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul (3)	Aug	Sep	Oct	Nov	Dec
2018	Jan	Feb	Mar	Apr	May (3)	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan	Feb	Mar	Apr	May (3)	Jun	Jul (5)	Aug	Sep	Oct	Nov	Dec
2021	Jan	Feb (4)	Mar	Apr	May	Jun	Jul (1)	Aug (6)	Sep (3)	Oct	Nov	Dec
2022	Jan (11)	Feb (2)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2023	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov (3)	Dec (3)
2024	Jan (7)	Feb (2)	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2025	Jan	Feb	Mar	Apr (1)	May (1)	Jun	Jul (3)	Aug	Sep	Oct	Nov	Dec