phpwiki-talk

[Phpwiki-talk] modified MakeWikiZipHtml to accept pages argument...

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

Reini,
  Here is a simple patch to make the action=ziphtml work like
action=dumphtml with the pages argument.  Simple cut and paste :-) 

John Cole


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

[Phpwiki-talk] pmwiki

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

Has anyone ever looked at pmwiki (http://www.pmwiki.org)? It looks quite 
beautiful. Nice docs. I like the "WikiGroups" too 
(http://www.pmwiki.org/wiki/PmWiki/WikiGroup); I think it is very close 
to the multi-purpose thing my user was hoping for (which has been 
discussed under 'multiple instances of Phpwiki'). It doesn't seem to 
have a DB behind it, though.

Dan

test dir name (WAS: Re: [Phpwiki-talk] cvs access to dfrankow)

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

I am blocked on this until we choose a name for 'testbox'.

Comments?

Dan

Dan Frankowski wrote:

> Reini Urban wrote:
>
>> Dan Frankowski schrieb:
>>
>>> One of the changes is to add an error handler (instead of just an 
>>> assert handler). This is useful because then if there is incorrect 
>>> PHP syntax, vars missing, etc., the tests don't run. In other words, 
>>> the tests get more picky, which is good. When they get more picky, 
>>> they want an existing testbox with some stuff in it (InterWikiMap, 
>>> global_data, a few other things). Thus, I want to make a "testbox" 
>>> in CVS with the right stuff and check it in, as I did on our local 
>>> copy.
>>>
>>> Since I do not wish to make changes that you don't want, please tell 
>>> me that you approve. Then I'll go ahead and make the unit test 
>>> changes, including adding a CVS-tracked "testbox" with stuff in it.
>>
>>
>>
>> approved.
>
>
>
> Cool. I won't add it until we have a name you like (see below).
>
>> but the name "testbox" compared to out intermediate ".testbox"
>> might not fully understandable. can you think of a better name?
>
>
>
> I'm sorry, I didn't understand this.
>
> I picked "testbox" to mean a "test sandbox." I agree it is not a great 
> name, but I'm having a hard time thinking of better ones. A list of 
> possibilities:
>
> 1. testbox
> 2. test_sandbox
> 3. sandbox
> 4. backend_dir
> 5. backend_data
> 6. testdb
>
> Any preferences? I'm not sure any are very good.
>
>> In a perl CPAN test framework the call it "t" (for the logic) and 
>> "output" (for the output which should be tested against).
>
>
>
> Neither "t" nor "output" is appropriate here. It's more like "input". 
> I guess that's another possibility.
>
>> i'm not quite accustomed to the java unittest structure.
>
>
>
> Java has no standard proposal for the input data upon which to base 
> unit tests.
>
> Dan
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

RE: [Phpwiki-talk] action=dumphtml broken...

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

Reini,

>I'm also regularly doing dumphtml, since this is the best method to 
>catch all existing page and rendering errors.
Does your pagedump go all the way through, or does it crash like mine?

>>   IIS6 stops dead after OldStyleTablePlugin (you guessed it,
>> OldTextFormattingRules is the next page).
>So Apache1 and Apache2 are doing it right now on OldTextFormattingRules?
>Even without CreateToc?
>That's fine, so we only have to workaround for IIS now.
Yes, A1 and A2 both dump that fine, though I ran into problems loading that
page into a virgin wiki (I truncate all tables in phpMyAdmin and reload the
homepage) with A1/A2/IIS6.


>Do you know how to detect IIS? The php_sapi_name() would be good to 
>know. I really have to install that sucker right now. Will give me 
>headaches.
Sorry,  I haven't had to dig too deep into php lately.  Currently I'm
bouncing around projects in PHP, C#, VB6, DocBook XML, NAnt and a few
others.  It's starting to get hard to concentrate on complex problems ;-)

>"pages" is the usual comma seperated list of pagenames, where glob-style 
>wildcards are allowed. Similar to "exclude", which is not yet supported 
>in the dump actions.

>I usually do it like:
>   /wiki/AnyPage?action=dumphtml&pages=*TextFormattingRules
THANK YOU!  That let me dump the pages I wanted!!!!  This takes this bug off
my list for now!  Now my top bug would be timeouts when trying to load a
large page (we have a lot of inline images, which seems to take a very long
time).  

John Cole

-------------------------------------
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] action=dumphtml broken...

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

Reini,
  I have IIS6 running with isapi at the moment (on a W2K3 Server).  I can
change that to cgi if you need me to.

John

-----Original Message-----
From: Reini Urban [mailto:ru...@x-...]
Sent: Wednesday, June 30, 2004 4:35 AM
To: John Cole
Cc: php...@li...
Subject: Re: [Phpwiki-talk] action=dumphtml broken...


John Cole wrote:
>   I'm still trying to make the dumphtml action work.  I've tried the
> following combinations IIS6/Apache 1.3.31/Apache 2.0.48 and each with SQL
> and ADODB.  All with a virgin database.

IIS with php as isapi or as cgi?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

-------------------------------------
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] action=dumphtml broken...

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

John Cole wrote:
>   I'm still trying to make the dumphtml action work.  I've tried the
> following combinations IIS6/Apache 1.3.31/Apache 2.0.48 and each with SQL
> and ADODB.  All with a virgin database.

IIS with php as isapi or as cgi?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] action=dumphtml broken...

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

John Cole wrote:
> Reini,
>   I'm still trying to make the dumphtml action work.  I've tried the
> following combinations IIS6/Apache 1.3.31/Apache 2.0.48 and each with SQL
> and ADODB.  All with a virgin database.

I'm also regularly doing dumphtml, since this is the best method to 
catch all existing page and rendering errors.

>   Most stop after PhpWikiPoll with the following error:

We should really print out the pagename before it gets dumped. So you 
only have to guess. With upgrade it's easy because I print into a <pre>.

> Php Wiki Recent Changes
> Error reading XML file,
> http://phpwiki.sourceforge.net/phpwiki/RecentChanges?format=rss

This is PhpWikiRecentChanges, an error in RssFeed, RssParser or HttpClient.

>   IIS6 stops dead after OldStyleTablePlugin (you guessed it,
> OldTextFormattingRules is the next page).

So Apache1 and Apache2 are doing it right now on OldTextFormattingRules?
Even without CreateToc?
That's fine, so we only have to workaround for IIS now.

Do you know how to detect IIS? The php_sapi_name() would be good to 
know. I really have to install that sucker right now. Will give me 
headaches.

However, I really want to find the real problem with converting old 
markup, in the anchored block regex.
I found another page of mine which crashes even with Apache1.

>   I've found some other issues with the current cvs version, but this one is
> at the top of my list at the moment, as I'm trying to get our user manual
> (newly converted to wiki from word) exported to compiled help files and
> pdfs, for a demo on Friday ;-)
> 
>   Also, could you give an example on how to use the 'pages' variable with
> the dumphtml action?

"pages" is the usual comma seperated list of pagenames, where glob-style 
wildcards are allowed. Similar to "exclude", which is not yet supported 
in the dump actions.

I usually do it like:
   /wiki/AnyPage?action=dumphtml&pages=*TextFormattingRules


> John
> 
> PS.  I've got today's CVS version running on intranet now, so its getting
> hit well at the moment.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Multiple instances of Phpwiki ?

[Oliver B. <ob...@de...>]

Matthew Palmer wrote:

[...]

> > I just prefer my simple starter scripts because they are shorter.
> 
> Shorter than
> 
> <?php
> require_once 'lib/IniConfig.php';
> IniConfig('/foo/bar/baz');
> define('__CONFIGURED');
> 
> ?

IMHO it is simpler, because the script also contains the specific 
configuration where your method requires a third file.

But I see not basic difference since both methods combine a standard 
config with specific settings, and therefore no need for heated 
discussions.

Although I have no PHP knowledge, I have no problem to understand 
both methods and adapt PhpWiki to my specific needs. If I decide to 
set variables in the php script, I can do so. If I prefer to read a 
*.ini, I can do it also. Who cares?

Is it important, which method is shipped with the PhpWiki 
distribution?

After all, both methods can be documented.

Oliver

Re: [Phpwiki-talk] Multiple instances of Phpwiki ?

[Matthew P. <mp...@he...>]

On Tue, Jun 29, 2004 at 07:39:12PM +0200, Reini Urban wrote:
> I never said that your idea sucks.
> I like it. I even have some test scripts which use your approach.

"And don't really like Matthew's idea."  (That's from message 8500690 in the
phpwiki-talk archive).

I'm happy to accept that you may have changed your mind in the interim, but
you did say in the past that you didn't like it.

> I just prefer my simple starter scripts because they are shorter.

Shorter than

<?php
require_once 'lib/IniConfig.php';
IniConfig('/foo/bar/baz');
define('__CONFIGURED');

?

The three basic defines in your example in 8500690 are that length, before
you start including index.php or lib/main.php.  The snippet above also
requires one change -- the location of the config file -- for use on another
site.

> And we used my way for some years now in the demo site, before we even 
> had a config.ini file.

I'm not denying it may well have been the best solution in the past.

- Matt

[Phpwiki-talk] Template eval error

[Tom C. <li...@to...>]

Hi everybody,

Sorry to bring this up again... I think I saw something about it on this list 
a week or so ago, but I couldn't find it in the archives.

How can I fix the following error without upgrading to the CVS / pre-release 
version?

---
Fatal error: Call to a member function on a non-object 
in /usr/local/apache/htdocs/phpwiki/lib/Template.php(131) : eval()'d code on 
line 5
---

Regards,
Tom

[Phpwiki-talk] action=dumphtml broken...

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

Reini,
  I'm still trying to make the dumphtml action work.  I've tried the
following combinations IIS6/Apache 1.3.31/Apache 2.0.48 and each with SQL
and ADODB.  All with a virgin database.

  Most stop after PhpWikiPoll with the following error:

Php Wiki Recent Changes
Error reading XML file,
http://phpwiki.sourceforge.net/phpwiki/RecentChanges?format=rss

  IIS6 stops dead after OldStyleTablePlugin (you guessed it,
OldTextFormattingRules is the next page).

  I've found some other issues with the current cvs version, but this one is
at the top of my list at the moment, as I'm trying to get our user manual
(newly converted to wiki from word) exported to compiled help files and
pdfs, for a demo on Friday ;-)

  Also, could you give an example on how to use the 'pages' variable with
the dumphtml action?

John

PS.  I've got today's CVS version running on intranet now, so its getting
hit well at the moment.

JwC

-------------------------------------
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] Multiple instances of Phpwiki ?

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

Matthew Palmer wrote:
> On Tue, Jun 29, 2004 at 09:14:42AM +1200, Jim Cheetham wrote:
> [__CONFIGURED for multiple Wikis]
>>I'd like to see this too, because I'm currently running three wikis on 
>>the same machine, with the associated duplication of code files. Perhaps 
>>Matthew could implement this, and Reini could accept it into CVS?
> 
> 
> Reini said he didn't like my idea, and preferred his way of doing it.  See
> http://sourceforge.net/mailarchive/message.php?msg_id=8500690.  The problem
> I see with Reini's idea is that it relies on trusting IniConfig not to go
> overwriting existing define()s.  That's fine and dandy now, but without
> giant "Here be Monsters, lad" all over the IniConfig code, someone in the
> future is going to change it to do just that (because constant leakage is
> bad), and suddenly all of your custom Wikis die.
> 
> Also, you're splitting the config into multiple parts again -- one for
> defines, and one for variables.  With the number of variables in PHPWiki
> (and the fact that now, with IniConfig, they're no longer documented as
> being variables in the config file, but only in the depths of IniConfig()
> -- and that's subject to change without notice), you're going to have a hard
> time figuring out which one's which.
> 
> My system adds little in the way of complexity -- both methods require
> .htaccess fiddling and snippets of custom code, as does mine -- but mine
> allows you to use the same config method for custom sites -- an IniConfig
> file -- as the main site.
> 
> But hey, to each their own.  Reini thinks my idea sucks, I think his does,
> and we all clap hands together.  

I never said that your idea sucks.
I like it. I even have some test scripts which use your approach.
I just prefer my simple starter scripts because they are shorter.

And we used my way for some years now in the demo site, before we even 
had a config.ini file.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Multiple instances of Phpwiki ?

[Philippe V. <Phi...@to...>]

Jim Cheetham said:
> Yes, Matthew Palmer was talking about enabling this for the Debian
> packaged version. The current stopper is that index.php looks in a fixed
> location for the config file, but if this were overridden by a php value
> set in the .htaccess file, you could have a lot of flexibility. Here's
> (part of) his original post ...
<Snip>

Interresting...
There is also another method described there:
http://phpwiki.sourceforge.net/phpwiki/WikiFarm

An alternative would be to use the last element of the path as a key to a
config file.
E.g. http://xxx.org/wiki1/index.php would look for a wiki1.ini config file.

So there are plenty of possibilities that one can implement easily as
wrapper around phpWiki without touching a lot to the sources.

Dan Frankowski said:
> This still does not allow one to use the same DB, so if any upgrades
> cause DB changes, that would still force lots of DB upgrades, and
> potentially lots of index.php config upgrades. However, it probably helps.

This is a more fundamendal change in the DB design. Less easy to do...

-- 
Philippe

Re: [Phpwiki-talk] Multiple instances of Phpwiki ?

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

Jim Cheetham schrieb:

> Dan Frankowski wrote:
> 
>> I replied that Twiki has a notion of multiple "webs", but Phpwiki had 
>> no such. One could run multiple Phpwiki instances, but then if the 
>> code changes, you have to update code and config for each instance 
>> separately.
>>
>> Does anyone have better ideas?
> 
> Yes, Matthew Palmer was talking about enabling this for the Debian 
> packaged version. The current stopper is that index.php looks in a fixed 
> location for the config file, but if this were overridden by a php value 
> set in the .htaccess file, you could have a lot of flexibility. Here's 
> (part of) his original post ...

You don't need seperate config.ini's.
Put the common options into config.ini and the overrides (DATABASE_DSN, 
WIKI_NAME, ...) into the short starter script.

I run about 30 different databases with lots of different options with 
the same config.ini. CONSTANT's override config.ini settings, besides 
the DATA_BASE settings, which must be defined after loading index.php.

Some files of my /wiki dir are attached.

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

[Phpwiki-talk] Stub plugin -- help

[Arthaey A. <ar...@gm...>]

So I've been looking at existing plugins and trying to learn how to
make them. Here I'm trying to make a simple stub warning plugin.
Here's the run function from my plugin/Stub.php:

    function run($dbi, $argstr, &$request, $basepage) {
        $args = $this->getArgs($argstr, $request);

        $html = HTML::div();
        $html->pushContent("This page is a ");
        $html->pushContent(LinkURL(WikiURL("StubPage")));
        $html->pushContent(". You can help the wiki by ");
        $html->pushContent(LinkURL(
         WikiURL($args['pagename'], array('action' => 'edit')),
         "editing it"));
        $html->pushContent(". Until then, it will be filed under ");
        $html->pushContent(LinkURL(WikiURL("CategoryStub")));
        $html->pushContent(".");

        return HTML::em($html);
    }

It displays almost perfectly
(http://arthaey.mine.nu:8080/wiki/index.php/Ashyinave), with the
exception that the LinkURLs are class='namedurl' instead of 'wiki'.
This makes it so that the BackLinks plugin on the CategoryStub page
doesn't see the pages with the stub link.

I tried changing it from

        $html->pushContent(LinkURL(WikiURL("CategoryStub")));

to

        $link = LinkURL(WikiURL("CategoryStub"));
        $link->setAttr('class', 'wiki');
        $html->pushContent($link);

But the class remained as 'namedurl'.

So I have two questions:

 1. Why doesn't the setAttr call work like I expected it to?
 2. Is there some better way of doing this altogether?


Thanks!

--
AA

Re: [Phpwiki-talk] Multiple instances of Phpwiki ?

[Matthew P. <mp...@he...>]

On Tue, Jun 29, 2004 at 09:14:42AM +1200, Jim Cheetham wrote:
[__CONFIGURED for multiple Wikis]

> I'd like to see this too, because I'm currently running three wikis on 
> the same machine, with the associated duplication of code files. Perhaps 
> Matthew could implement this, and Reini could accept it into CVS?

Reini said he didn't like my idea, and preferred his way of doing it.  See
http://sourceforge.net/mailarchive/message.php?msg_id=8500690.  The problem
I see with Reini's idea is that it relies on trusting IniConfig not to go
overwriting existing define()s.  That's fine and dandy now, but without
giant "Here be Monsters, lad" all over the IniConfig code, someone in the
future is going to change it to do just that (because constant leakage is
bad), and suddenly all of your custom Wikis die.

Also, you're splitting the config into multiple parts again -- one for
defines, and one for variables.  With the number of variables in PHPWiki
(and the fact that now, with IniConfig, they're no longer documented as
being variables in the config file, but only in the depths of IniConfig()
-- and that's subject to change without notice), you're going to have a hard
time figuring out which one's which.

My system adds little in the way of complexity -- both methods require
.htaccess fiddling and snippets of custom code, as does mine -- but mine
allows you to use the same config method for custom sites -- an IniConfig
file -- as the main site.

But hey, to each their own.  Reini thinks my idea sucks, I think his does,
and we all clap hands together.  He runs the project, and does it well
enough that I doubt anyone's about to start muttering about mutiny or taking
their bat and ball because of a different method of doing multi-wiki.

I'll run up a patch if anyone is truly interested (and I'll even keep it
current against future releases), but it's such a simple modification that
you can do it yourself at home with simple hand tools -- as documented in my
original E-mail (for reference, 
http://sourceforge.net/mailarchive/message.php?msg_id=7966839).

- Matt

Re: [Phpwiki-talk] Multiple instances of Phpwiki ?

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

Philippe Vanhaesendonck wrote:

> Try this: http://phpwiki.sourceforge.net/phpwiki/FrequentlyAskedQuestions


Ah! I presume you mean this question:

  Q. Can I run two PhpWiki 
<http://phpwiki.sourceforge.net/phpwiki/PhpWiki>s with separate 
databases off the same code?:

I don't look in the FAQ page because it's large, frightening, and has 
not much TOC, but I should remember to grind through it more. This is 
somewhat helpful.

It might be nice if only the changes were kept in separate files. 
Presumably, one could modify the index.php and wiki2.php to include some 
common config.

This still does not allow one to use the same DB, so if any upgrades 
cause DB changes, that would still force lots of DB upgrades, and 
potentially lots of index.php config upgrades. However, it probably helps.

Dan

>
> Dan Frankowski wrote:
>
>> Folks,
>>
>> One of my users is really excited about Phpwiki, and said, "I can 
>> think of uses for dozens of instances of it!" However, he wants that 
>> each of those instances is logically separate from the others. So, 
>> for example, the HomePage of each does not show the others, the 
>> search for each does not turn up pages in the others, etc.
>>
>> I replied that Twiki has a notion of multiple "webs", but Phpwiki had 
>> no such. One could run multiple Phpwiki instances, but then if the 
>> code changes, you have to update code and config for each instance 
>> separately.
>>
>> Does anyone have better ideas?
>>
>> Dan
>
>
>

Re: [Phpwiki-talk] Multiple instances of Phpwiki ?

[Jim C. <ji...@iN...>]

Dan Frankowski wrote:
> I replied that Twiki has a notion of multiple "webs", but Phpwiki had no 
> such. One could run multiple Phpwiki instances, but then if the code 
> changes, you have to update code and config for each instance separately.
> 
> Does anyone have better ideas?

Yes, Matthew Palmer was talking about enabling this for the Debian 
packaged version. The current stopper is that index.php looks in a fixed 
location for the config file, but if this were overridden by a php value 
set in the .htaccess file, you could have a lot of flexibility. Here's 
(part of) his original post ...

>> Another method, if you wanted it, that would work in PHPWiki more or less
>> as-is, would be to use the other method I devised for the above project
>> (which I didn't use as the substring method was more appropriate in that
>> case).  Create a constant, perhaps called __CONFIGURED, that will be
>> defined
>> true once all of the appropriate config statements have been processed.
>> Then, tell index.php not to call IniConfig() (or tell IniConfig() not to
>> do
>> anything) if __CONFIGURED is defined.
>>
>> How does this help?  Because you put something like the following in your
>> apache.conf for each of the virtualised PHPWiki instances:
>>
>> php_value auto_prepend_file /some/config/file.php
>>
>> Where /some/config/file.php is unique for each instance, and contains
>> pretty
>> much the following code:
>>
>> require_once '/usr/share/phpwiki/lib/IniConfig.php';
>> IniConfig('/some/config/file.ini');
>> define('__CONFIGURED', true);
>>
>> Again, where /some/config/file.ini is unique to that virtual instance of
>> PHPWiki and filled with lovely local-specific config options.
>>
>> You then point each virtual instance of PHPWiki at /usr/share/phpwiki for
>> it's code, index.php runs for everyone but skips the default config for
>> your
>> virtual instances because __CONFIGURED is defined, and IniConfig() has
>> previously run with your per-instance config file.

I'd like to see this too, because I'm currently running three wikis on 
the same machine, with the associated duplication of code files. Perhaps 
Matthew could implement this, and Reini could accept it into CVS?

-jim

Re: [Phpwiki-talk] Wikilens-phpwiki integration: PageList custom column problems

[Scott Y. <sy...@cs...>]

Reini Urban wrote:

> Scott Yilek schrieb:
>
>> My name is Scott Yilek and I'm working on wikilens with Dan 
>> Frankowski. We've recently been trying to integrate wikilens with 
>> phpwiki and we are still having a few issues with the new pagelist 
>> custom columns.
>>
>> The main problem is that we need to send each column more parameters 
>> than are currently allowed.  Currently each custom pagelist column's 
>> constructor gets $params which is always assumed to be length 4 with 
>> $params[3] as the reference back to the pagelist object.  If any 
>> other parameters are needed, the constructor gets them from the 
>> pagelist object: $this->_pagelist->getOption('user')  for example.  
>> This doesn't quite work for us because we need each column to get its 
>> parameters independently from the other columns.  For example, we 
>> can't do getOption('user') if we want a column for each buddy; we 
>> need to send in the buddy as a parameter.
>>
>> What would be great is if each column's constructor could accept more 
>> parameters as necessary.  The way Dan Frankowski proposed originally 
>> worked well for this because we could create our own column objects 
>> how we liked them and just sent them into pagelist to be added.  Do 
>> you think we should go back to this or do you see a better solution?
>
>
> Have you updated your source, so that I can see it?


We haven't updated our source because we're still merging, in part 
depending on the resolution to this question.

However, our tarred source code has our original proposal for custom 
pagelist columns.  The code to best explain our problem is in our 
lib/plugin/UserRatings.php file on lines 204-212.

>
> I thought putting the required column options to the pagelist object 
> is enough, so that the columns can get it from the pagelist object.
>
> you need more usernames? cannot you put the needed array of buddies to 
> the $pagelist->_options then?


Each pagelist column needs to get its own user, and although an array of 
users in PageList that can be accessed by $pagelist->_options can store 
all the users, each column still needs to be sent a parameter to tell it 
which user it's supposed to show ratings for.  Somehow the column needs 
to know which user in the array to use.  So sending the constructor more 
arguments seems necessary, and the way we had it before makes this 
possible and fairly easy.

I tried to put in a hack to still use the way you currently have it set 
up, where on the same lines mentioned above i do,
 
$col = array('_PageList_Column_ratingvalue','custom:ratingvalue', 
$u->getId(), 'right', $u);
$pagelist->addColumnObject($col);

and then in addColumnObject() function in PageList I change
$params[3] = & $this;
to
$params[count($params)] =& $this;
so that the reference is always the last element of the parameter array 
instead of the 4th element.  This works, but involved me editing the 
core code which we are trying to avoid, and it just feels wrong.  But it 
highlights what we need to do: send extra parameters to the column's 
constructor.


Thanks,
Scott

Re: [Phpwiki-talk] Multiple instances of Phpwiki ?

[Philippe V. <Phi...@to...>]

Try this: http://phpwiki.sourceforge.net/phpwiki/FrequentlyAskedQuestions

Dan Frankowski wrote:

> Folks,
>
> One of my users is really excited about Phpwiki, and said, "I can 
> think of uses for dozens of instances of it!" However, he wants that 
> each of those instances is logically separate from the others. So, for 
> example, the HomePage of each does not show the others, the search for 
> each does not turn up pages in the others, etc.
>
> I replied that Twiki has a notion of multiple "webs", but Phpwiki had 
> no such. One could run multiple Phpwiki instances, but then if the 
> code changes, you have to update code and config for each instance 
> separately.
>
> Does anyone have better ideas?
>
> Dan


-- 
PhilV

Key fingerprint = 2B97 90DB 124B C784 FFE8  6EED 6345 A87E 4BBA F57C

[Phpwiki-talk] more issues...

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

Reini,
  It appears that both ADODB and SQL are not following the DATABASE_TIMEOUT
option.  I have a page that apparently times out regularly.  The resulting
page is blank.

  The page is 28939 bytes, could this be an apache config problem?  I have
tried Apache 1.3.31 and IIS6

  I'm also having a problem with unfolding subpages with very large
subpages, and I think this might be an issue here too.

John Cole

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

[Phpwiki-talk] Multiple instances of Phpwiki ?

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

Folks,

One of my users is really excited about Phpwiki, and said, "I can think 
of uses for dozens of instances of it!" However, he wants that each of 
those instances is logically separate from the others. So, for example, 
the HomePage of each does not show the others, the search for each does 
not turn up pages in the others, etc.

I replied that Twiki has a notion of multiple "webs", but Phpwiki had no 
such. One could run multiple Phpwiki instances, but then if the code 
changes, you have to update code and config for each instance separately.

Does anyone have better ideas?

Dan

[Phpwiki-talk] dump to xhtml is broken...

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

Reini,
  The dump to xhmtl is broken.  You get the following on
PhpWikiRecentChanges

Php Wiki Recent Changes
Error reading XML file,
http://phpwiki.sourceforge.net/phpwiki/RecentChanges?format=rss

  Also, if you append the ?action=dumphtml to a page, it does the same thing
as pressing the 'dump to xhtml' button on the admin page, instead of dumping
that one page (or subpages).

John

-------------------------------------
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] cvs access to dfrankow

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

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> One of the changes is to add an error handler (instead of just an 
>> assert handler). This is useful because then if there is incorrect 
>> PHP syntax, vars missing, etc., the tests don't run. In other words, 
>> the tests get more picky, which is good. When they get more picky, 
>> they want an existing testbox with some stuff in it (InterWikiMap, 
>> global_data, a few other things). Thus, I want to make a "testbox" in 
>> CVS with the right stuff and check it in, as I did on our local copy.
>>
>> Since I do not wish to make changes that you don't want, please tell 
>> me that you approve. Then I'll go ahead and make the unit test 
>> changes, including adding a CVS-tracked "testbox" with stuff in it.
>
>
> approved.


Cool. I won't add it until we have a name you like (see below).

> but the name "testbox" compared to out intermediate ".testbox"
> might not fully understandable. can you think of a better name?


I'm sorry, I didn't understand this.

I picked "testbox" to mean a "test sandbox." I agree it is not a great 
name, but I'm having a hard time thinking of better ones. A list of 
possibilities:

1. testbox
2. test_sandbox
3. sandbox
4. backend_dir
5. backend_data
6. testdb

Any preferences? I'm not sure any are very good.

> In a perl CPAN test framework the call it "t" (for the logic) and 
> "output" (for the output which should be tested against).


Neither "t" nor "output" is appropriate here. It's more like "input". I 
guess that's another possibility.

> i'm not quite accustomed to the java unittest structure.


Java has no standard proposal for the input data upon which to base unit 
tests.

Dan

[Phpwiki-talk] another pass-by-reference

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

Reini,
  Found another pass-by-reference...

[28-Jun-2004 13:03:42] PHP Warning:  Call-time pass-by-reference has been
deprecated - argument passed by value;  If you would like to pass it by
reference, modify the declaration of array_push().  If you would like to
enable call-time pass-by-reference, you can set
allow_call_time_pass_reference to true in your INI file.  However, future
versions may not support this any longer.  in c:\program files\apache
group\apache\htdocs\phpwiki\lib\plugin\ListPages.php on line 90

John

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