phpwiki-talk

Re: [Phpwiki-talk] AdSense Tip

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

Rui Carmo schrieb:
> Besides yesterday's fix, I spent quite some time figuring out why I 
> still had another "hit" on the search pages. At first I thought it was 
> something inside the search code, but when I started logging IP 
> addresses it became obvious.
> 
> It turned out that AdSense will trigger an _immediate_ hit from the 
> google bot if I display ads on my *Search pages, which prompted me to 
> include this little snippet right at the start of index.php (to waste as 
> little resources as possible):
> 
> 
> define( "DUMB_BOTS", 
> '/(JPluck|Mediapartners|ia_archiver|googlebot|msnbot|Crawl)/i' );
> 
> if( preg_match( DUMB_BOTS, $_SERVER['HTTP_USER_AGENT'] ) ) {
>   if( preg_match( '/\?(s|action|version)=/', $_SERVER['REQUEST_URI'] ) ) {
>     header( "HTTP/1.1 404 File Not Found" );
>     echo( "<H1>404 File Not Found</H1>" );
>     exit;
>   }
> }

That's not a good idea!
Google's Ad Sense checks where the ads really appear on the page, and 
calculates the rank (= money!) from this info.
If you reject the checker you will get no profit from AdSense at all.

rejected the main googlebot is also not a good idea.
The googlebot is a good thing.
You just have to prepare for being "slashdotted" to death once in a 
while. Some referrer check or referrer throttling.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] AdSense Tip

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

Besides yesterday's fix, I spent quite some time figuring out why I 
still had another "hit" on the search pages. At first I thought it was 
something inside the search code, but when I started logging IP 
addresses it became obvious.

It turned out that AdSense will trigger an _immediate_ hit from the 
google bot if I display ads on my *Search pages, which prompted me to 
include this little snippet right at the start of index.php (to waste 
as little resources as possible):


define( "DUMB_BOTS", 
'/(JPluck|Mediapartners|ia_archiver|googlebot|msnbot|Crawl)/i' );

if( preg_match( DUMB_BOTS, $_SERVER['HTTP_USER_AGENT'] ) ) {
   if( preg_match( '/\?(s|action|version)=/', $_SERVER['REQUEST_URI'] ) 
) {
     header( "HTTP/1.1 404 File Not Found" );
     echo( "<H1>404 File Not Found</H1>" );
     exit;
   }
}


On Dec 7, 2004, at 11:39 AM, Rui Carmo wrote:

> Bingo. I spotted it late yesterday evening when trying to figure out 
> what PageType was for. My fork already had some of those lines moved 
> around (I added If-Modified-Since checking near those bits and return 
> "not modified"), but that was basically it.
>
> Which would definitely place my fork as 
> 1.3.7-plus-bits-of-other-versions-on-steroids :)
>
> If only it wasn't running for two years like this (sigh). Well, at 
> least my other optimizations work even faster now :)
>
> R.
>
> On Dec 7, 2004, at 1:33, Carsten Klapp wrote:
>
>>>
>>
>> Hi Rui,
>>
>> This sounds exactly like the "double transformation" bug which I 
>> (inadvertently introduced, and later) fixed around 1.3.7.

[Phpwiki-talk] Re: Sourceforge changing the environment....

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

Paolo Salvan schrieb:
> ...Update: I've now read your "We survived webserver switch without any
> problem." message...
> 
> We unfortunatly didn't survived... :o(
> do you have any suggestion to help us debug the problem?
> Please let us know.... bye!
> Paolo
> 
> ------------------------------------------------------------
> Hi Reini,
> 
> I'm replying your 26-october mail; ...is there any news?
> 
> Sourceforge has been updated, and our website (thinstation.sf.net) is
> down :o( (the already-described white screen...)

Sorry. Several sf.net user got the white-screen on their phpwiki sites.
I don't know why yet (new symlinked apache root?),
but I know how to workaround:

Comment the if statement at the end of index.php:

// if (@is_dir( ...
     include(dirname(__FILE__)."/lib/main.php");

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

Re: [Phpwiki-talk] Load and Overwrite

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

Micki Kaufman schrieb:
> Hi folks - just pulled the latest build from cvs. Looks good!
> 
> There seems to be a lot of mysql flakiness that I'm tracking down, some 
> perms irregularities, but by and large it's looking good.

ADODB should be fine, but I have to update PearDB and dba to enable the 
new undoable remove feature.

And the new purge-empty-pages button.
I just purged >1000 unreferenced empty pages at the 
phpwiki.sf.net/demo/en mysql setup.
These came from old link parsings steps and where never deleted.

I added now new experimental code (in ADODB only) to clean up old stale 
links (mostly syntax problems) which clutter the page table.

> One issue off the bat that I encountered - the 'load with overwrite' 
> option (used for bringing in zipdumps with page histories) seems broken, 
> and all that can be loaded is version 1 (the oldest) for each page.

Thanks.

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

Re: [Phpwiki-talk] We survived webserver switch without any problem.

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

Reini Urban schrieb:
> Some good news:
> sf.net switched to the new servers yesterday at 12:00 am
> (just when I tried to fix the security problem, reported yesterday)

More observations on our new servers:

mysql is at least 10 times faster than before. good. wonder why.
dba has gdbm and db4 (berkeley), which is good. both seem to work fine.

apache and php are a fresh custom builds, not the default fc1 ones. good!

apache-1.3.33 and not apache-2. very good! (no threading problems with 
certain php libs)

php is 4.3.9, so the PCRE memory problems (while converting old markup) 
should be gone.

cron is enabled again. good.
I enabled the demo daily update again. with a better script which 
handles conflicts:
#!/bin/sh
cd ~/demo
cvs -n up 2>&1 |grep "^C " | cut -c3- > ~/cvsup.lst
for f in $(cat  ~/cvsup.lst); do
   mv $f $f.tmp
   cvs up -C $f 2>&1 | tee -a cvsup.log
done
cvs up 2>&1 | tee -a cvsup.log

you can also expect the nightly tarballs soon without CVS dirs as before.

php uses now the Turck MMCache-2.4.6 (30MB), which seems to be better 
than the APC cache as before. we will see.

xml-rpc is now built in, so our xml-rpc server will not work on sf.net 
until our library is fixed. low priority though.
Fixing SOAP has also low priority. Maybe this will gain more popularity 
with the new blogging stuff next year.

mbstring has bow with full native support, so we can finish our japanese 
and chinese demo sites soon. even ldap and imap is now enabled.
gd has no TTF support.

still no ming support for dynamic flash generation. but this can be done 
via external binaries. (similar to our current PDF generation)
I'm working on some kind of ActionScript plugin for better image galleries.

> And all our own wiki's still work ok.
>   1.3.10, 1.3.11pre and 1.2.5
> That's good.
> So the expected force-type php problem with the apache2 PrettyWiki setup 
> we use didn't cause any problems. good.
> 
> We even had our first spammers on the 1.2.5 site.
> 
> There are some dba glitches to fix in 1.2.5 on save:
> "dba_insert ... Cannot replace in .. phpwiki-1.2.5/lib/dbalib.php on 
> line 121" which might require an immediate bugfix.
> 
> The servers are still as slow as before. Maybe even slower.
> I'll report some accurate timings later.
> 
> But first I'll check dba and convert our 1.3.x wiki's back from mysql to 
> dba to get rid of the memory problems finally.
-- 
Reini Urban
http://phpwiki.org/

[Phpwiki-talk] Load and Overwrite

[Micki K. <mic...@co...>]

Hi folks - just pulled the latest build from cvs. Looks good!

There seems to be a lot of mysql flakiness that I'm tracking down, 
some perms irregularities, but by and large it's looking good.

One issue off the bat that I encountered - the 'load with overwrite' 
option (used for bringing in zipdumps with page histories) seems 
broken, and all that can be loaded is version 1 (the oldest) for each 
page.

Thanks!
Micki
-- 

Micki
mailto:mic...@co...

[Phpwiki-talk] We survived webserver switch without any problem.

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

Some good news:
sf.net switched to the new servers yesterday at 12:00 am
(just when I tried to fix the security problem, reported yesterday)

And all our own wiki's still work ok.
   1.3.10, 1.3.11pre and 1.2.5
That's good.
So the expected force-type php problem with the apache2 PrettyWiki setup 
we use didn't cause any problems. good.

We even had our first spammers on the 1.2.5 site.

There are some dba glitches to fix in 1.2.5 on save:
"dba_insert ... Cannot replace in .. phpwiki-1.2.5/lib/dbalib.php on 
line 121" which might require an immediate bugfix.

The servers are still as slow as before. Maybe even slower.
I'll report some accurate timings later.

But first I'll check dba and convert our 1.3.x wiki's back from mysql to 
dba to get rid of the memory problems finally.

Helmer Pardun schrieb:
> thanks for the fast answer. Following your advice, I'll install phpwiki
> again at the end of the week.
> -----Ursprüngliche Nachricht-----
> Von: Reini Urban [mailto:ru...@x-...] 
> Gesendet: Dienstag, 7. Dezember 2004 12:40
> An: Helmer Pardun
> Cc: php...@li...
> Betreff: Re: [Phpwiki-talk] newest version to install?
> 
> CVS WikiDB is just in being refactored, which will be finished in about 
> two days. It works, but some major changes will still come.
> (remove a page, improved pagedata cache, improved versiondata cache).
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Converting from gdbm to mysql

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

Earnie Boyd schrieb:
> Anyone on this list have any words of wisdom?

backup in old db, change to mysql, restore in new db.

via PhpWikiAdminstration
or manually via action=zip, action=loadfile
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] odd behavior

[Alan B. <al...@ba...>]

I've just setup phpwiki 1.3.10, and though I've set it up before, for some
reason this time it's giving me fits.  First I got a bunch of the following,
though I didn't think DEBUG was a required config option.

lib/IniConfig.php:108: Notice[1024]: missing config setting for DEBUG
lib/main.php:869: Notice[8]: Use of undefined constant DEBUG - assumed 'DEB=
UG'
=2E..

Setting it in config.ini fixed that, but when I try to login, I get a
blank page.  I already had to comment out the "if" in index.php to get
it going at all.  If anyone can save me some more hours of debugging, I'd
appreciate it...

--=20
Alan Batie                   ______    alan.batie.org                Me
alan at batie.org            \    /    www.qrd.org         The Triangle
PGPFP DE 3C 29 17 C0 49 7A    \  /     www.pgpi.com   The Weird Numbers
27 40 A5 3C 37 4A DA 52 B9     \/      spamassassin.taint.org  NO SPAM!

The voters have spoken.  Let's hope we survive the result.

[Phpwiki-talk] Bibdesk Wiki pages messed up

[Christiaan H. <chr...@we...>]

Several pages on the Bibdesk Wiki page are messed up, they have long 
lists of (at least to me) non-sensical links on the bottom.

Christiaan

Re: [Phpwiki-talk] can't unlock pages in CVS build and much more

[Stefan <son...@ba...>]

Hello i have to be more speciffic sorry

Reini Urban schrieb:

> Stefan schrieb:
>
>> in the cvs version it is not possible to unlock pages.
>
> I already said that current pagadata cache is unstable and needs some 
> more days to stabilize. This was also reported three days ago by 
> Charles Corrigan.

oh thats fine thanks

>> I've also tried to use the acl to set page permissions. does anyone 
>> know how to handle this tool? i can change what i want but nothing 
>> really happens. the right managment is much to difficult and buggy to 
>> use it.
>
>
> I see no other bugs than the current pagadata cache problem. I'd be 
> happy to receive bugreports.

have a look at this please: try to change the settings of a page that 
only authentificated users can see the page
maybe i did'nt understand the syntax.  i have tried it more than one 
hour on every way i found but it happens nothing that works.

>> sorry that i tell you this, but in my opinion there are to much 
>> plugins and features in this wiki but the base and the usefull 
>> plugins are to buggy to use them at all. you should first fix bugs in 
>> the base system before makeing anything else. i read about new 
>> features and themes but the really usefull things are not present or 
>> do nut function correct.
>
> The current bug list is pretty empty.
> I only have some outstanding php5 and apache2/IIS issues.
> See my TODO list which I mailed 2004-12-04.
> Subject: "browse page and plugin/WikiAdminSelect.php show different ..."
>
>> -Rightmanagement
>
> There are only outstanding issues with http auth.

see problem bevor. did'nt meen user auth

>> -Changing a lot of pages with sql and update cached versions
>
> This has to be done. Some changes are still pending.
> The original architecture was okay for big servers and small wikis:
> < 500 pages.
> I have to fine-tune the caching system now,
>   too much wasted memory <=> too much unneeded db queries.
> You reported 2 Gig RAM for a big request. This must be fixed.


Yes i know it is fixed ! Very very good job! The wiki is very fast also 
thank you

I often have to change 4000 pages at once. This can be done making an 
sql to change all pages in the "version" table.
But it's useless because the "page" table  always do have the unchanged 
versions until i open and save every page again.
To clear the cache is useless. i have to rebuild the hole "page" table 
again but how?

>> -Backlinks did'nt work when link is part of a plugin
>
>
> This is an architectural problem. Links created by plugins must be 
> known at save-time and are only saved at save-time.
> We don't want such dynamic WikiDB hooks yet. It will cost more time 
> and more memory with little benefits.
>
> Most plugins are simple and just store normal pages, which are of 
> course correctly backlinked.
> The only exceptions are Calendar and CalendarList, and I fixed a part 
> of the problem yesterday.

RichTable Plugin

Page Test1

<?plugin RichTable
*border=0, cellpadding=1, bgcolor=#ffffff, align=center, width=99%
-
|[OtherPage]
?>

when you save this page the link [OtherPage] is known. If you to page 
OtherPage ans press backlinks, the page Test1 is not shown in the backlinks.

>> -Seperate database for auth and data (only partially there)
>
> This is fully implemented.

the prefs tables has to be at the same db as the auth table. Maybe 
sometimes usefull but not when verifying against an external userstore.

>
>> -HTML Dump stops when plugin needs to much time
>
> Thanks for the report. We will extend the timeout to 20 secs per page. 
> and not 240 secs per request.
>
>> -Users homedir is always his userid why there is no subpage like 
>> /users/userid to move them from root
>
>
> Sorry, we will not be able to fulfill this feature request until the 
> next major release. You can hack it by yourself. It will be very easy.

You are right this is a feature with less priority
Can you tell me where i have to change it? I've tried it but im not so 
familiar with the code nad it would be a good feature for the users.

Thanks for your help and information, sometimes it's to much to do for a 
lone <se?p=/Mn4k.&search=lone> fighter <se?p=/Mn4k.&search=fighter>.

Regards Stefan

[Phpwiki-talk] Converting from gdbm to mysql

[Earnie B. <ea...@us...>]

Anyone on this list have any words of wisdom?


Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

Re: [Phpwiki-talk] can't unlock pages in CVS build and much more

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

Stefan schrieb:
> in the cvs version it is not possible to unlock pages.

I already said that current pagadata cache is unstable and needs some 
more days to stabilize. This was also reported three days ago by Charles 
Corrigan.

> I've also tried to use the acl to set page permissions. does anyone know 
> how to handle this tool? i can change what i want but nothing really 
> happens. the right managment is much to difficult and buggy to use it.

I see no other bugs than the current pagadata cache problem. I'd be 
happy to receive bugreports.

> sorry that i tell you this, but in my opinion there are to much plugins 
> and features in this wiki but the base and the usefull plugins are to 
> buggy to use them at all. you should first fix bugs in the base system 
> before makeing anything else. i read about new features and themes but 
> the really usefull things are not present or do nut function correct.

The current bug list is pretty empty.
I only have some outstanding php5 and apache2/IIS issues.
See my TODO list which I mailed 2004-12-04.
Subject: "browse page and plugin/WikiAdminSelect.php show different ..."

> -Rightmanagement

There are only outstanding issues with http auth.

> -Changing a lot of pages with sql and update cached versions

This has to be done. Some changes are still pending.
The original architecture was okay for big servers and small wikis:
< 500 pages.
I have to fine-tune the caching system now,
   too much wasted memory <=> too much unneeded db queries.

You reported 2 Gig RAM for a big request. This must be fixed.

> -Backlinks did'nt work when link is part of a plugin

This is an architectural problem. Links created by plugins must be known 
at save-time and are only saved at save-time.
We don't want such dynamic WikiDB hooks yet. It will cost more time and 
more memory with little benefits.

Most plugins are simple and just store normal pages, which are of course 
correctly backlinked.
The only exceptions are Calendar and CalendarList, and I fixed a part of 
the problem yesterday.

> -Seperate database for auth and data (only partially there)

This is fully implemented.

> -HTML Dump stops when plugin needs to much time

Thanks for the report. We will extend the timeout to 20 secs per page. 
and not 240 secs per request.

> -Users homedir is always his userid why there is no subpage like 
> /users/userid to move them from root

Sorry, we will not be able to fulfill this feature request until the 
next major release. You can hack it by yourself. It will be very easy.

> -and a lot more ....
> 
> don't missunderstand me please, i like this wiki, but i use it in a 
> production environment with more than 400 registred Users and there it 
> should be rock solid. I have to decide where to go in the future use a 
> slow good featured system like wikipedia does or the faster one  like 
> phpwiki .
> i really did'nt like to change !!!
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Plugins Executed Twice, Displayed Only Once?

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

Bingo. I spotted it late yesterday evening when trying to figure out  
what PageType was for. My fork already had some of those lines moved  
around (I added If-Modified-Since checking near those bits and return  
"not modified"), but that was basically it.

Which would definitely place my fork as  
1.3.7-plus-bits-of-other-versions-on-steroids :)

If only it wasn't running for two years like this (sigh). Well, at  
least my other optimizations work even faster now :)

R.

On Dec 7, 2004, at 1:33, Carsten Klapp wrote:

>
> On Dec 6, 2004, at 6:28 am, Rui Carmo wrote:
>
>> Hello there.
>>
>> I'm running a heavily customized version of PhpWiki at  
>> http://the.taoofmac.com, and have come up with an interesting  
>> problem.
>>
>> It might be from my tweaks (I forked my code from PhpWiki sometime  
>> around 1.3.7, I think), but plugins in the node contents seem to be  
>> invoked twice, i.e:
>>
>> * if I use PageTrails as part of browse.tmpl, it is only invoked once
>> * If I add <?plugin PageTrails ?> to my Sandbox, the plugin code  
>> (i.e., run()) gets invoked twice, even though the output is only  
>> shown once.
>
> Hi Rui,
>
> This sounds exactly like the "double transformation" bug which I  
> (inadvertently introduced, and later) fixed around 1.3.7.
>
> I think you may find the answer here, by comparing an old revision of  
> PageType.php with the one before it:
>
> http://cvs.sourceforge.net/viewcvs.py/phpwiki/phpwiki/lib/ 
> PageType.php?r1=1.9&r2=1.10
>
> IIRC normally you wouldn't notice the double transformation, except on  
> pages which contain plugins, so I'm quite sure this is it.
>
> I haven't had time to work on PhpWiki in almost a year but I do  
> periodically monitor this list and thought I could help in this case.  
> If this does not turn out to be the cause of the problem, I'm sorry  
> then, offhand I don't know what else to try as I am quite out of date  
> with the current code.
>
> Carsten

Re: [Phpwiki-talk] newest version to install?

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

Helmer Pardun schrieb:
> Hi my name is Helmer Pardun and I've worked with phpwiki now one year
> ago with the good helping hands of carsten klapp. Meanwihle, working on
> cms more or less, I lost contact to php wiki and Carsten. Could anyone
> please give me a hint, where to download the latest version to newly
> install php wiki.

At http://phpwiki.org/ (link to the sf.net site) are the links to the 
latest releases and to fresh CVS.

CVS WikiDB is just in being refactored, which will be finished in about 
two days. It works, but some major changes will still come.
(remove a page, improved pagedata cache, improved versiondata cache).

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

Re: [Phpwiki-talk] Re: Big security problem in phpWiki?

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

Carsten Klapp schrieb:
> A possible security issue with PhpWiki, please see what you can do to help.

> On Dec 6, 2004, at 6:03 am, Santtu Jarvi wrote:
>> I tried the phpWiki but noticed that I was able to load files
>> with an anonymous account. With this function I was able to
>> load critical files into the wiki for everyone to see.
>>
>> I noticed this on my own webserver and thought that it was
>> only some misconfiguration somewhere.. but it can be done
>> even at the phpWiki that is on display at sourceforge.
>>
>> Simply loading 'config/config.ini' from the load local file function
>> in the administration panel gives you access to the config.ini
>> file with all server configuration and admin password. All this
>> can be done with a normal anonymous account.

Ah, it was you.
I saw that page and the security problem, but then sf.net died before I 
could fix it. Thanks a lot!

we'll change the passwords also.

>> I didn't expect this kind of thing to work but it worked at the
>> test site. It would be better to delete the page from there at
>> once.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] can't unlock pages in CVS build and much more

[Stefan <son...@ba...>]

Hello,

in the cvs version it is not possible to unlock pages.

I've also tried to use the acl to set page permissions. does anyone know 
how to handle this tool? i can change what i want but nothing really 
happens. the right managment is much to difficult and buggy to use it.

sorry that i tell you this, but in my opinion there are to much plugins 
and features in this wiki but the base and the usefull plugins are to 
buggy to use them at all. you should first fix bugs in the base system 
before makeing anything else. i read about new features and themes but 
the really usefull things are not present or do nut function correct.

-Rightmanagement
-Changing a lot of pages with sql and update cached versions
-Backlinks did'nt work when link is part of a plugin
-Seperate database for auth and data (only partially there)
-HTML Dump stops when plugin needs to much time
-Users homedir is always his userid why there is no subpage like 
/users/userid to move them from root
-and a lot more ....

don't missunderstand me please, i like this wiki, but i use it in a 
production environment with more than 400 registred Users and there it 
should be rock solid. I have to decide where to go in the future use a 
slow good featured system like wikipedia does or the faster one  like 
phpwiki .
i really did'nt like to change !!!

Regards Stefan


 

[Phpwiki-talk] Authority management

[Manuel V. <man...@st...>]

Hi all,

I've a question of right management (v1.3.10).
I disabled anno users and I only have level 2 users. But these users 
have some admin rights such as restoring Wiki.

I trace the requiredAuthority function in main.php and I found this line:
$auth = $this->requiredAuthorityForAction($action);
if (!ALLOW_ANON_USER) return WIKIAUTH_USER;

I think it should be:
$auth = $this->requiredAuthorityForAction($action);
if (!ALLOW_ANON_USER && $auth < WIKIAUTH_USER) return WIKIAUTH_USER;

... or not?


-- 
# VACELET Manuel     manuel.vacelet-abecedaire(at)st(dot)com #
# Tel:  042 6089                          +33 (0)476 92 6089 #
# STMicroelectronics  - Central R&D DAIS - Flexware          #
# 850, rue Jean Monet - 38926 CROLLES CEDEX - FRANCE         #

[Phpwiki-talk] newest version to install?

[Helmer P. <red...@ge...>]

Hi my name is Helmer Pardun and I've worked with phpwiki now one year
ago with the good helping hands of carsten klapp. Meanwihle, working on
cms more or less, I lost contact to php wiki and Carsten. Could anyone
please give me a hint, where to download the latest version to newly
install php wiki.

Thanks a lot 

Helmer from Dresden

[Phpwiki-talk] Installation problem: blank page

[Jay D. <sun...@ve...>]

Hi everyone,

I'm trying to install phpwiki 1.2.5, but I'm getting a blank page for
index.php.

I'm hosting my site through Dreamhost, which I believe uses Debian
Linux/Apache.

Approaches I've tried:

1. I tried (as the installation instructions suggested) editing the file
lib/config.php and changing the setting for DBM_FILE_TYPE from "gdbm" to
"db3", but it had no effect -- still blank.
=20
2. In lib/dbalib.php, I deleted the '@' in front of the call to =
dba_open().
I got the following error: "Fatal error: Call to undefined function:
dba_open() in
/home/.quentin/sugarmountain/jaydixit.org/phpwiki/lib/dbalib.php on line =
54"

I've looked at all the documentation I can find, but I can't figure it =
out.
I have an account at Dreamhost, and I even found a whole Dremahost forum =
of
people experiencing the same problem --
http://discussion.dreamhost.com/showflat.pl?Cat=3D&Board=3D3rdparty&Numbe=
r=3D14058
&page=3D0&view=3Dcollapsed&sb=3D5&o=3D14&part=3D -- but nobody on the =
forum had any
solutions.

Many thanks if you have any ideas or can direct me to someone who can.

Best,
Sunjay Dixit

Re: [Phpwiki-talk] Problem with database files?

[Mike A. <mik...@gm...>]

Hmmmm..... the problem now seems to have fixed itself.

Perhaps they forgot to install a library for a short while?

Thanks for your help,

  Mike.


On Mon, 06 Dec 2004 17:55:09 +0100, Reini Urban <ru...@x-...> wrote:
> Mike Anderson schrieb:
> 
> 
> > Hello Everyone,
> >
> > I've just run into a problem using phpwiki on sourceforge that I can't
> > figure out how to solve. It was working fine for several weeks, but
> > now all I get is:
> >
> >
> > Warning: Variable passed to each() is not an array or object in
> > /var/local/home/groups/t/ty/tyrant/htdocs/phpwiki/lib/dbalib.php on
> > line 76
> >
> > WikiFatalError
> > Cannot open database 'wiki' : 'pages3/wikipagesdb', giving up.
> >
> > Any ideas? As far as I can see, I didn't take any specific action that
> > triggered this problem. Running a pretty standard installation.
> 
> This must be the new fc1 php. (sf.net webserver upgrade)
> Maybe upgrading to phpwiki-1.2.5 will help but I'm not sure that.
> I will need some time to check that.
> ( I tested phpwiki-1.2.5 against php-4.3.9, not 4.3.8 )
> --
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>

[Phpwiki-talk] Re: Big security problem in phpWiki?

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

A possible security issue with PhpWiki, please see what you can do to 
help.

Many thanks,
Carsten Klapp

On Dec 6, 2004, at 6:03 am, Santtu Jarvi wrote:

> Dear Carsten Klapp,
>
> I tried the phpWiki but noticed that I was able to load files
> with an anonymous account. With this function I was able to
> load critical files into the wiki for everyone to see.
>
> I noticed this on my own webserver and thought that it was
> only some misconfiguration somewhere.. but it can be done
> even at the phpWiki that is on display at sourceforge.
>
> Simply loading 'config/config.ini' from the load local file function
> in the administration panel gives you access to the config.ini
> file with all server configuration and admin password. All this
> can be done with a normal anonymous account.
>
> I didn't expect this kind of thing to work but it worked at the
> test site. It would be better to delete the page from there at
> once.
>
> Respectfully,
> Santtu Jarvi


Hi Santtu,

I am forwarding your message to the phpwiki-talk mailing list, someone 
there should be able to help.

Although I periodically monitor the phpwiki-talk list I have not had 
time to work on PhpWiki in almost a year, so I am not versed at all 
with the current code-base (i.e. There were not even any .ini files 
last time I worked on PhpWiki).

Thanks for reporting your problem, I have confidence in those who are 
currently working on PhpWiki. :) In the future you are better off 
sending an email to the phpwiki-talk mailing list for assistance rather 
than contacting one of developers directly. :) 
http://sourceforge.net/mail/?group_id=6121

Best of luck,
Carsten

Re: [Phpwiki-talk] Plugins Executed Twice, Displayed Only Once?

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

On Dec 6, 2004, at 6:28 am, Rui Carmo wrote:

> Hello there.
>
> I'm running a heavily customized version of PhpWiki at  
> http://the.taoofmac.com, and have come up with an interesting problem.
>
> It might be from my tweaks (I forked my code from PhpWiki sometime  
> around 1.3.7, I think), but plugins in the node contents seem to be  
> invoked twice, i.e:
>
> * if I use PageTrails as part of browse.tmpl, it is only invoked once
> * If I add <?plugin PageTrails ?> to my Sandbox, the plugin code  
> (i.e., run()) gets invoked twice, even though the output is only shown  
> once.

Hi Rui,

This sounds exactly like the "double transformation" bug which I  
(inadvertently introduced, and later) fixed around 1.3.7.

I think you may find the answer here, by comparing an old revision of  
PageType.php with the one before it:

http://cvs.sourceforge.net/viewcvs.py/phpwiki/phpwiki/lib/PageType.php? 
r1=1.9&r2=1.10

IIRC normally you wouldn't notice the double transformation, except on  
pages which contain plugins, so I'm quite sure this is it.

I haven't had time to work on PhpWiki in almost a year but I do  
periodically monitor this list and thought I could help in this case.  
If this does not turn out to be the cause of the problem, I'm sorry  
then, offhand I don't know what else to try as I am quite out of date  
with the current code.

Carsten

Re: [Phpwiki-talk] Plugins Executed Twice, Displayed Only Once?

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

On Dec 6, 2004, at 8:02 PM, Reini Urban wrote:

> Rui Carmo schrieb:
>>
>
> Ah okay. I'll probably use just your blog theme then. And some 
> js-buttons here and there.

I'll send you SeeAlso and some of the other stuff for inclusion, 
though. Lots of people seem to like that ;)

>
> Ah I forget to wrote that, sorry.
>
> The only and main is in CachedMarkup.php:
>   Cached_PluginInvocation::expand()
> This is where you must put your debugprint statement.
> expand() is called recursively through the HTML parse tree.
>
> The expander for the Cached_PluginInvocation class is
> a normal printExpansion() call.
>

Many thanks. I'll look into it after I rsync a copy to my local machine 
to try to get better debugging.

R.

Re: [Phpwiki-talk] Plugins Executed Twice, Displayed Only Once?

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

Rui Carmo schrieb:
> On Dec 6, 2004, at 5:15 PM, Reini Urban wrote:
>> Rui Carmo schrieb:
>>
>>> I'm running a heavily customized version of PhpWiki at 
>>> http://the.taoofmac.com, and have come up with an interesting problem.
>>
>> This blog theme is exactly what I wanted to have also, but didn't had 
>> time yet. Very good work!
> 
> Thanks. It's a bit crufty around the edges (the edit template is still 
> broken, for instance), but it does the job for visitors.
> 
>>> It might be from my tweaks (I forked my code from PhpWiki sometime 
>>> around 1.3.7, I think), but plugins in the node contents seem to be 
>>> invoked twice, i.e:
>>> * if I use PageTrails as part of browse.tmpl, it is only invoked once
>>> * If I add <?plugin PageTrails ?> to my Sandbox, the plugin code 
>>> (i.e., run()) gets invoked twice, even though the output is only 
>>> shown once.
>>
>> If you have a plugin in a template it is invoced from there also, but 
>> no normal template should be processed twice.
>>
>>> This is tolerable for simple stuff like PageTrails, but a _major_ 
>>> nuisance for TitleSearch and whatnot (which is what I'm trying to 
>>> optimize).
>>> I'm blaming it on template expansion (which I haven't modified myself 
>>> and might have a few lingering bugs not present in current CVS), but 
>>> instead of upgrading (which would mean refactoring all my current 
>>> custom plugins and subpage handling) what I would _really_ like are 
>>> some pointers as to how to go about debugging this, namely:
>>
>>
>> I'll do the work and merge some of your stuff to our version as
>> another theme, ok? Our WikiBlog template smells awful.
>> Also an example how to add google ads to some sidebar is useful for 
>> some theme.
>> Do you have a tarball of your changes and the Kubrick theme somewhere 
>> to download?
> 
> No, there is no change tarball available. And the reason for that is 
> that I've basically butchered the code over the last two years to remove 
> PhpWiki features I don't like nor need (like multiple user support, 
> subpage handling, etc.).
> 
> So it's not really just a set of changes - I've edited just about 
> everything from the database driver to the block parser, and admittedly 
> not in a very elegant way. I also have a faint recollection of changing 
> the database schema, although I will probably do it again soon to store 
> post titles in a separate field upon page creation (saves me a lot of 
> trouble to generate the Alphabetical Index, searching, etc.) and add a 
> node creation date that stays put and doesn't get flushed away with 
> older revisions (which would help my Atom feed).
> 
> Not to mention a number of hard-coded regexps in the middle of the code 
> to block spam referrers and other niceties of the open Internet...
> 
> Actually, most of the stuff you see (the Kubrick theme, the ads, etc.) 
> is really _trivial_ to do - the real work is in the plugins and CSS, and 
> that isn't even halfway done yet (if you look at the CSS you'll still 
> see two different markup styles, mine and Michael's, that I haven't yet 
> merged). Adding the base theme took me all of two hours, most of it 
> spent moving CSS and images around, and Adsense takes all of two minutes.
> 
> Plus, it's not just PhpWiki anymore. I don't use any of the WikiBlog 
> stuff (as I recall, it was based on UnfoldSubPages), I rely on a 
> hardcoded blog/ prefix. There are also a couple of other things inside 
> (although I haven't re-themed them all yet), and releasing the sources 
> generally would mean I be expected to provide support and fix bugs for 
> other people, so I don't do it wholesale - I just throw a copy of my 
> plugins to whomever asks and make it plain that they're on their own. :)
> 
> I could try to isolate some of the bits that are my code and send you a 
> tarball, though. _After_ I fix the plugin calls.

Ah okay. I'll probably use just your blog theme then. And some 
js-buttons here and there.

>> I was also working today on more radio userland features, like RSS2 
>> and cloud support (pagechange notification via xml-rpc).
>> The atom format not yet, but you already have that.
> 
> Oh yes, I hacked a copy of RssWriter and added a new formatter to 
> RecentChanges. It does, however, rely on a lot of the internal caching 
> stuff I also added (to check If-Modified-Since headers), and almost 
> completely breaks your coding conventions :)
> 
>> Trackback is missing but almost the same.
> 
> I don't do trackback or comments - it's a free JavaScript add-on from 
> HaloScan.com (I don't want to bother with dealing with comment spam, and 
> I only added comments at all as an experiment).
> 
>>> * In which conditions are plugins expanded
>>
>> On every invocation only once :)
> 
> And, returning to my original question, where does that happen in the 
> code? The only thing I haven't done so far is to sanitize the templates 
> themselves to see if I've created some sort of loop...
> 
>>> * if dump_template() is useful for debugging that (the initial 
>>> results aren't satisfactory, but I might have missed something)
>>> I'm currently trying to wrap my neurons around printExpansion(), 
>>> which is what I see getting called more often. I would have used 
>>> PHP's call stack debugger if I could, but have to resort to browser 
>>> output and file logging, so it's tough going (some sort of call graph 
>>> for page generation would also be nice, since it is nigh on 
>>> impossible to just use error_log() with all the built-in error 
>>> handling mechanisms).
>>
>> Don't you have a GUI php debugger?
> 
> No. I have to access the machine via SSH and I don't know of any free 
> ones that run on Macs (or decent ones that I can run on Linux), so I 
> would really appreciate some pointers to where plugin invocation happens 
> in the source code and/or how to disable _all_ the extra error handling 
> so I can simply place a few calls here and there and see the output in 
> the system log...

Ah I forget to wrote that, sorry.

The only and main is in CachedMarkup.php:
   Cached_PluginInvocation::expand()
This is where you must put your debugprint statement.
expand() is called recursively through the HTML parse tree.

The expander for the Cached_PluginInvocation class is
a normal printExpansion() call.

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