phpwiki-talk

[Phpwiki-talk] MAybe a bug

[Hiram G. <gi...@cs...>]

Hello,

I don't think this is a bug but I would like if someone would be able to 
point me in the right direction?



I have checked all the bugs on
https://sourceforge.net/bugs/?group_id=6121

and haven't been able to get my wiki started:
http://wiki.csit.fsu.edu/phpwiki-1.2.4/


This happens right after the install and still after the configuration 
is complete. (Well unless I have missed something of course).

Any help would be greatly appreciated.


Thanks,
-Hiram


-- 
//------------------------------------------//

                 Hiram Gibbard
             Programmer Analyst II
        School of Computational Science

              PHONE: 850.644.0188
          Email: gi...@cs...
        URL:   www.csit.fsu.edu/~gibbard

//-----------------------------------------//

Re: [Phpwiki-talk] Wiki-installation

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

Johannes Rumpf schrieb:
> i've got a mass installation problems with the 1.3.10 Wiki. this morning i'd 
> changed just one line in the config.ini
> ; THEME = default
> THEME = Hattstein
> and then the wiki don't like me any more. The error i got is:
> 
> [Mon Aug 23 12:35:22 2004] [error] PHP Fatal error:  Call to undefined 
> function:  dba_open() in /home/ha....
> 
> 
> But there is no change in the dba... just the theme. And it stays after change 
> back to ol' config...

php issue, nothing related to phpwiki:

There must be happened a change in the php.ini or the php build, because 
dba_open() is not known anymore. somebody changed your php installation.

inspect your phpinfo().

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

[Phpwiki-talk] Wiki-installation

[Johannes R. <ru...@fb...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi @all,

i've got a mass installation problems with the 1.3.10 Wiki. this morning i'=
d=20
changed just one line in the config.ini
; THEME =3D default
THEME =3D Hattstein
and then the wiki don't like me any more. The error i got is:

[Mon Aug 23 12:35:22 2004] [error] PHP Fatal error:  Call to undefined=20
function:  dba_open() in /home/ha....


But there is no change in the dba... just the theme. And it stays after cha=
nge=20
back to ol' config...

I hate these all so much...

Joe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBUqqGnmAbbUgFSFgRApxTAJoDS2u5zZyMuPjH3xq7DGg1f0+NaQCgpJrc
KRw22dsWrX0jkF37n/4CTu0=3D
=3DHMmK
=2D----END PGP SIGNATURE-----

Re: [Phpwiki-talk] plugin-list proposal

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

Reini:

SO glad to see this. It's what I've been working on/waiting for for a 
long time - IncludeSiteMap is okay, but it will massively increase 
phpwiki's usefulness as the core of our documentation creation 
environment in the following way:

We use certain Categories to indicate 'approved', 'completed', 
'obsolete', 'shipping' documentation, and by doing a 'FullTextSearch' 
we currently can autogenerate lists of documents maatching the right 
criteria.

With this pluginlist capability and IncludePage, we can automatically 
create complete web pages (and, by extension, pdf's and html 
directories) containing not only a list, but the content of the pages 
themselves...

...I'm looking forward to experimenting with it!

Thanks again,
Micki



At 8:40 PM -0700 8/22/04, php...@li... wrote:
>Message: 2
>Date: Sun, 22 Aug 2004 16:34:06 +0200
>From: Reini Urban <ru...@x-...>
>To:  php...@li...
>Subject: [Phpwiki-talk] plugin-list proposal
>
>I carry for some weeks now this idea with me and want to share it.
>
>The problem is that several plugins produce page lists, and other
>plugins accept page lists as input, but there's no connection between them.
>For example BackLinks produces a list of pages, which could be used as
>pages argument for the IncludePage plugin, if it will be extended for
>multiple pages, or as argument to the ListSubpages, WikiAdminSetAcl,
>WikiAdminSearchReplace plugins.
>Or for the example for the exclude argument
>
>I would like to discuss an additional API for plugins which is similar
>to run() but returns ony a list of pages, not the HTML'ized UL list,
>which in turn can be used as input argument to other plugins.
>Similar to unix pipes.
>Arguments accepting only a single pagename will take the first page from
>the list.
>The list method will share the same code as run, but only returns a LIST
>of pagenames, not the HTML objects.
>For the start list() could extract the pagename list from the run() method.
>Several plugins will require a unification of the "pages" vs. "p" vs.
>"s" argument.
>
>Examples:
>
>Select the pages linking to HomePage to change a text.
><?plugin WikiAdminSearchReplace p=<?plugin-list BackLinks
>page="HomePage" ?> ?>
>
>List the subpages of the first page starting with "Doc*":
><?plugin ListSubpages basepage=<?plugin-list TitleSearch s="Doc*" ?> ?>
>
>remove some of the orphaned pages:
><?plugin WikiAdminRemove p=<?plugin-list OrphanedPages ?> ?>


-- 

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

Re: [Phpwiki-talk] plugin-list proposal

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

Jim Cheetham schrieb:
> On Aug 23, 2004, at 7:23 AM, Reini Urban wrote:
>> Reini Urban schrieb:
>>
>>>> I would like to discuss an additional API for plugins which is 
>>>> similar to run() but returns ony a list of pages, not the HTML'ized 
>>>> UL list, which in turn can be used as input argument to other plugins.
>>>
>>> See http://phpwiki.sourceforge.net/phpwiki/PluginList
>>
>> If there are no objections I will include it.
>>
> You haven't given much time to think about it ;-) but it seems like a 
> very good idea.
> It's simple and flexible. Good stuff.

Yeah, I forgot to actually attach the diff. It is now at the tracker.

Works fine, just the argument parser is not really stable.

pages=<?plugin-list ... ?> is okay, but these not:
pages = <?plugin-list ... ?>
pages="<?plugin-list ... ?>"
pages='<?plugin-list ... ?>'

I think I will commit this in the next days, since the changes are 
marginal and I find it useful.
-- 
Crime does not pay ... as well as politics. (Alfred E. Newman)

Re: [Phpwiki-talk] plugin-list proposal

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

Reini Urban schrieb:
>> I would like to discuss an additional API for plugins which is similar 
>> to run() but returns ony a list of pages, not the HTML'ized UL list, 
>> which in turn can be used as input argument to other plugins.
> 
> See http://phpwiki.sourceforge.net/phpwiki/PluginList

I posted a working patch against cuurrent CVS at
http://sourceforge.net/tracker/index.php?func=detail&aid=1013913&group_id=6121&atid=306121

If there are no objections I will include it.

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

Re: [Phpwiki-talk] plugin-list proposal

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

Reini Urban schrieb:
> I would like to discuss an additional API for plugins which is similar 
> to run() but returns ony a list of pages, not the HTML'ized UL list, 
> which in turn can be used as input argument to other plugins.

See http://phpwiki.sourceforge.net/phpwiki/PluginList

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

[Phpwiki-talk] plugin-list proposal

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

I carry for some weeks now this idea with me and want to share it.

The problem is that several plugins produce page lists, and other 
plugins accept page lists as input, but there's no connection between them.
For example BackLinks produces a list of pages, which could be used as 
pages argument for the IncludePage plugin, if it will be extended for 
multiple pages, or as argument to the ListSubpages, WikiAdminSetAcl, 
WikiAdminSearchReplace plugins.
Or for the example for the exclude argument

I would like to discuss an additional API for plugins which is similar 
to run() but returns ony a list of pages, not the HTML'ized UL list, 
which in turn can be used as input argument to other plugins.
Similar to unix pipes.
Arguments accepting only a single pagename will take the first page from 
the list.
The list method will share the same code as run, but only returns a LIST 
of pagenames, not the HTML objects.
For the start list() could extract the pagename list from the run() method.
Several plugins will require a unification of the "pages" vs. "p" vs. 
"s" argument.

Examples:

Select the pages linking to HomePage to change a text.
<?plugin WikiAdminSearchReplace p=<?plugin-list BackLinks 
page="HomePage" ?> ?>

List the subpages of the first page starting with "Doc*":
<?plugin ListSubpages basepage=<?plugin-list TitleSearch s="Doc*" ?> ?>

remove some of the orphaned pages:
<?plugin WikiAdminRemove p=<?plugin-list OrphanedPages ?> ?>

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

Re: [Phpwiki-talk] Re: PhpWiki - Superglobals and Author-independent Archiving

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

Dan Kamins schrieb:

> I spent a few hours digging into 1.3 source.  Wow, it looks like a complete rewrite.  I didn't expect so much to change in a minor version.  I'm glad I didn't spend too much time familiarizing with the 1.2 codebase!  Sorry for the mail.
> 
> I'm kind of at a standstill now though, because 1.2 doesn't have the features I need (as mentioned below) or work on my server without modifications, and 1.3 crashes my server in a weird way ( http://sourceforge.net/tracker/?func=detail&aid=1013350&group_id=6121&atid=106121 )... What to do... Anybody seen this PCRE crash before?
> 
>>From the bug report, this code crashes (which is a simpler version of what my ConvertOldMarkup() does to the file OldTextFormattingRules during virgin setup):
>   $pat = "/\A((?:.|\n)*?)(^(?:[ \t]+\S(?:.*\s*\n[ \t]+\S)*|".
>     "\|(?:.*\n\|)*|[#*;]*(?:[*#]|;.*?:)|\[\s*(\d+)\s*\]|".
>     "<\?plugin(?:-form)?\b.*\?>\s*$|!{1,3}[^!]).*$)\n?/m";
>   $subj = str_repeat("123456789 ", 50);
>   preg_match($pat, $subj);

yes, this is a known issue.
cause still unknown. happens only with huge anchored regex.

please remove pgsrc/OldTextFormattingRules on virgin setup.


> Ouch!
> 
> --
> Dan Kamins
> 
> On Sat, 21 Aug 2004 10:34:12 +0200, Reini Urban wrote:
> 
>>Dan Kamins schrieb:
>>
>>>Hi guys. First of all, let me say that PhpWiki is great! I just
>>>got into the Wiki world, evaluated a bunch of Wiki packages, and
>>>almost immediately left the Wiki world in disgust until I found
>>>PhpWiki, which is well-organized, efficient, straightforward, and
>>>configurable.  Kudos. Now before I get too far down the path of
>>>using it, there are a couple of changes I was going to request,
>>>but I would actually be happy to do them myself and submit
>>>patches.  So what I wanted to ask was a) how do you feel about
>>>these changes, and b) how should I submit them.  It may be
>>>possible these are already in the 1.3 branch, but I've only
>>>installed and worked with 1.2 stable so far.  In fact, maybe
>>>you've discussed and/or included these in 1.3, but I didn't see
>>>either in the mail list archives or patch history.
>>>
>>
>>All your requests are in the 1.3.x branch and much more. 1.3 is by
>>far better, you'll like it!
>>
>>And please post to the mailinglist, not to the indidviduals.
>>
>>
>>
>>>1. Superglobals...
>>>
>>>
>>>As of PHP 4.2.0, register_globals went from ON to OFF by default.
>>>Many servers operate in this new mode, which is far more secure
>>>now. The effect is that PhpWiki doesn't work! And I'm *SURE* a
>>>lot of users go through what I did: install 10 different Wiki
>>>engines and evaluate them. When it doesn't work right out of the
>>>box for mysterious reasons, you're going to lose a lot of
>>>potential users. I had to dig deep to figure out what the problem
>>>was, and I think a lot of people would just move on.
>>>
>>>
>>>The problem manifests itself as the fact that you can't click on
>>>anything because all the links are broken. It's easy to fix, and
>>>just requires changing all global implicit vars to explicit
>>>superglobal references. Like $DOCUMENT_ROOT becomes
>>>$_SERVER['DOCUMENT_ROOT'].  A poor workaround is to slam a big
>>>set of code up at the top of config.php that does something like:
>>>if (isset($_SERVER['SERVER_NAME'])) $SERVER_NAME =
>>>$_SERVER['SERVER_NAME']; if (isset($_SERVER['SERVER_PORT']))
>>>$SERVER_PORT = $_SERVER['SERVER_PORT']; if
>>>(isset($_SERVER['SCRIPT_NAME'])) $SCRIPT_NAME =
>>>$_SERVER['SCRIPT_NAME']; ... The right way to do it is to just
>>>reference the superglobal names directly.  This will break
>>>compatibility with PHPs older than 4.1.0 (when superglobals were
>>>introduces), but does anybody really use PHP that old?
>>>There are a LOT of these variables in the source, but I am
>>>volunteering to change them.
>>>
>>>
>>>The motivation and history of this is clearly explained at this
>>>link: http://us4.php.net/manual/en/security.globals.php
>>>
>>>I saw a discussion regarding this ("superglobals policy") on the
>>>mail archives:
>>>http://sourceforge.net/mailarchive/message.php?msg_id=2051713
>>>Valid points were brought up, but that was almost 2 years ago,
>>>and the world has changed a lot.  I think it's time to revisit
>>>this issue (if it hasn't been yet).
>>>
>>>---
>>>
>>>
>>>2. Author-Independent Archiving...
>>>
>>>
>>>In 1.2 stable, only changes made by different authors get
>>>archived and are thus diff-able.  So if I make a change, then
>>>make another change, I lose my intermediate change history.
>>>Maybe this is fine for many users, but I'm 100% other users would
>>>like every change archived (as I am one of those users), and this
>>>is functionality many other engines provide.  I propose adding a
>>>config variable (like "ArchiveOnlyWhenAuthorChanges" defaulting
>>>to TRUE, which would be same behavior as now) which would be
>>>checked in savepage.php at the point of archiving the old data.
>>>If set to FALSE, then every change would be archived.
>>>
>>>
>>>---
>>>
>>>
>>>Thanks for listening.  Let me know what you think about these
>>>issues and keep up the good work.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 


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

[Phpwiki-talk] Re: PhpWiki - Superglobals and Author-independent Archiving

[Dan K. <do...@ax...>]

I spent a few hours digging into 1.3 source.  Wow, it looks like a complete=
 rewrite.  I didn't expect so much to change in a minor version.  I'm glad I=
 didn't spend too much time familiarizing with the 1.2 codebase!  Sorry for=
 the mail.

I'm kind of at a standstill now though, because 1.2 doesn't have the=
 features I need (as mentioned below) or work on my server without=
 modifications, and 1.3 crashes my server in a weird way (=
 http://sourceforge.net/tracker/?func=3Ddetail&aid=3D1013350&group_id=3D6121&atid=3D=
106121 )... What to do... Anybody seen this PCRE crash before?

>From the bug report, this code crashes (which is a simpler version of what=
 my ConvertOldMarkup() does to the file OldTextFormattingRules during virgin=
 setup):
  $pat =3D "/\A((?:.|\n)*?)(^(?:[ \t]+\S(?:.*\s*\n[ \t]+\S)*|".
    "\|(?:.*\n\|)*|[#*;]*(?:[*#]|;.*?:)|\[\s*(\d+)\s*\]|".
    "<\?plugin(?:-form)?\b.*\?>\s*$|!{1,3}[^!]).*$)\n?/m";
  $subj =3D str_repeat("123456789 ", 50);
  preg_match($pat, $subj);

Ouch!

--
Dan Kamins

On Sat, 21 Aug 2004 10:34:12 +0200, Reini Urban wrote:
> Dan Kamins schrieb:
>> Hi guys. First of all, let me say that PhpWiki is great! I just
>> got into the Wiki world, evaluated a bunch of Wiki packages, and
>> almost immediately left the Wiki world in disgust until I found
>> PhpWiki, which is well-organized, efficient, straightforward, and
>> configurable.  Kudos. Now before I get too far down the path of
>> using it, there are a couple of changes I was going to request,
>> but I would actually be happy to do them myself and submit
>> patches.  So what I wanted to ask was a) how do you feel about
>> these changes, and b) how should I submit them.  It may be
>> possible these are already in the 1.3 branch, but I've only
>> installed and worked with 1.2 stable so far.  In fact, maybe
>> you've discussed and/or included these in 1.3, but I didn't see
>> either in the mail list archives or patch history.
>>
>
> All your requests are in the 1.3.x branch and much more. 1.3 is by
> far better, you'll like it!
>
> And please post to the mailinglist, not to the indidviduals.
>
>
>> 1. Superglobals...
>>
>>
>> As of PHP 4.2.0, register_globals went from ON to OFF by default.
>> Many servers operate in this new mode, which is far more secure
>> now. The effect is that PhpWiki doesn't work! And I'm *SURE* a
>> lot of users go through what I did: install 10 different Wiki
>> engines and evaluate them. When it doesn't work right out of the
>> box for mysterious reasons, you're going to lose a lot of
>> potential users. I had to dig deep to figure out what the problem
>> was, and I think a lot of people would just move on.
>>
>>
>> The problem manifests itself as the fact that you can't click on
>> anything because all the links are broken. It's easy to fix, and
>> just requires changing all global implicit vars to explicit
>> superglobal references. Like $DOCUMENT_ROOT becomes
>> $_SERVER['DOCUMENT_ROOT'].  A poor workaround is to slam a big
>> set of code up at the top of config.php that does something like:
>> if (isset($_SERVER['SERVER_NAME'])) $SERVER_NAME =3D
>> $_SERVER['SERVER_NAME']; if (isset($_SERVER['SERVER_PORT']))
>> $SERVER_PORT =3D $_SERVER['SERVER_PORT']; if
>> (isset($_SERVER['SCRIPT_NAME'])) $SCRIPT_NAME =3D
>> $_SERVER['SCRIPT_NAME']; ... The right way to do it is to just
>> reference the superglobal names directly.  This will break
>> compatibility with PHPs older than 4.1.0 (when superglobals were
>> introduces), but does anybody really use PHP that old?
>> There are a LOT of these variables in the source, but I am
>> volunteering to change them.
>>
>>
>> The motivation and history of this is clearly explained at this
>> link: http://us4.php.net/manual/en/security.globals.php
>>
>> I saw a discussion regarding this ("superglobals policy") on the
>> mail archives:
>> http://sourceforge.net/mailarchive/message.php?msg_id=3D2051713
>> Valid points were brought up, but that was almost 2 years ago,
>> and the world has changed a lot.  I think it's time to revisit
>> this issue (if it hasn't been yet).
>>
>> ---
>>
>>
>> 2. Author-Independent Archiving...
>>
>>
>> In 1.2 stable, only changes made by different authors get
>> archived and are thus diff-able.  So if I make a change, then
>> make another change, I lose my intermediate change history.
>> Maybe this is fine for many users, but I'm 100% other users would
>> like every change archived (as I am one of those users), and this
>> is functionality many other engines provide.  I propose adding a
>> config variable (like "ArchiveOnlyWhenAuthorChanges" defaulting
>> to TRUE, which would be same behavior as now) which would be
>> checked in savepage.php at the point of archiving the old data.
>> If set to FALSE, then every change would be archived.
>>
>>
>> ---
>>
>>
>> Thanks for listening.  Let me know what you think about these
>> issues and keep up the good work.

[Phpwiki-talk] Re: PhpWiki - Superglobals and Author-independent Archiving

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

Dan Kamins schrieb:
> Hi guys. First of all, let me say that PhpWiki is great! I just got
> into the Wiki world, evaluated a bunch of Wiki packages, and almost
> immediately left the Wiki world in disgust until I found PhpWiki,
> which is well-organized, efficient, straightforward, and
> configurable.  Kudos. Now before I get too far down the path of using
> it, there are a couple of changes I was going to request, but I would
> actually be happy to do them myself and submit patches.  So what I
> wanted to ask was a) how do you feel about these changes, and b) how
> should I submit them.  It may be possible these are already in the
> 1.3 branch, but I've only installed and worked with 1.2 stable so
> far.  In fact, maybe you've discussed and/or included these in 1.3,
> but I didn't see either in the mail list archives or patch history.

All your requests are in the 1.3.x branch and much more.
1.3 is by far better, you'll like it!

And please post to the mailinglist, not to the indidviduals.

> 1. Superglobals...
> 
> As of PHP 4.2.0, register_globals went from ON to OFF by default. Many servers operate in this new mode, which is far more secure now. The effect is that PhpWiki doesn't work! And I'm *SURE* a lot of users go through what I did: install 10 different Wiki engines and evaluate them. When it doesn't work right out of the box for mysterious reasons, you're going to lose a lot of potential users. I had to dig deep to figure out what the problem was, and I think a lot of people would just move on. 
> 
> The problem manifests itself as the fact that you can't click on anything because all the links are broken. It's easy to fix, and just requires changing all global implicit vars to explicit superglobal references. Like $DOCUMENT_ROOT becomes $_SERVER['DOCUMENT_ROOT'].  A poor workaround is to slam a big set of code up at the top of config.php that does something like:
>    if (isset($_SERVER['SERVER_NAME'])) $SERVER_NAME = $_SERVER['SERVER_NAME'];
>    if (isset($_SERVER['SERVER_PORT'])) $SERVER_PORT = $_SERVER['SERVER_PORT'];
>    if (isset($_SERVER['SCRIPT_NAME'])) $SCRIPT_NAME = $_SERVER['SCRIPT_NAME'];
>    ...
> The right way to do it is to just reference the superglobal names directly.  This will break compatibility with PHPs older than 4.1.0 (when superglobals were introduces), but does anybody really use PHP that old?
> There are a LOT of these variables in the source, but I am volunteering to change them.
> 
> The motivation and history of this is clearly explained at this link:
>   http://us4.php.net/manual/en/security.globals.php
> 
> I saw a discussion regarding this ("superglobals policy") on the mail archives:
>  http://sourceforge.net/mailarchive/message.php?msg_id=2051713
> Valid points were brought up, but that was almost 2 years ago, and the world has changed a lot.  I think it's time to revisit this issue (if it hasn't been yet).
> 
> ---
> 
> 2. Author-Independent Archiving...
> 
> In 1.2 stable, only changes made by different authors get archived and are thus diff-able.  So if I make a change, then make another change, I lose my intermediate change history.  Maybe this is fine for many users, but I'm 100% other users would like every change archived (as I am one of those users), and this is functionality many other engines provide.  I propose adding a config variable (like "ArchiveOnlyWhenAuthorChanges" defaulting to TRUE, which would be same behavior as now) which would be checked in savepage.php at the point of archiving the old data.  If set to FALSE, then every change would be archived.
> 
> ---
> 
> Thanks for listening.  Let me know what you think about these issues and keep up the good work.


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

Re: [Phpwiki-talk] How to output a non-HTML file from a plugin?

[Lea V. <vil...@cs...>]

On Friday 20 August 2004 15:32, Reini Urban wrote:

> so your CreateBib plugin has to generate an bibtex download action
> button also, which dumps the bibtex to the client.

OK, I created the button, but how can I refer to the contents
of that dynamic page as a whole? I understand that I need to 
call MailifyPage or something equivalent to strip the HTML, 
but that needs a page contents reference. How can I get it without
doing getPage(), getCurrentRevision(), getContents() sequence
which does not seem to work for dynamic pages.

Sorry if this is obvious, but this is my first PHP / PHPWiki effort. 
I really appreciate the help.

-- 
Lea 'LadyBug' Viljanen			Ignorance killed the cat,
Researcher, TuBE-project		curiosity was framed.
Univ. of Helsinki, Dept. of CS

Re: [Phpwiki-talk] How to output a non-HTML file from a plugin?

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

Lea Viljanen schrieb:

> On Friday 20 August 2004 13:04, Reini Urban wrote:
> 
> 
>>If you want to have everything in your plugin, look at the
>>lib/loadsave.php code.
>>MakeWikiZip() with the request argument pages="Page1,Page2,...".
> 
> 
> I made some experiments and also looked at PageDump plugin.
> 
> The problem is that I have a wiki page that is dynamically
> created by <?plugin CreateBib?> (this plugin invocation is the 
> whole contents of the page) and all the stuff having pagenames 
> as arguments do not seem to like that. At best with the zip method 
> I get the literal page contents but not the dynamically generated 
> bibtex stuff.

so your CreateBib plugin has to generate an bibtex download action 
button also, which dumps the bibtex to the client.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] How to output a non-HTML file from a plugin?

[Lea V. <vil...@cs...>]

On Friday 20 August 2004 13:04, Reini Urban wrote:

> If you want to have everything in your plugin, look at the
> lib/loadsave.php code.
> MakeWikiZip() with the request argument pages="Page1,Page2,...".

I made some experiments and also looked at PageDump plugin.

The problem is that I have a wiki page that is dynamically
created by <?plugin CreateBib?> (this plugin invocation is the 
whole contents of the page) and all the stuff having pagenames 
as arguments do not seem to like that. At best with the zip method 
I get the literal page contents but not the dynamically generated 
bibtex stuff.

-- 
Lea 'LadyBug' Viljanen			Ignorance killed the cat,
Researcher, TuBE-project		curiosity was framed.
Univ. of Helsinki, Dept. of CS

Re: [Phpwiki-talk] How to output a non-HTML file from a plugin?

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

Lea Viljanen schrieb:
> I have created a plugin that basically creates a bibtex file
> from a set of pages linked to a master page (*). It works and 
> currently generates a normal looking Wiki page with the
> bibtex entries.
> 
> However, since real bibtex files are not HTML files, I'd like 
> my plugin to output a plain text page instead of HTML so we
> could just save the file to the disk as such.  Generating
> a file to the Wiki server disk is not ideal, since all Wiki users 
> do not have file access to the server. 
> 
> Any hints?

Let the users download their pages with ?action=zip.
At the PhpWikiAdministration page.
If you want to have everything in your plugin, look at the 
lib/loadsave.php code.
MakeWikiZip() with the request argument pages="Page1,Page2,...".

> (*) Basically this is very idiotic functionality, i.e. read a list
>      of linked pages and extract sections of type
>     @whatever{...
> 	....
>     }
>     from each linked page.
> 


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

[Phpwiki-talk] How to output a non-HTML file from a plugin?

[Lea V. <vil...@cs...>]

I have created a plugin that basically creates a bibtex file
from a set of pages linked to a master page (*). It works and 
currently generates a normal looking Wiki page with the
bibtex entries.

However, since real bibtex files are not HTML files, I'd like 
my plugin to output a plain text page instead of HTML so we
could just save the file to the disk as such.  Generating
a file to the Wiki server disk is not ideal, since all Wiki users 
do not have file access to the server. 

Any hints?

(*) Basically this is very idiotic functionality, i.e. read a list
     of linked pages and extract sections of type
    @whatever{...
	....
    }
    from each linked page.

-- 
Lea 'LadyBug' Viljanen			Ignorance killed the cat,
Researcher, TuBE-project		curiosity was framed.
Univ. of Helsinki, Dept. of CS

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: Protected message
  Date: Wed Aug 18 11:07:46 2004
Any infected parts of the message (Counter_strike.com)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Counter_strike.com
Executable DOS/Windows programs are dangerous in email (Counter_strike.com)
No programs allowed (Counter_strike.com)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: New changes
  Date: Tue Aug 17 15:55:07 2004
Any infected parts of the message (Manufacture.scr)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Manufacture.scr
Windows Screensavers are often used to hide viruses (Manufacture.scr)
No programs allowed (Manufacture.scr)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: RE: Protected message
  Date: Tue Aug 17 13:41:25 2004
Any infected parts of the message (Manufacture.com)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Manufacture.com
Executable DOS/Windows programs are dangerous in email (Manufacture.com)
No programs allowed (Manufacture.com)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: Hidden message
  Date: Mon Aug 16 16:11:53 2004
Any infected parts of the message (Details.scr)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Details.scr
Windows Screensavers are often used to hide viruses (Details.scr)
No programs allowed (Details.scr)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: RE: Message Notify
  Date: Mon Aug 16 13:59:19 2004
Any infected parts of the message (Readme.hta)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Readme.hta
HTML archives are very dangerous in email (Readme.hta)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: Re: Incoming Message
  Date: Sun Aug 15 17:29:32 2004
Any infected parts of the message (Your_complaint.hta)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Your_complaint.hta
HTML archives are very dangerous in email (Your_complaint.hta)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: RE: Incoming Msg
  Date: Sun Aug 15 13:04:06 2004
Any infected parts of the message (Your_complaint.vbs)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Your_complaint.vbs
Visual Basic Scripts are dangerous in email (Your_complaint.vbs)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: RE: Protected message
  Date: Sat Aug 14 17:32:22 2004
Any infected parts of the message (You_are_dismissed.cpl)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file You_are_dismissed.cpl
Control panel items are often used to hide viruses (You_are_dismissed.cpl)
No programs allowed (You_are_dismissed.cpl)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support

[Phpwiki-talk] Warning: E-mail viruses detected

[MailScanner <pos...@ba...>]

Our virus detector has just been triggered by a message you sent:-
  To: sa...@pc...
  Subject: Re: Yahoo!
  Date: Fri Aug 13 13:27:38 2004
Any infected parts of the message (Nervous_illnesses.exe)
have not been delivered.

This message is simply to warn you that your computer system may have a
virus present and should be checked.

The virus detector said this about the message:
Report: >>> Virus 'W32/Bagle-AA' found in file Nervous_illnesses.exe
Executable DOS/Windows programs are dangerous in email (Nervous_illnesses.exe)
No programs allowed (Nervous_illnesses.exe)


-- 
MailScanner
Email Virus Scanner
www.mailscanner.info
Mailscanner thanks transtec Computers for their support