phpwiki-talk

RE: [Phpwiki-talk] Strange error in URL.

[Breki T. <br...@ho...>]

>You might want to check near the bottom of index.php --
>there are defines (in later versions?) which will force
>host & path.

 I've tried that. It gives the right path for the URL, but only loads the
FrontPage when I click a link. :-/

 Any ideas what it could be? It seems to be accessing the database allright
when it fetches the FrontPage, but it doesn't seem to want to let me go any
further than that. I've even tried manually opening a page by typing in
http://www.qliphoth.net/bottom.php?ModiX , for example, but it still throws
the FrontPage at me.

Re: [Phpwiki-talk] Re: extlinks

[aphid <me...@ap...>]

On Tuesday, October 1, 2002, at 12:39  AM, Reini Urban wrote:

> aphid schrieb:
>> hey, you commented on my wiki that you'd add something for extlinks 
>> so it would be possible to make them pop up in new windows..
>> i was wondering if this had gone in and where i should look for it 
>> when it does?  i did a multi-file search to try to hunt down where it 
>> renders the a href tags for links and couldn't find it.
>
> sorry, currently I'm very busy.
>
> I know I did it on my private wiki, so it's not online yet.
> you need <a target"_new" href=""> in LinkUnknownWikiWord()
>
> I added:
>   if ($request->getArg('frame'))
>       $link->setAttr('target', '_top');
>
> Similarly you can do that for yours,
> or override this function in your theme.
>
>   $link->setAttr('target', '_new');
>

I've tried this in theme.php and if it did anything, I'm not sure what. 
  What I'm trying to do is have links that go away from the wiki (which 
I believe are called NamedWiki) to open in "_new".. maybe my calling 
them external links confused the situation.

Cheers
A

Re: [Phpwiki-talk] Strange error in URL.

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

Breki,

Which version of phpwiki?

You might want to check near the bottom of index.php -- there are 
defines (in later versions?) which will force host & path.

jbw

Breki Tomasson wrote:
>  Hi there!
> 
>  I updated to the latest versions of Apache and PHP yesterday (I'm running
> the server on Windows XP, which has worked fine with the wiki for half a
> year), and my phpwiki suddenly stopped working. I've modified the original
> code slightly, but hardly enough to warrant an error like this, which showed
> up after the upgrade of PHP and Apache.
> 
>  The Wiki, which is housed on http://www.qliphoth.net automatically usde
> pathnames like http://www.qliphoth.net/bottom?university when i had a link
> to [university]. After the upgrade, the PHP seems to want to look for the
> pages in the path http://'/?university instead, for some reason which I
> cannot understand.
> 
>  When I upgraded, I could use the original configuration file for Apache,
> but was forced to upgrade the PHP-file. Other PHP-applications still seem to
> work fine, as you can see under www.qliphoth.net/gallery, which is very
> PHP-intensive.
> 
>  What do you think this problem could be dependant on?
> 
>  Please e-mail the answer directly to me.
> 
>  Thank you,
>  Breki Tomasson. (br...@ho...)
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] Strange error in URL.

[Breki T. <br...@ho...>]

 Hi there!

 I updated to the latest versions of Apache and PHP yesterday (I'm running
the server on Windows XP, which has worked fine with the wiki for half a
year), and my phpwiki suddenly stopped working. I've modified the original
code slightly, but hardly enough to warrant an error like this, which showed
up after the upgrade of PHP and Apache.

 The Wiki, which is housed on http://www.qliphoth.net automatically usde
pathnames like http://www.qliphoth.net/bottom?university when i had a link
to [university]. After the upgrade, the PHP seems to want to look for the
pages in the path http://'/?university instead, for some reason which I
cannot understand.

 When I upgraded, I could use the original configuration file for Apache,
but was forced to upgrade the PHP-file. Other PHP-applications still seem to
work fine, as you can see under www.qliphoth.net/gallery, which is very
PHP-intensive.

 What do you think this problem could be dependant on?

 Please e-mail the answer directly to me.

 Thank you,
 Breki Tomasson. (br...@ho...)

[Phpwiki-talk] phpwiki/postnuke install problem

[Tim G. <tgr...@ho...>]

I installed the most recent phpwiki/postnuke module, went through the =
install procedures (twice) and get the same thing: a blank page =
presented instead of the default pages. by blank I mean=20
<html><head>very little stuff</head>
<body></body></html>
that kind of blank.
Anyone ever seen this before?
Oh yeah
Postnuke is 7.21 on hostnuke.com

The only thing I wasnt sure of was doing the chown on the files. Sorry =
I'm a unix newbie.

Thanks for any help,
Tim Graham

Re: [Phpwiki-talk] Re: auth prefs

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

Reini Urban wrote:
We just discussed the layout here, but I have no code yet, because of 
the UserAuth problems. See the mainlinglist and the phpwiki pages.

Ok found the discussion and am up to speed.


We decided to put the groupmembers info into simple wikipages as * lines.


Hmmm... I would have gone for DB fields, but then I wasn't paying 
attention... See below.

PagePermission is just another numeric meta_data field "perm", similar 
to "hits" or "pref".

'r' = view
'w' = edit
'x' = ? admin rights ?

Also a new field owner: "owner", with groups "owner.group"? or seperate?
"userid" is the latest author.
for upgrading the owner will be the original userid field.

I would store in seperate "owner" and "group" meta fields, if not in 
fields on the page_tbl table (faster queries).  See below.


Then each action needs a central permission check in main().
For display, save/remove and various other executable plugins.
I would move the basic read/write checks from main() to the WikiDB level.

Then we have to enhance requiredAuthority ($action) to
requiredAuthority ($action, $page),

ok

or make requiredAuthority ($action) a WikiDB method.

For example to disallow the listing of private -r pages in PageList.
or if an admin plugin may change other pages.

Yikes! That's a lot of parsing for an 'a-r g+r' page that isn't owned by 
the user.  It would be a lot easier if group membership was stored in 
the DB:

1)
"SELECT groupname FROM $user_group_tbl WHERE username=$username"

vs.

2)
// Note: functions are just for demo of what is nec. not an actual
// proposal
//  get all the groups
$groups = getGroups();
$membership = array();
foreach($groups as $x){
     // grab/parse group page looking for username
     if(userInGroup($x, $username)){
         $membership[] = $x;
     }
}

In #1 there is one DB call and in #2 there will be 1+N DB calls (where N 
is the number of groups).  #2 is not going to scale up very well.

jbw


** Sorry again Reini...ment to send to whole list.  I am used to just 
Replying (not Reply-Alling) to lists **

Re: [Phpwiki-talk] Re: auth prefs

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

Reini Urban wrote:
> Joby Walker schrieb:
> 
>> Reini Urban wrote:
>>
>>> Joby Walker schrieb:
>>>
>>>> 1) a new login method (currently PUBCOOKIE_LOGIN): this will allow 
>>>> end user to use the University of Washington's Pubcookie system.  
>>>> When using Pubcookie the end user accesses a web site he is forced 
>>>> to authenticate at a central site, and the central login site then 
>>>> guarantees the authentication to the web site.  Thus the end user's 
>>>> password is never available to the web site, and allowing a unified 
>>>> login structure for an organization.  The only check is that 
>>>> $HTTP_SERVER_VARS['REMOTE_USER'] is guaranteed to be set and correct.
>>>
> 
> Oops. I mixed that up with our local php cookie login systems, which I 
> had to fix. pubcookie seems to be a good thing.
> So why not?

No problem, I like a healthy skepticism of a method's security!

> 
> Seems not too hard to support in phpwiki, but requires lots of changes 
> in apache. I'll have a look.
> 
> http://www.washington.edu/computing/pubcookie/uwash-mod-1.77.html
> 
> How do you detect this pubcookie session with PHP besides 
> $_ENV['REMOTE_USER'] and $_COOKIE[PUBCOOKIE_NetID]?
> 
> http://www.washington.edu/computing/web/publishing/uwnetid.html
> 
> REFERER?
> Maybe any SSL var?
> 

I agree that support is pretty easy to add, but I would not make it an 
detected login method.  If this method is needed, there is a significant 
amount of backend work that needs to be completed that I don't think we 
should worry about autodetection -- If this method is desired the wiki 
owner should just say so.  In addition, if phpwiki makes a "false 
positive" detection of pubcookie, a serious security breach could 
result.  All we need is:

index.php (or config_user.php/config_dist.php):
#define('USE_PUBCOOKIE_AUTH', true);
if(!defined('USE_PUBCOOKIE_AUTH')) define ('USE_PUBCOOKIE_AUTH', false);

WikiUser.php:
function _pwcheck...
// right after the ADMIN_USER check
if(USE_PUBCOOKIE_AUTH){
	if($HTTP_SERVER_VARS['REMOTE_USER'] == $userid){
		return WIKIAUTH_USER;
	}
	return false;
}

jbw

Re: [Phpwiki-talk] Re: auth prefs

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

Joby Walker schrieb:
> Reini Urban wrote:
>> Joby Walker schrieb:
>>
>>> 1) a new login method (currently PUBCOOKIE_LOGIN): this will allow 
>>> end user to use the University of Washington's Pubcookie system.  
>>> When using Pubcookie the end user accesses a web site he is forced to 
>>> authenticate at a central site, and the central login site then 
>>> guarantees the authentication to the web site.  Thus the end user's 
>>> password is never available to the web site, and allowing a unified 
>>> login structure for an organization.  The only check is that 
>>> $HTTP_SERVER_VARS['REMOTE_USER'] is guaranteed to be set and correct.
>>
>> I'm against adding this to the default HEAD branch of phpwiki.
>> I know that some sites do cookie auth, and even we do it in our 
>> internal backoffice, but this is totally insecure.
> 
> Why is this more insecure than other methods?

Oops. I mixed that up with our local php cookie login systems, which I 
had to fix. pubcookie seems to be a good thing.
So why not?

Seems not too hard to support in phpwiki, but requires lots of changes 
in apache. I'll have a look.

http://www.washington.edu/computing/pubcookie/uwash-mod-1.77.html

How do you detect this pubcookie session with PHP besides 
$_ENV['REMOTE_USER'] and $_COOKIE[PUBCOOKIE_NetID]?

http://www.washington.edu/computing/web/publishing/uwnetid.html

REFERER?
Maybe any SSL var?

> Pubcookie follows the kerberos model for single login access, and was
> the first model accepted by the Internet2's WebISO project:
> 
> http://middleware.internet2.edu/webiso/
> 
> Many universities use a similar login system, and they will become much
> more common in the near future.
> 
> More info on UW's Pubcookie:
> 
> http://www.washington.edu/pubcookie/
> 
> If you are worried about stolen cookies, why are we using PHPSessions?
> They are only 128bit numbers.
> 
>> But I already added beta support for ALLOW_HTTP_AUTH_LOGIN which 
>> accepts already logged in users.
> 
> Unfortunately, ALLOW_HTTP_AUTH_LOGIN is not useful for my purposes. With
> pubcookie there is no password to go with the
> $HTTP_SERVER_VARS['REMOTE_USER'] (because only the login server is
> trusted with passwords), thus as structured a login would be impossible.
> And you can't allow a REMOTE_USER login with out a password, because
> then there would be no protection against a user changing to a different
> account (since none of them have passwords) -- thus the necessity of the
> WikiUserID == REMOTE_USER (which breaks the administrative account).
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] phpwiki slow?

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

ph...@de... schrieb:
> On Wed, 02 Oct 2002 07:45:57 -0700, Joby Walker wrote:
> => Phpwiki is a pretty big app.  Every page access 
> => requires the loading of many (10+) php files, and then the content of 
> => the page must be parsed as well.
> 
> 	Which is *really* unfortunate for those of us trying to
> make phpWiki work as an additional collaborative tool for clients
> hosted on shared servers (such as those at http://www.pair.com).
> 
> 	I always keep my fingers crossed that our very creative
> phpwiki dev team keeps us in mind as they continue to improve
> this great "little" app.

Pretty big? I work with php apps which load > 500 php files per page 
request. Also on public serverhosts, with lots of load.

But if it's too slow for you, we can think of optionally concatenating 
the generally required files alltogether to ease your pain.
In some kind of Makefile.

(untested. just to get the idea)

Makefile:
BACKEND = sql
DB_ROOT = root
DB_ROOTPASS =
DB_USER = wikiuser
DB_PASS = fixme
WIKI_DB = phpwiki
ALL =  index.php lib/main.php lib/prepend.php ...

noop :
         true

install : install-mysql
         echo "read INSTALL"
         echo "browse to configurator.php"

install-mysql :
!if DB_ROOT
         mysqladmin -u$(DB_ROOT) -p$(DB_ROOTPASS) create $(WIKI_DB)
         mysql -u$(DB_ROOT) -p$(DB_ROOTPASS) -e"GRANT select, insert, 
update, delete ON $(WIKI_DB).* TO $(DB_USER)@localhost IDENTIFIED BY 
'$(DB_PASS)'"
!endif
         mysql -u$(DB_USER) -p$(DB_PASS) $(WIKI_DB) < schemas/mysql.sql

single-file : phpwiki.php

phpwiki.php: $(ALL)
         cat $(ALL) > phpwiki.php
# patch phpwiki.php to disable most require calls
	for $s in $ALL; do
           perl -pi.bak -e"s|require_once\('$s'\)|//$&|" phpwiki.php
	done
         echo "use phpwiki.php as your DirectoryIndex"

and so on...

I've done this single-file version for my autolisp standard library, 
with the help of a simple perl script. But I found no performance 
advantage, only administrative. Even on windows which has aching slow 
fileaccess.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Re: auth prefs

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

Joby Walker schrieb:
> Reini Urban wrote:
>> Joby Walker schrieb:
>>
>>> 2) no admin account (ADMIN_GROUP): this would grant to specific users 
>>> WIKIAUTH_ADMIN privilages.  With this enabled there is no admin 
>>> account, but certain users have administrative privilages.  With this 
>>> modifications can be tracked by user.
>>
>> This will be a PagePermission feature, once groups are ready.
> 
> 
> Any info on this?  I will certainly help.

Good.

We just discussed the layout here, but I have no code yet, because of 
the UserAuth problems. See the mainlinglist and the phpwiki pages.

We decided to put the groupmembers info into simple wikipages as * lines.

PagePermission is just another numeric meta_data field "perm", similar 
to "hits" or "pref".
Also a new field owner: "owner", with groups "owner.group"? or seperate?
"userid" is the latest author.
for upgrading the owner will be the original userid field.

Then each action needs a central permission check in main().
For display, save/remove and various other executable plugins.
I would move the basic read/write checks from main() to the WikiDB level.

Then we have to enhance requiredAuthority ($action) to
requiredAuthority ($action, $page),
or make requiredAuthority ($action) a WikiDB method.

For example to disallow the listing of private -r pages in PageList.
or if an admin plugin may change other pages.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] phpwiki slow?

[<ph...@de...>]

On Wed, 02 Oct 2002 07:45:57 -0700, Joby Walker wrote:
=> Phpwiki is a pretty big app.  Every page access 
=> requires the loading of many (10+) php files, and then the content of 
=> the page must be parsed as well.

	Which is *really* unfortunate for those of us trying to
make phpWiki work as an additional collaborative tool for clients
hosted on shared servers (such as those at http://www.pair.com).

	I always keep my fingers crossed that our very creative
phpwiki dev team keeps us in mind as they continue to improve
this great "little" app.

	Cheers,

	- Don (who is looking forward to the next "release")

Re: [Phpwiki-talk] Re: auth prefs

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

Reini Urban wrote:

> Joby Walker schrieb:
>
>> 1) a new login method (currently PUBCOOKIE_LOGIN): this will allow 
>> end user to use the University of Washington's Pubcookie system.  
>> When using Pubcookie the end user accesses a web site he is forced to 
>> authenticate at a central site, and the central login site then 
>> guarantees the authentication to the web site.  Thus the end user's 
>> password is never available to the web site, and allowing a unified 
>> login structure for an organization.  The only check is that 
>> $HTTP_SERVER_VARS['REMOTE_USER'] is guaranteed to be set and correct.
>
>
>
> I'm against adding this to the default HEAD branch of phpwiki.
> I know that some sites do cookie auth, and even we do it in our 
> internal backoffice, but this is totally insecure.
>

Why is this more insecure than other methods?

Pubcookie follows the kerberos model for single login access, and was
the first model accepted by the Internet2's WebISO project:

http://middleware.internet2.edu/webiso/

Many universities use a similar login system, and they will become much
more common in the near future.

More info on UW's Pubcookie:

http://www.washington.edu/pubcookie/

If you are worried about stolen cookies, why are we using PHPSessions?
They are only 128bit numbers.

> But I already added beta support for ALLOW_HTTP_AUTH_LOGIN which 
> accepts already logged in users.
>

Unfortunately, ALLOW_HTTP_AUTH_LOGIN is not useful for my purposes. With
pubcookie there is no password to go with the
$HTTP_SERVER_VARS['REMOTE_USER'] (because only the login server is
trusted with passwords), thus as structured a login would be impossible.
And you can't allow a REMOTE_USER login with out a password, because
then there would be no protection against a user changing to a different
account (since none of them have passwords) -- thus the necessity of the
WikiUserID == REMOTE_USER (which breaks the administrative account).

jbw

P.S. Sorry Reini, ment to sent to the whole list...

Re: [Phpwiki-talk] Re: auth prefs

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

Reini Urban wrote:
> Joby Walker schrieb:
>> 2) no admin account (ADMIN_GROUP): this would grant to specific users 
>> WIKIAUTH_ADMIN privilages.  With this enabled there is no admin 
>> account, but certain users have administrative privilages.  With this 
>> modifications can be tracked by user.
> 
> 
> This will be a PagePermission feature, once groups are ready.

Any info on this?  I will certainly help.

jbw

Re: [Phpwiki-talk] phpwiki slow?

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

LS wrote:
>     I just installed phpwiki-1.3.3 from CVS on my RH7.3 Linux server running
> Apache/2.0.40 (Unix) PHP/4.3.0-dev and MySQL4.0a. I host a number of small PHP
> sites and they all respond very quickly, despite the server being a P166 with 92MB
> RAM, but for some reason PHPWiki takes about 1.4 seconds to render typical pages.
> RecentChanges takes nearly 7 seconds.

I don't know if anyone has tested Apache 2.0/PHP 4.3 with phpwiki.  But 
your server is most likely the issue.  A P166 with 92MB is really lite 
to run phpwiki.  Phpwiki is a pretty big app.  Every page access 
requires the loading of many (10+) php files, and then the content of 
the page must be parsed as well.  This is probably competing with your 
MySQL database to be in memory.  Thus when the php parser is activated 
your MySQL database is getting dumped to swap.  And when php makes MySQL 
calls, MySQL is brought back to memory and the php/apache process is 
dumped to swap.  etc...

This would indicate a need for a new server. Perhaps you can keep 
apache/php/phpwiki on your P166/92MB, but stick MySQL on another old 
computer -- though this introduces network latency...

jbw

Re: [Phpwiki-talk] phpwiki slow?

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

LS schrieb:
> Hi-
>     Can anyone suggest why PHPWiki is so slow, or how I can configure it to make it
> faster?
> 
>     I just installed phpwiki-1.3.3 from CVS on my RH7.3 Linux server running
> Apache/2.0.40 (Unix) PHP/4.3.0-dev and MySQL4.0a. I host a number of small PHP
> sites and they all respond very quickly, despite the server being a P166 with 92MB
> RAM, but for some reason PHPWiki takes about 1.4 seconds to render typical pages.
> RecentChanges takes nearly 7 seconds.
>     I am trying to get folks at my office to embrace the Wiki world, but they are
> complaining about the site being too slow. The pages take the same amount of time
> to load via lynx on localhost.
>     I do not have PHPA running on the server, as it does not yet support Apache2,
> and I'm wondering if there is just a hell of a lot of PHP parsing that has to
> happen each time the Wiki is called. Or perhaps there is just a lot of database
> updates that need to happen and PEAR isn't handling them well.
>     If anyone has suggestions on how to use PHPWiki on a small server, please let
> me know.

for me 1.3.4pre and 1.3.3 is of about the same speed.
jeff's page cache and the upgrade to the new pear DB brought it to the 
same speed as of the previous ADODB in 1.3.2.

tried the ZendOptimizer?

is it innodb on mysql4? maybe it's also apache2.
also 92MB RAM is very low. we typically have from 512MB to 1.5GB RAM on 
our servers.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: auth prefs

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

Joby Walker schrieb:
> Since you seem to be heading up the modifications to the user 
> authentication system, I thought I would run by you two more options I 
> would like to add.
> 
> 1) a new login method (currently PUBCOOKIE_LOGIN): this will allow end 
> user to use the University of Washington's Pubcookie system.  When using 
> Pubcookie the end user accesses a web site he is forced to authenticate 
> at a central site, and the central login site then guarantees the 
> authentication to the web site.  Thus the end user's password is never 
> available to the web site, and allowing a unified login structure for an 
> organization.  The only check is that $HTTP_SERVER_VARS['REMOTE_USER'] 
> is guaranteed to be set and correct.

I'm against adding this to the default HEAD branch of phpwiki.
I know that some sites do cookie auth, and even we do it in our internal 
backoffice, but this is totally insecure.

But I already added beta support for ALLOW_HTTP_AUTH_LOGIN which accepts 
already logged in users.

> 2) no admin account (ADMIN_GROUP): this would grant to specific users 
> WIKIAUTH_ADMIN privilages.  With this enabled there is no admin account, 
> but certain users have administrative privilages.  With this 
> modifications can be tracked by user.

This will be a PagePermission feature, once groups are ready.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] auth prefs

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

Reini,

Since you seem to be heading up the modifications to the user 
authentication system, I thought I would run by you two more options I 
would like to add.

1) a new login method (currently PUBCOOKIE_LOGIN): this will allow end 
user to use the University of Washington's Pubcookie system.  When using 
Pubcookie the end user accesses a web site he is forced to authenticate 
at a central site, and the central login site then guarantees the 
authentication to the web site.  Thus the end user's password is never 
available to the web site, and allowing a unified login structure for an 
organization.  The only check is that $HTTP_SERVER_VARS['REMOTE_USER'] 
is guaranteed to be set and correct.

2) no admin account (ADMIN_GROUP): this would grant to specific users 
WIKIAUTH_ADMIN privilages.  With this enabled there is no admin account, 
but certain users have administrative privilages.  With this 
modifications can be tracked by user.

jbw

[Phpwiki-talk] 1.3.4pre not 1.3.3

[LS <alp...@ya...>]

I am sorry, I mistyped my PHPWiki version. I am using (and trying to resolve
slowness issues with) 1.3.4pre not 1.3.3.

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

[Phpwiki-talk] phpwiki slow?

[LS <alp...@ya...>]

Hi-
    Can anyone suggest why PHPWiki is so slow, or how I can configure it to make it
faster?

    I just installed phpwiki-1.3.3 from CVS on my RH7.3 Linux server running
Apache/2.0.40 (Unix) PHP/4.3.0-dev and MySQL4.0a. I host a number of small PHP
sites and they all respond very quickly, despite the server being a P166 with 92MB
RAM, but for some reason PHPWiki takes about 1.4 seconds to render typical pages.
RecentChanges takes nearly 7 seconds.
    I am trying to get folks at my office to embrace the Wiki world, but they are
complaining about the site being too slow. The pages take the same amount of time
to load via lynx on localhost.
    I do not have PHPA running on the server, as it does not yet support Apache2,
and I'm wondering if there is just a hell of a lot of PHP parsing that has to
happen each time the Wiki is called. Or perhaps there is just a lot of database
updates that need to happen and PEAR isn't handling them well.
    If anyone has suggestions on how to use PHPWiki on a small server, please let
me know.

Thanks!

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

[Phpwiki-talk] Re: extlinks

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

aphid schrieb:
> hey, you commented on my wiki that you'd add something for extlinks so 
> it would be possible to make them pop up in new windows..
> 
> i was wondering if this had gone in and where i should look for it when 
> it does?  i did a multi-file search to try to hunt down where it renders 
> the a href tags for links and couldn't find it.

sorry, currently I'm very busy.

I know I did it on my private wiki, so it's not online yet.
you need <a target"_new" href=""> in LinkUnknownWikiWord()

I added:
   if ($request->getArg('frame'))
       $link->setAttr('target', '_top');

Similarly you can do that for yours,
or override this function in your theme.

   $link->setAttr('target', '_new');

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

Re: [Phpwiki-talk] Page Trail plugin (comments)

[Jeff D. <da...@da...>]

I haven't tried the plugin yet, but here's my one coding
suggestion.

You can use $request->setSessionVar() and $request->getSessionVar()
to save persistent data.  (Also $request->{get,set}CookieVar...)
And you can save arrays (or anything else) that way.

So instead of 

>          $Page=array();
>          // Shift down the page names and store them back to cookies
>          for ($count=$numberlinks; $count>0; $count--) {
> 		$thisvalue="PageTrail".$count;
>                  $thiscookie = @$_COOKIE["$thisvalue"];
>                  if ($thiscookie!="") {
>                          $Page[$count+1]=$thiscookie;
>                  } else {
>                          $Page[$count+1]="";
>                  }
>          }
>          $Page[1]=$thispage;
>          // Now lets cycle through them saving them with setcookie
>          $html = " ";
>          for ($count=$numberlinks; $count>0; $count--) {
>                  if ($Page[$count]!="") {
>                          $Name="PageTrail" . $count;
> 			$Value = $Page[$count];
> 			setcookie ($Name, $Value, 0, '/');
> 		}
> 	}

You can do something like (this is untested, of course, so
guaranteed not to work):

    $pagetrail = $request->getSessionVar('PageTrail');
    if (!is_array($pagetrail))
        // FIXME: probably better validation is in order...
        $pagetrail = array();
    array_unshift($pagetrail, $thispage);
    array_split($pagetrail, $numberlinks); // limit trail length
    $request->setSessionVar('PageTrail', $pagetrail);

(Note that $pagetrail is a zero-based array, rather than a
one-based array...)

Besides being cleaner code, it has the advantage of not 
storing a whole handful of cookies in the clients browser...

Cheers!

[Phpwiki-talk] =?GB2312?B?uafPssT6o6E=?=

[<sk...@sk...>]

尊敬的先生（小姐）：
恭喜您！这是一封随机发送的信件，内含重要的致富秘诀，现免费赠送，只向1000名先到者开放，详情请见：http://www.dirshop.com/mall/index.php?user=wangyao 

[Phpwiki-talk] user registration and administration

[Andreas R. <an...@ri...>]

Is there a roadmap, when approximately will be a new release of 
phpwiki with a working user login with password?

Mit freundlichen Gr=FC=DFen
Andreas Rittershofer

--
E-Learning mit http://www.LmTM.de/
*die* E-Learning-Plattform f=FCr Physik!
und
Homepage http://www.rittershofer.de/

RE: [Phpwiki-talk] creating themes

[<mc...@tw...>]

Yeah, that would be useful knowledge for Yours Truly too=2E Gracias=2E Lov=
e McD=2E

Original Message:
-----------------
From: Michael Hoennig michael@hostsharing=2Enet
Date: Fri, 27 Sep 2002 12:07:33 +0200
To: phpwiki-talk@lists=2Esourceforge=2Enet
Subject: [Phpwiki-talk] creating themes


Hi list members!

Is there any how to out there for creating own themes?  I tried to copy a
theme and adapt it, but that does not seem to work=2E  If I patch the
"default" theme, after a while it is reset to the original :-(

Thanks
=09Michael

--=20
Hostsharing eG / Boytinstr=2E 10 / D-22143 Hamburg
phone+fax: +49 700 HOSTSHARING (=3D +49 700 46787427)
http://www=2Ehostsharing=2Enet: where YOU make the difference


-------------------------------------------------------
This sf=2Enet email is sponsored by:ThinkGeek
Welcome to geek heaven=2E
http://thinkgeek=2Ecom/sf
_______________________________________________
Phpwiki-talk mailing list
Phpwiki-talk@lists=2Esourceforge=2Enet
https://lists=2Esourceforge=2Enet/lists/listinfo/phpwiki-talk


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E

Re: [Phpwiki-talk] Page Trail plugin (comments)

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

I added a fixed version to CVS.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/lib/plugin/PageTrail.php

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