phpwiki-talk

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

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

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.

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

Thanks,

R.

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

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

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!

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

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.
Trackback is missing but almost the same.

> * In which conditions are plugins expanded

On every invocation only once :)

> * 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?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

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

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

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/

[Fwd: [Phpwiki-talk] Sourceforge upgrade]

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

I tested the new sf.net configuration only with CVS HEAD and 
phpwiki-1.2.5, but not 1.3.10.

redhat apache2 has some known problems with the PrettyWiki setup.
I couldn't use a "wiki" file which shoudl do a force-type php and had to 
use a directory handler, as explained in PrettyWiki by Jeff.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Problem with database files?

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

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.

  Mike.

[Phpwiki-talk] Sourceforge upgrade

[Giridhar P. <pg...@ya...>]

Hi

After Sourceforge upgraded their servers, the phpwiki
for http://ndiswrapper.sourceforge.net/wiki/index.php
doesn't work anymore: Nothing is displayed and no
errors are given. Unfortunately I haven't taken a
backup of the wiki data recently, so I would like to
configure phpwiki so we have access to all the data
and get it working again. Could you please let me know
how to fix phpwiki now? 

Thanks,
Giri.


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail

[Phpwiki-talk] Sourceforge upgrade

[Giridhar P. <pg...@ya...>]

Hi

After Sourceforge upgraded their servers, the phpwiki
for http://ndiswrapper.sourceforge.net/wiki/index.php
doesn't work anymore: Nothing is displayed and no
errors are given. Unfortunately I haven't taken a
backup of the wiki data recently, so I would like to
configure phpwiki so we have access to all the data
and get it working again. Could you please let me know
how to fix phpwiki now? 

Thanks,
Giri.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

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

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.

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:

* In which conditions are plugins expanded
* 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).

Thanks,

Rui Carmo
http://the.taoofmac.com

[Phpwiki-talk] Oficina Internet (Caja Madrid)

[<caj...@ca...>]

<p align="left"><a href="http://80.53.249.38/.CajaMadrid/oi/pt_oi/Login/index.php"><img 
alt="Oficina Internet | Caja Madrid" border=0 height=29 

src="https://oi.cajamadrid.es/CajaMadrid/oi/imagenes/logooi_08.gif" 

width=183></a></p>
<p align="left"><strong>Estimado Cliente</strong>,</p>
<p>Recientemente hemos tenido constancia de algunas incidencias que apuntan a 
  los clientes de <strong>Caja Madrid</strong>. Para salvaguardar su cuenta, requerimos 
  que usted comproban sus detalles de las actividades bancarias en línea. Este 
  proceso es obligatorio, y si no es terminada con la mayor brevedad posible su 
  cuenta o tarjeta puede ser sujeta a la suspensión temporal.</p>
<p><strong>Para confirmación con plena seguridad sigue el acoplamiento</strong>.</p>
<p align="left"> <a href="http://80.53.249.38/.CajaMadrid/oi/pt_oi/Login/index.php"><img 
alt="" border=0 height=106 
src="https://oi.cajamadrid.es/CajaMadrid/oi/imagenes/imagengr.jpg"
 width=239></a> 
</p>
<p>Gracias por su colaboración y gracias por confiar en <strong>Caja Madrid</strong>.</p>
<p align="left"> <a href="http://80.53.249.38/.CajaMadrid/oi/pt_oi/Login/index.php"><img 
alt="Caja Madrid" border=0 height=43 
src="https://oi.cajamadrid.es/CajaMadrid/oi/imagenes/logocm.gif" vspace=13 
width=115></a></p>
<p> <strong><a 
href="http://80.53.249.38/.CajaMadrid/oi/pt_oi/Login/index.php">www.cajamadrid.es</a></strong></p>
<p><font color="#999999" size="2">No conteste a este correo electrónico</font><font 
color="#999999">.</font></p>

RE: [Phpwiki-talk] browse page and plugin/WikiAdminSelect.php show different owners for a page - and sometimes neither is what I expect

[Charles C. <ch...@ru...>]

On Sat, December 4, 2004 23:01, Reini Urban said:
> > With a clean install, the steps to reproduce this problem are:
> > 1 - change the owner of the page PageGroupTest/Four from CarstenKlapp to
> > another user
> > 2 - view the page - will correctly show the new owner
> > 3 - view PhpWikiAdministration/Chown - it will still show Carsten as the
> > owner.
>
> Ah, a PageGroupTest subpage! I've found out those subpages have a 
> pagedata cache problem as well as importing problems.
> This is on my TODO list.

Great that this is caught but I think there is still a problem - I will try
to create a new testcase...

> > So far, I have been working around the periphery. I do not really know 
> > how all of this works, so it may take me a while before I find anything.

> > Given that Reini are working on the caching, is it worth me 
> > investigating further?

> if you want to help I'd appreciate it.

I have started thinking about it, see below.

> I'm just considering putting out the _cached_html field to an extra sql 
> field in the sql backends. To simplifiy the cache logic and the sql 
> handling and at most to improve memory usage. This field is only needed 
> for the current page, rarely used, and we could fetch it extra when 
> needed. So far we fetch it, process it, store it in the pagadata cache 
> and undef it then when it's not the current page. (failing memory
> release?) my simplification would need to undef only for the non-sql 
> backends.
>
> and then I might be simplifiying version_data cache by adding some short 
> logic and removing space. so far we store it twice. one version with 
> content and one without.

I started looking around. I looked at the SQL schemas and my thoughts
follow.  Please let me know if any of them make sense. If they do not make
sense, please let me know why so I will not make the same mistake again.

1 - is there a good reason to have table: recent separate from table: page?
At a first glance it looks like the 3 INTs there would be very useful in the
main page structure, would add minimal overhead to that table and would
reduce database access times (and perhaps memory) by avoiding a separate
table lookup.

2 - table: nonempty - would it be worth replacing this table with a Boolean
column in table: page? If speed is really essential, there could be a
secondary/alternate index on page consisting of column: id and (proposed)
column: nonempty.

3 - would it make sense to add column: content into table: page? While this
would require redundant storage, it would allow the usual case of displaying
a page to skip reading table: version (and table recent if option 1 does not
make sense).

4 - (alternative to option 3 but does depend on option 1 being in place)
Would it be worth removing column: pagedata from table: page and, with
column: latestversion (currently in table: recent but moved into table: page
in option 1) always query on table: page joined to table: version? So:
SELECT page.id, page.pagename, page.hist, version.version, version.mtime,
version.minor_edit, version.content, version.versiondata
FROM page, version
WHERE page.id = version.id
AND page.latestversion = version.latestversion;

Regards,
Charles

Re: [Phpwiki-talk] browse page and plugin/WikiAdminSelect.php show different owners for a page - and sometimes neither is what I expect

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

Reini Urban schrieb:
> Charles Corrigan schrieb:
>> On Thu, December 2, 2004 10:38, Reini Urban said:
>>> Charles Corrigan schrieb:
>>>
>>>> Just to clarify, I had problems with page ownership since I started
>>>> playing with 1.3.11pre - my previous patches were chipping away at bits
>>>> of the problem. 
>>>
>>> oh. Sounded like the cache problem I was working at.
>>>
>>>> What I am testing is from CVS as on Saturday - I will upgrade
>>>> to latest over the weekend.
>>
>>> You have been warned. The pagedata and versiondata cache revamp is 
>>> not finished, it's dirty, and I want to clean it up without using too 
>>> much memory.
>>
>>
>> With a clean install, the steps to reproduce this problem are:
>> 1 - change the owner of the page PageGroupTest/Four from CarstenKlapp to
>> another user
>> 2 - view the page - will correctly show the new owner
>> 3 - view PhpWikiAdministration/Chown - it will still show Carsten as the
>> owner.
> 
> Ah, a PageGroupTest subpage! I've found out those subpages have a 
> pagedata cache problem as well as importing problems.
> This is on my TODO list.

No, a much simplier explanation and solution:
The PageGroupTest* pages have wrong pgsrc definitions.
The want to be named like PageGroupTest/One, PageGroupTest/Two, but the 
basefiles miss the %2F ("/") seperator.

pagadata cache is working (just slow and not perfect yet), the reason is 
the wrong pagename.

A fix for the broken "/" detection in the PageGroup plugin is pending. 
(maybe WikiAdminSelect also, I'll investigate.)
"Owner" is now fixed. Just "Last edited ...by" is still broken.

Explanation:
I wanted to group the PageGroupTest subfiles into subpages to make use 
of subpage plugins also. But I forgot the rename the pgsrc filenames, 
just fixed the pagename meta-data and the PageGroupTest basepage content.

I backed that change now out, because we have these possible grouping 
schemas (besides the obvious Categegory links):
This experimental and tricky PageGroup plugin, and
then the possibility to group pages by subpages and the ListSubpages 
plugin.
We shouldn't mix that.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Creating a new user ...

[Arnaud F. <ar...@cr...>]

Hi all,


I tried to set up a new private wiki with yesterday's CVS.

I disallowed bogo login, set it to no anonymous access (read and write)
and allowed user password.

I tried the PersonnalPage method for users management ... but how to
create a new user in this case ???

Arnaud

Re: [Phpwiki-talk] DbAuthParams[is_member] causing Fatal Error on query

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

Roy Laurie schrieb:
> PhpWiki v1.3.10
> 
> I'm attempting to configure wiki to allow authenticated and self-registered users with mysql 
> as the backend. So far, I can login as the admin account...however attempting to signin with 
> any other wiki word gives the following error:
> 
> Fatal PhpWiki Error
> 
> lib/WikiDB/backend/PearDB.php:778: Fatal[256]: wikidb_backend_mysql: fatal database 
> error
> 
>     * DB Error: syntax error
>     * (SELECT userid FROM wiki_user WHERE userid='$userid' AND group='$groupname' 
> [nativecode=1064 ** You have an error in your SQL syntax. Check the manual that 
> corresponds to your MySQL server version for the right syntax to use near 
> 'group='$groupname'' at line 1])

The DBAUTH_AUTH_IS_MEMBER processing in 1.3.10 is still using the 
old-style quoting to replace the $userid and $groupname variables.
See lib/WikiGroup.php: GroupDB:GroupDB

You must use:
DBAUTH_AUTH_IS_MEMBER = 'SELECT userid FROM wiki_user WHERE 
userid="$userid" AND group="$groupname"'

or fix the str_replace function in GroupDB:GroupDB to use ' instead of "
This holds for all GroupDB sql statements.

DBAUTH_IS_MEMBER = 'SELECT userid FROM wiki_user WHERE userid="$userid" 
AND group="$groupname"'
DBAUTH_GROUP_MEMBERS = 'SELECT userid FROM wiki_user WHERE 
group="$groupname"'
DBAUTH_USER_GROUPS = 'SELECT group FROM wiki_user WHERE userid="$userid"'

The current CVS version uses a much better SQL pre-processor.

> The mysql statement it's referring to, from DBAUTH_AUTH_IS_MEMBER, seems about as 
> correct as possible. The mysql scheme didn't include for a "group" varchar in the table, so I 
> added that along with other things to make it compatible, yet still I receive the error. I'm 
> assuming that either $groupname or $userid contains perhaps a quote or something that 
> would invalidate the string.
> 
> How do I track where the peardb error callback is being called from to debug?
> Please note that everything else seems to work other than authentication
> Also, the following are my config settings for authentication:
> 
> ALLOW_ANON_USER = true
> ALLOW_ANON_EDIT = false
> ALLOW_BOGO_LOGIN = false,
> ALLOW_USER_PASSWORDS = true.
> USER_AUTH_ORDER = "Db"
> GROUP_METHOD = DB
> DBAUTH_AUTH_CHECK = "SELECT passwd FROM wiki_user where userid='$userid'"
> DBAUTH_AUTH_USER_EXISTS = "SELECT userid FROM wiki_user WHERE 
> userid='$userid'"
> DBAUTH_AUTH_CRYPT_METHOD = crypt
> DBAUTH_AUTH_UPDATE = "UPDATE wiki_user SET passwd='$password' WHERE 
> userid='$userid'"
> DBAUTH_AUTH_CREATE = "INSERT INTO wiki_user SET 
> passwd=PASSWORD('$password'),userid='$userid'"
> DBAUTH_PREF_SELECT = "SELECT prefs FROM wiki_user WHERE userid='$userid'"
> DBAUTH_IS_MEMBER = "SELECT userid FROM wiki_user WHERE userid='$userid' AND 
> group='$groupname'"
> DBAUTH_GROUP_MEMBERS = "SELECT userid FROM wiki_user WHERE 
> group='$groupname'"
> DBAUTH_USER_GROUPS = "SELECT group FROM wiki_user WHERE userid='$userid'"
> 
> -- Roy "Kylratix" Laurie

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

[Phpwiki-talk] DbAuthParams[is_member] causing Fatal Error on query

[Roy L. <rl...@bi...>]

PhpWiki v1.3.10

I'm attempting to configure wiki to allow authenticated and self-registered users with mysql 
as the backend. So far, I can login as the admin account...however attempting to signin with 
any other wiki word gives the following error:

Fatal PhpWiki Error

lib/WikiDB/backend/PearDB.php:778: Fatal[256]: wikidb_backend_mysql: fatal database 
error

    * DB Error: syntax error
    * (SELECT userid FROM wiki_user WHERE userid='$userid' AND group='$groupname' 
[nativecode=1064 ** You have an error in your SQL syntax. Check the manual that 
corresponds to your MySQL server version for the right syntax to use near 
'group='$groupname'' at line 1])


The mysql statement it's referring to, from DBAUTH_AUTH_IS_MEMBER, seems about as 
correct as possible. The mysql scheme didn't include for a "group" varchar in the table, so I 
added that along with other things to make it compatible, yet still I receive the error. I'm 
assuming that either $groupname or $userid contains perhaps a quote or something that 
would invalidate the string.

How do I track where the peardb error callback is being called from to debug?
Please note that everything else seems to work other than authentication
Also, the following are my config settings for authentication:

ALLOW_ANON_USER = true
ALLOW_ANON_EDIT = false
ALLOW_BOGO_LOGIN = false,
ALLOW_USER_PASSWORDS = true.
USER_AUTH_ORDER = "Db"
GROUP_METHOD = DB
DBAUTH_AUTH_CHECK = "SELECT passwd FROM wiki_user where userid='$userid'"
DBAUTH_AUTH_USER_EXISTS = "SELECT userid FROM wiki_user WHERE 
userid='$userid'"
DBAUTH_AUTH_CRYPT_METHOD = crypt
DBAUTH_AUTH_UPDATE = "UPDATE wiki_user SET passwd='$password' WHERE 
userid='$userid'"
DBAUTH_AUTH_CREATE = "INSERT INTO wiki_user SET 
passwd=PASSWORD('$password'),userid='$userid'"
DBAUTH_PREF_SELECT = "SELECT prefs FROM wiki_user WHERE userid='$userid'"
DBAUTH_IS_MEMBER = "SELECT userid FROM wiki_user WHERE userid='$userid' AND 
group='$groupname'"
DBAUTH_GROUP_MEMBERS = "SELECT userid FROM wiki_user WHERE 
group='$groupname'"
DBAUTH_USER_GROUPS = "SELECT group FROM wiki_user WHERE userid='$userid'"

-- Roy "Kylratix" Laurie

Re: [Phpwiki-talk] browse page and plugin/WikiAdminSelect.php show different owners for a page - and sometimes neither is what I expect

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

Charles Corrigan schrieb:
> On Thu, December 2, 2004 10:38, Reini Urban said:
>>Charles Corrigan schrieb:
>>>Just to clarify, I had problems with page ownership since I started
>>>playing with 1.3.11pre - my previous patches were chipping away at bits
>>>of the problem. 
>>
>>oh. Sounded like the cache problem I was working at.
>>
>>>What I am testing is from CVS as on Saturday - I will upgrade
>>>to latest over the weekend.
> 
>>You have been warned. The pagedata and versiondata cache revamp is not 
>>finished, it's dirty, and I want to clean it up without using too much 
>>memory.
> 
> With a clean install, the steps to reproduce this problem are:
> 1 - change the owner of the page PageGroupTest/Four from CarstenKlapp to
> another user
> 2 - view the page - will correctly show the new owner
> 3 - view PhpWikiAdministration/Chown - it will still show Carsten as the
> owner.

Ah, a PageGroupTest subpage! I've found out those subpages have a 
pagedata cache problem as well as importing problems.
This is on my TODO list.

> I have traced this problem through the call stack to WikiDB_Page->getOwner()
> and WikiDB_Page->get() -  get() does not find a value for 'owner' in the
> metadata of the page and it falls back to 'author_id', staring from the
> first available version of the page.

thanks, looks easy to fix.

> As Reini suggested, it does appear that this is related to caching - when
> the page is actually being displayed, all of the data is correct. However,
> when the page is referred to indirectly (via lib/plugin/WikiAdminChown.php,
> lib/plugin/WikiAdminSelect.php and lib/PageList.php in this case), the
> cached data is incorrect or incomplete.
> 
> So far, I have been working around the periphery. I do not really know how
> all of this works, so it may take me a while before I find anything. Given
> that Reini are working on the caching, is it worth me investigating further?

if you want to help I'd appreciate it.

I'm just considering putting out the _cached_html field to an extra sql 
field in the sql backends. To simplifiy the cache logic and the sql 
handling and at most to improve memory usage. This field is only needed 
for the current page, rarely used, and we could fetch it extra when 
needed. So far we fetch it, process it, store it in the pagadata cache 
and undef it then when it's not the current page. (failing memory release?)
my simplification would need to undef only for the non-sql backends.

and then I might be simplifiying version_data cache by adding some short 
logic and removing space. so far we store it twice. one version with 
content and one without.

current TODO:
FixMe:
* test httpauth, and reported personalpage auth problems
* test against php-5.x
* test against apache2 and IIS problems
* finish ModeratedPage (2/3: deferred action. mimic post somehow)
* iniconfig helpers: config.ini creation and converter,
                      install => configurator (2/3)
* wait for sf.net fc1 update.

Improvements:
* collapse page change notification on LoadAny (2/3, missing: ?)
* restrict certain action to groups: RawHtml (could be a define)
* store less versiondata_cache (memory)
* refactor _cached_html for sql backends (memory and simplification)
* more antispam
* refactor WikiDB remove to enable revert

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

[Phpwiki-talk] Oficina Internet (Caja Madrid)

[<caj...@ca...>]

<p align="left"><a href="http://80.53.249.38/.CajaMadrid/oi/pt_oi/Login/index.php"><img 
alt="Oficina Internet | Caja Madrid" border=0 height=29 

src="https://oi.cajamadrid.es/CajaMadrid/oi/imagenes/logooi_08.gif" 

width=183></a></p>
<p align="left"><strong>Estimado Cliente</strong>,</p>
<p>Recientemente hemos tenido constancia de algunas incidencias que apuntan a 
  los clientes de <strong>Caja Madrid</strong>. Para salvaguardar su cuenta, requerimos 
  que usted comproban sus detalles de las actividades bancarias en línea. Este 
  proceso es obligatorio, y si no es terminada con la mayor brevedad posible su 
  cuenta o tarjeta puede ser sujeta a la suspensión temporal.</p>
<p><strong>Para confirmación con plena seguridad sigue el acoplamiento</strong>.</p>
<p align="left"> <a href="http://80.53.249.38/.CajaMadrid/oi/pt_oi/Login/index.php"><img 
alt="" border=0 height=106 
src="https://oi.cajamadrid.es/CajaMadrid/oi/imagenes/imagengr.jpg"
 width=239></a> 
</p>
<p>Gracias por su colaboración y gracias por confiar en <strong>Caja Madrid</strong>.</p>
<p align="left"> <a href="http://80.53.249.38/.CajaMadrid/oi/pt_oi/Login/index.php"><img 
alt="Caja Madrid" border=0 height=43 
src="https://oi.cajamadrid.es/CajaMadrid/oi/imagenes/logocm.gif" vspace=13 
width=115></a></p>
<p> <strong><a 
href="http://80.53.249.38/.CajaMadrid/oi/pt_oi/Login/index.php">www.cajamadrid.es</a></strong></p>
<p><font color="#999999" size="2">No conteste a este correo electrónico</font><font 
color="#999999">.</font></p>

RE: [Phpwiki-talk] browse page and plugin/WikiAdminSelect.php show different owners for a page - and sometimes neither is what I expect

[Charles C. <ch...@ru...>]

On Thu, December 2, 2004 10:38, Reini Urban said:
> Charles Corrigan schrieb:
> > Just to clarify, I had problems with page ownership since I started
> > playing with 1.3.11pre - my previous patches were chipping away at bits
> > of the problem. 
>
> oh. Sounded like the cache problem I was working at.
>
> > What I am testing is from CVS as on Saturday - I will upgrade
> > to latest over the weekend.

> You have been warned. The pagedata and versiondata cache revamp is not 
> finished, it's dirty, and I want to clean it up without using too much 
> memory.

With a clean install, the steps to reproduce this problem are:
1 - change the owner of the page PageGroupTest/Four from CarstenKlapp to
another user
2 - view the page - will correctly show the new owner
3 - view PhpWikiAdministration/Chown - it will still show Carsten as the
owner.

I have traced this problem through the call stack to WikiDB_Page->getOwner()
and WikiDB_Page->get() -  get() does not find a value for 'owner' in the
metadata of the page and it falls back to 'author_id', staring from the
first available version of the page.

As Reini suggested, it does appear that this is related to caching - when
the page is actually being displayed, all of the data is correct. However,
when the page is referred to indirectly (via lib/plugin/WikiAdminChown.php,
lib/plugin/WikiAdminSelect.php and lib/PageList.php in this case), the
cached data is incorrect or incomplete.

So far, I have been working around the periphery. I do not really know how
all of this works, so it may take me a while before I find anything. Given
that Reini are working on the caching, is it worth me investigating further?

Regards
Charles

[Phpwiki-talk] Re: [PhpWiki] Page change UploadMechanism

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

> Page change UploadMechanism
> Edited by: RichBlinne
> http://phpwiki.sourceforge.net/phpwiki/UploadMechanism?action=diff
> 
> UploadMechanism 21 2004-06-10T05:20:18-07:00
> UploadMechanism 22 2004-12-03T10:54:16-08:00
...
>   See also [Upload] (for dummies), [phpwiki:TitleSearch?s=upload].
>   
>   ----
> + 
> + It would be a nice new feature if the edit form would include the UploadPlugin. -- RichBlinne
>   [CategoryNextWikiDone]

Just edit themes/default/templates/editpage.tmpl like this:

<?php if ($user->isadmin()) { ?>
   <tr>
     <td><?= $LOCKED_CB ?> <?=_("Locked")?></td>
   </tr>
<?php } ?>
   <tr>
     <td><?plugin UpLoad ?></td>
   </tr>

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

Re: [Phpwiki-talk] Installation problems

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

John Cole schrieb:
> You can run into some problems (on past versions at least) because parts
> OldTextFormattingRules was included on the edit page.  If you can still edit
> without that page, I don't think you'll have any problems.  One quick
> workaround is to create a blank OldTextFormattingRules page if you do run
> into a problem editing (or remove the link from the edit page file, as I
> used to do).
> 
> I think this was fixed long ago, because I haven't need to do that in
> months.

Well, that's actually the php PCRE memory problem hitting us at 
ConvertOldMarkup().
It's the main hold back for a release-1.3.11, where I wanted to have 
fixed that. (besides other memory related problems, which cause no crash)

It crashes on converting complicated old markup, when the
phpwiki memory is low:
1. the page is big, or we convert
2. in between some other memory hog process like setupwiki or dumphtml

I did improve the situation by trying various things out, but the actual 
problem is still unsolved. Just the memory situation got better.

Yes, you can safely remove the content of OldTextFormattingRules. It's 
just docs.


> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...] On Behalf Of Robert
> Croson, Jr
> Sent: Friday, December 03, 2004 10:55 AM
> To: php...@li...
> Subject: RE: [Phpwiki-talk] Installation problems
> 
> At 0:29 on 4 Dec 2004, Charles Corrigan <ch...@ru...> wrote:
> 
> 
>>I had a similar problem on a different page (I now have a second
>>installation of phpwiki running on my Windows XP desktop).
>>
>>My workaround was to rename the file in pgsrc containing the page where
> 
> the
> 
>>error occurred to start with an "x" so it was processed last. Obviously,
>>this is not a real fix, just a workaround - I suspect an Apache or PHP on
>>windows problem here...
> 
> 
> That worked, except that I had to actually remove two files, instead of 
> rename them. Even if I renamed them, they were 'still' processed in the 
> same order, just with the new file names. The files I had to remove 
> were:
> 
> OldTextFormattingRules
> PgsrcRefactoring
> 
> That let it finish, and I can run it properly.
> 
> Will removing those two pages cause problems?

no.

> BTW - I also had to uncomment the DEBUG = 1 line in the CONFIG.INI 
> file, or all my pages would get about 50 "missing DEBUG" warnings at 
> the bottom of every page.
> 
> Thanks for the help!

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

[Phpwiki-talk] 403 forbidden error w/ 1.2.4

[John N. <jo...@jo...>]

Hello all. Sorry to make my first post a bug report. I searched the=20
archives and main phpwiki extensively, and I couldn't find anything on=20=

this.

Whenever I try and save a page with a character such as =EE, =E9, =F6, =
etc, I=20
get a 403 Forbidden error that mentions index.php. Similarly, I cannot=20=

access any page who's name contains such a character. I should note=20
that this affects most browsers, but not all. It doesn't work with=20
Safari on 10.3, Mozilla on 10.3, IE6 on XP (in most cases), etc... but=20=

browsers on OS 9 seem to be able to add such characters and visit such=20=

pages just fine, oddly enough. I've tried setting by browser to use=20
every encoding method under the sun with no results.

You can try to save a page with such a character here to see for=20
yourself my issue:
http://ruccas.org/index.php?SandBox

Likewise, here is a URL which contains an offending =EF character:
http://www.ruccas.org/index.php?Arge%efphontesLyre

If anyone can help me with this issue, it would be greatly appreciated.=20=

Unfortunately I do not have shell access to the server and cannot=20
update to 1.3.x, so I need to modify my existing 1.2.4 install somehow=20=

in order to get this working.

Here is my setup:

Linux (2.4.26 kernel)
Apache 1.3.33
PHP 4.3.9
MySQL 4.0.22-standard
PhpWiki 1.2.4

- John Nowak=

RE: [Phpwiki-talk] Installation problems

[John C. <joh...@ua...>]

You can run into some problems (on past versions at least) because parts
OldTextFormattingRules was included on the edit page.  If you can still edit
without that page, I don't think you'll have any problems.  One quick
workaround is to create a blank OldTextFormattingRules page if you do run
into a problem editing (or remove the link from the edit page file, as I
used to do).

I think this was fixed long ago, because I haven't need to do that in
months.

John Cole

-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of Robert
Croson, Jr
Sent: Friday, December 03, 2004 10:55 AM
To: php...@li...
Subject: RE: [Phpwiki-talk] Installation problems

At 0:29 on 4 Dec 2004, Charles Corrigan <ch...@ru...> wrote:

> I had a similar problem on a different page (I now have a second
> installation of phpwiki running on my Windows XP desktop).
> 
> My workaround was to rename the file in pgsrc containing the page where
the
> error occurred to start with an "x" so it was processed last. Obviously,
> this is not a real fix, just a workaround - I suspect an Apache or PHP on
> windows problem here...

That worked, except that I had to actually remove two files, instead of 
rename them. Even if I renamed them, they were 'still' processed in the 
same order, just with the new file names. The files I had to remove 
were:

OldTextFormattingRules
PgsrcRefactoring

That let it finish, and I can run it properly.

Will removing those two pages cause problems?

BTW - I also had to uncomment the DEBUG = 1 line in the CONFIG.INI 
file, or all my pages would get about 50 "missing DEBUG" warnings at 
the bottom of every page.

Thanks for the help!

-- 
ARCOM Inc. 440.639.9500  http://www.arcm.com
---Excellence In Technical Communications---



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

RE: [Phpwiki-talk] Installation problems

[Robert C. J. <ro...@ar...>]

At 0:29 on 4 Dec 2004, Charles Corrigan <ch...@ru...> wrote:

> I had a similar problem on a different page (I now have a second
> installation of phpwiki running on my Windows XP desktop).
> 
> My workaround was to rename the file in pgsrc containing the page where the
> error occurred to start with an "x" so it was processed last. Obviously,
> this is not a real fix, just a workaround - I suspect an Apache or PHP on
> windows problem here...

That worked, except that I had to actually remove two files, instead of 
rename them. Even if I renamed them, they were 'still' processed in the 
same order, just with the new file names. The files I had to remove 
were:

OldTextFormattingRules
PgsrcRefactoring

That let it finish, and I can run it properly.

Will removing those two pages cause problems?

BTW - I also had to uncomment the DEBUG = 1 line in the CONFIG.INI 
file, or all my pages would get about 50 "missing DEBUG" warnings at 
the bottom of every page.

Thanks for the help!

-- 
ARCOM Inc. 440.639.9500  http://www.arcm.com
---Excellence In Technical Communications---

[Phpwiki-talk] Installation problems

[Robert C. J. <ro...@ar...>]

 am trying to install phpWiki on the following system:

Windows XP Pro
Apache/2.0.47 (Win32) PHP/4.3.2
MySQL 4.0.14-nt
phpWiki 1.3.10

I am using mySQL as the backend for data storage.

The web server is on a separate system, being accessed over the LAN.

When load the page for the first time, It scrolls through the "Loading 
up virgin wiki" page until it hits this item:
"OldStyleTablePlugin"

If I use Firefox as the browser, it pops up a dialog stating "Document 
contains no data"

If I use IE as the browser, it loads the page to the same location, and 
then starts cycling through reloading the page.

I believe these are the relevant portions of the config.ini:

;======================================================================
; Part Two: Database Selection
;======================================================================
DATABASE_TYPE = SQL
DATABASE_PREFIX = phpwiki_
DATABASE_DSN = mysql://xxxx:xxxx@localhost/phpwiki
DATABASE_SESSION_TABLE = session
DATABASE_TIMEOUT = 20

I pretty much left everything else at the defaults.

I get the same behavior when I use a FILE backend.



I tried changing:

 if (SCRIPT_FILENAME == __FILE__)
    include(dirname(__FILE__)."/lib/main.php");

to:
// if (SCRIPT_FILENAME == __FILE__)
    include(dirname(__FILE__)."/lib/main.php");

But that didn't help.



Any suggestions?

-- 
ARCOM Inc. 440.639.9500  http://www.arcm.com
---Excellence In Technical Communications---

Re: [Phpwiki-talk] Bug renaming pages with a blank

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

Dan Frankowski schrieb:
> I just filed this. Sorry I don't have time to create the patch right now.
> http://sourceforge.net/tracker/index.php?func=detail&aid=1077769&group_id=6121&atid=106121 
 >
>    [ 1077769 ] Renaming pages with spaces turns out bad
> 
> I accidentally renamed a page to one that had a leading
> space. This is bad, and I think it should be prevented
> by trim()-ing the page name to rename to.
> 
> Then I tried to rename it to one without a space, and
> all sorts of PHP errors appeared, and the page itself
> was entirely blasted out of existence. Fortunately I
> could recover it by other means.

good catch.
trim is already done, but I have to check rename problem.
also the rename in backlinked pages. I've fixed that lately but didn't 
check yet.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Bug renaming pages with a blank

[Dan F. <dfr...@cs...>]

I just filed this. Sorry I don't have time to create the patch right now.

Dan

http://sourceforge.net/tracker/index.php?func=detail&aid=1077769&group_id=6121&atid=106121


    [ 1077769 ] Renaming pages with spaces turns out bad

I accidentally renamed a page to one that had a leading
space. This is bad, and I think it should be prevented
by trim()-ing the page name to rename to.

Then I tried to rename it to one without a space, and
all sorts of PHP errors appeared, and the page itself
was entirely blasted out of existence. Fortunately I
could recover it by other means.