phpwiki-talk

RE: [Phpwiki-talk] Root directories vs. subdirectories

[Martyn D. <ma...@dr...>]

Jeff,

Firstly many thanks for your reply.  Based on what you've said below, I
think the easiest thing that I can do would be to install PHPwiki under it's
own subdirectory of /wiki and in the root directory have an immediate HTTP
redirect to point to http://xxx/wiki.  This way, everything remains nice and
neat and doesn't involve any hacking about with the files, etc.

Regards,

	Martyn

-----Original Message-----
From: Jeff Dairiki [mailto:da...@da...]
Sent: 22 November 2002 16:17
To: Martyn Drake
Cc: php...@li...
Subject: Re: [Phpwiki-talk] Root directories vs. subdirectories


> I'm attempting to install phpwiki-1.33 into the root directory of my
> virtual web server (which is running Apache 1.3.27).  Note that it is
> the root directory and not some kind of /wiki or /phpwiki derivative.

I think I remember hearing some reports of some people being at least
partially successful doing that, but I'd recommend against it.

Where PhpWiki is installed (assuming USE_PATHINFO is on), it takes
over the entire URL-space.   If you install PhpWiki under /wiki, every
URL beginning with /wiki is a wiki page (or operation on one).
If you install PhpWiki under /, then every URL on your
host refers to a wiki page.  There's no place left
(without hackage) to put style sheets, icons, or anything
else that's not a wiki page.  (A request for /phpwiki.css
is interpreted as a request for the wiki page titled
'phpwiki.css'.)

Certainly PhpWiki was not designed with that usage in mind.

That said, here's a couple ideas:

Idea 1:

Recognize certain extensions (.css, .gif, .jpg) as non-wiki page.
Use mod_rewrite rules to differentiate between those special
URLs, and everything else.

Idea 2:

Put all the non-wiki page things on a different (possible virtual)
host.  (Or a (virtual) server running off a different (non-standard)
port.)



Not having attempted either, I like the second idea better...

In either case, you'll have to become familiar with the
configure options in part 5 ("URL options") of index.php
--- most of them will probably require manual configuration...


Write back if you get stuck.
If you get it to work, please write up a short howto...

Re: [Phpwiki-talk] Root directories vs. subdirectories

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

> I'm attempting to install phpwiki-1.33 into the root directory of my
> virtual web server (which is running Apache 1.3.27).  Note that it is
> the root directory and not some kind of /wiki or /phpwiki derivative.

I think I remember hearing some reports of some people being at least
partially successful doing that, but I'd recommend against it.

Where PhpWiki is installed (assuming USE_PATHINFO is on), it takes
over the entire URL-space.   If you install PhpWiki under /wiki, every
URL beginning with /wiki is a wiki page (or operation on one).
If you install PhpWiki under /, then every URL on your
host refers to a wiki page.  There's no place left
(without hackage) to put style sheets, icons, or anything
else that's not a wiki page.  (A request for /phpwiki.css
is interpreted as a request for the wiki page titled
'phpwiki.css'.)

Certainly PhpWiki was not designed with that usage in mind.

That said, here's a couple ideas:

Idea 1:

Recognize certain extensions (.css, .gif, .jpg) as non-wiki page.
Use mod_rewrite rules to differentiate between those special
URLs, and everything else.

Idea 2:

Put all the non-wiki page things on a different (possible virtual)
host.  (Or a (virtual) server running off a different (non-standard)
port.)



Not having attempted either, I like the second idea better...

In either case, you'll have to become familiar with the
configure options in part 5 ("URL options") of index.php
--- most of them will probably require manual configuration...


Write back if you get stuck.
If you get it to work, please write up a short howto...

[Phpwiki-talk] Root directories vs. subdirectories

[Martyn D. <ma...@dr...>]

Hi,

I'm attempting to install phpwiki-1.33 into the root directory of my virtual
web server (which is running Apache 1.3.27).  Note that it is the root
directory and not some kind of /wiki or /phpwiki derivative.  The problem is
that the themes are not being picked up.  There are broken images and no
background image is displayed.  However, the Wiki appears to be fine in all
other respects.  Installing phpwiki-1.33 into a subdirectory from the web
server's root, all themes and images work fine.

Is there anything that can be done to ensure that the theme funtionality
works within the server's root directory as well as whatever subdirectory
that is chosen?  I'd ideally like to use my Wiki as the frontend to my web
site.

Many thanks,

	Martyn

Re: [Phpwiki-talk] weird linking bug

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

> anyone got a clue on how this is happening?

Yes.  (And I just fixed it.)  (It's only an issue in the CVS code:
this should be happening in 1.3.3 or earlier releases...)

The patch is:
http://cvs.sf.net/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/lib/InlineParser.php.diff?r1=1.16&r2=1.17


The cause of the trouble was:

A few weeks ago, I got rid of the old markup engine --- instead
old markup is run through a filter to convert it to new markup,
which is fed to the new-markup engine.   As part of the conversion,
'~' is (correctly) converted to '~~'.  (In the new markup '~' is a
magic escape character which causes the following character to
be treated literally, no matter what context.)

The new markup code was not properly de-escaping the magic ~ escapes
within links...  that's now fixed.

NOTICE: This is going to break any existing new markup pages
with ~'s in links.


Thanks for the report!
Jeff

[Phpwiki-talk] weird linking bug

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

I can't think of anything I may have changed that could cause this, but 
alas it happens:

when I enter a url either as http://www.somewhere.com/~user] or 
[http://www.somewhere.com/~user] or [a link | 
http://www.somewhere.com/~user] the tilde is gettting doubled.. ie 
converted to: http://www.somewhere.com/~~user

however, if I just use a ~ outside of a link, it isn't being doubled.

anyone got a clue on how this is happening?

cheers
a

Re: [Phpwiki-talk] HTML in plugins

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

> I believe the HTML object is Jeff's own creation so it is really part 
> of PhpWiki. It is fantastic to work with, I would like to see it become 
> part of PHP!

Thanks!

I use the Xml/HtmlElement is a couple other personal projects,
but I think PhpWiki is the only public release...

To give proper credit, most of the ideas come from Perl's
HTML::Element module (by Gisle Aas.)

Re: [Phpwiki-talk] HTML in plugins

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

I believe the HTML object is Jeff's own creation so it is really part 
of PhpWiki. It is fantastic to work with, I would like to see it become 
part of PHP!

The code is in lib/XmlElement.php and lib/HtmlElement.php and is used 
throughout PhpWiki. The other plugins make good examples, they are a 
good place to start to learn a little more how it works.

Carsten

p.s. oops, probably you already noticed a mistake in my code:
-    $MOTD = explode("\n", htmlentities($MOTD)); // make an array to
+    $MOTD = explode("\n", $MOTD); // make an array to

On Tuesday, November 19, 2002, at 08:37  pm, Loyd Goodbar wrote:

> Thanks, that worked nicely. Is the html object part of PHP now, or is 
> it part
> of PEAR? Where can I find more?
>
> Thanks,
> Loyd
>
> On Tue, 19 Nov 2002 00:41:39 -0500, Carsten Klapp
> <car...@us...> wrote:
>
>> Hi Loyd,
>>
>> Yes the HelloWorld plugin comments are a little vague and out of date,
>> the returned value should now use the HTML class functions not raw
>> strings. Try something like this:
>>
>>     $MOTD = "One moon shows in every pool;\nIn every pool, the one
>> moon.";
>>     $MOTD = explode("\n", htmlentities($MOTD)); // make an array to
>> walk through later
>>
>>     $html = HTML(); // new HTML object
>>     foreach ($MOTD as $line)
>>         $html->pushContent($line, HTML::br()); // add each line to the
>> html object
>>
>>     $html->unshiftContent(HTML::h2(_("Message of the Day")));
>>
>>     return $html;
>>
>> Carsten

Re: [Phpwiki-talk] HTML in plugins

[Loyd G. <lo...@bl...>]

Thanks, that worked nicely. Is the html object part of PHP now, or is it =
part
of PEAR? Where can I find more?

Thanks,
Loyd

On Tue, 19 Nov 2002 00:41:39 -0500, Carsten Klapp
<car...@us...> wrote:

>Hi Loyd,
>
>Yes the HelloWorld plugin comments are a little vague and out of date,=20
>the returned value should now use the HTML class functions not raw=20
>strings. Try something like this:
>
>     $MOTD =3D "One moon shows in every pool;\nIn every pool, the one=20
>moon.";
>     $MOTD =3D explode("\n", htmlentities($MOTD)); // make an array to=20
>walk through later
>
>     $html =3D HTML(); // new HTML object
>     foreach ($MOTD as $line)
>         $html->pushContent($line, HTML::br()); // add each line to the=20
>html object
>
>     $html->unshiftContent(HTML::h2(_("Message of the Day")));
>
>     return $html;
>
>Carsten

--=20
"Why, you can even hear yourself think." --Hobbes
"This is making me nervous. Let's go in." --Calvin
lo...@bl...  ICQ#504581  http://www.blackrobes.net/

[Phpwiki-talk] Problem with PHP 4.2.3?

[Martin G. <gim...@gi...>]

Hi everybody

My provider upgraded to PHP 4.2.3 some time ago, and that broke
PhpWiki with errors like this:

lib/FileFinder.php:161: Warning[2]: SAFE MODE Restriction in effect.
The script whose uid is 1332 is not allowed to access
/usr/local/lib/php owned by uid 0

Line 161 corresponded to the 'elseif (file_exists("$dir/$file"))' line
in _search() in FileFinder.php. I've now "solved" the problem my
putting a '@' in front of the file_exists() call to suppress the
warnings.

The strange thing is, that I dont' get these warnings on my local
server (running PHP 4.2.3 in Safe Mode)...

I also don't understand why it's necessary for PhpWiki to search for
PEAR files - doesn't PhpWiki provide it's own? Or is it done in the
hope that a newer version is installed on the server?

Oh, and then there was this little thing in stdlib.php where $i goes
beyond the end of the array:

Index: stdlib.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/stdlib.php,v
retrieving revision 1.130
diff -u -3 -r1.130 stdlib.php
--- stdlib.php  19 Oct 2002 21:04:58 -0000      1.130
+++ stdlib.php  19 Nov 2002 22:05:10 -0000
@@ -1089,7 +1089,7 @@
     $list = explode(',',$input);
     // expand wildcards from list of $allnames
     if (preg_match('/[\?\*]/',$input)) {
-        for ($i = 0; $i <= sizeof($list); $i++) {
+        for ($i = 0; $i < sizeof($list); $i++) {
             $f = $list[$i];
             if (preg_match('/[\?\*]/',$f)) {
                reset($allnames);

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] Arabic in the Wiki

[Tony L. <la...@is...>]

> (If not, what happens if you delete the first line?  Does
> the second line still get marked up as <pre>?)

Well, since you asked. 
So far I've crashed Mozilla twice trying to do that sort of thing (or 
just afterwards). Fun stuff. 

-T.L. 

Re: [Phpwiki-talk] Arabic in the Wiki

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

> In the case of the sample with two lines, 
> however, they don't line up. The bottom 
> line is set off to the right. 

http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=MultilingualWikiTalk

The second line is in an HTML <pre> element (which is why is
doesn't line up with the first line).
Are you sure there isn't a leading space on that line?
(If not, what happens if you delete the first line?  Does
the second line still get marked up as <pre>?)

Re: [Phpwiki-talk] Arabic in the Wiki

[Tony L. <la...@is...>]

On Tue, 19 Nov 2002, Jeff Dairiki wrote:

>   http://www.php.net/manual/en/pcre.pattern.syntax.php

Thanks!

> > one line of Arabic looked alright, but 
> > with two lines something is not right. 
> 
> Not being able to read arabic, could you describe more
> precisely what it is that's not right?

I am still learning about how arabic should be 
handled, but in the case of the two 
line sample, one would expect the words to line 
up with each other vertically within this page, 
at the left margin. It might be that they 
shouldn't line up at the left, but I suspect 
that this is the case here, as the single 
line sample does line up there, and as the page 
is essentially set up for ltr format (as far 
as I know). 
In the case of the sample with two lines, 
however, they don't line up. The bottom 
line is set off to the right. 

Further experiments seem to suggest that 
this might not be a Wiki thing, however. 
I will note my finding on that page, as 
I get a better grasp. 

There is some arabic on this Wiki page, 
btw. Wouldn't you know it; it's only 
a single ling :) 

http://www.wikipedia.org/wiki/Arabic_alphabet

Re: [Phpwiki-talk] Arabic in the Wiki

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

> where can we find out what the \b 
> means? just out of curiosity. 

\b is a "zero-width assertion" which matches a "word boundary":
the spot between a word character and a non-word character.

Documentation of PCRE (Perl-compatible regular expressions):
  http://www.php.net/manual/en/pcre.pattern.syntax.php
  http://www.perldoc.com/perl5.6/pod/perlre.html

> btw, 
> I put some Arabic in the Wiki. 
> one line of Arabic looked alright, but 
> with two lines something is not right. 

Not being able to read arabic, could you describe more
precisely what it is that's not right?

[Phpwiki-talk] Arabic in the Wiki

[Tony L. <la...@is...>]

Jeff, 

great fix for the TextSearch. 
can't find any oranges now, which 
is the way it should be (tangerines 
are usually better than oranges 
in Japan, anyway). 
where can we find out what the \b 
means? just out of curiosity. 

btw, 
I put some Arabic in the Wiki. 
one line of Arabic looked alright, but 
with two lines something is not right. 
Might not be a Wiki issue, but I thought 
I would send it this way, just in case. 

http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=MultilingualWikiTalk

Thanks. 

Tony Laszlo, Tokyo
http://www.issho.org/laszlo.html

Re: [Phpwiki-talk] More NewTextFormattingRules problems

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

> Why do two of these behave differently than just one of them?

Allowing (as the new markup does) for multiple paragraphs
(and other complex block level structures) within list items
complicates in subtle and insideous ways the markup of lists.

There's some discussion at:
  http://phpwiki.sourceforge.net/phpwiki/NewBlockMarkup
(See section "Tight vs Loose lists.")

I'm not really happy with the current solution, but the
alternatives proposed so far do not make me happier.
I suppose it's time to revisit the problem.


> Between that, and the bleeding bolds and italics when followed
by punctuation, ...

I think that problem has been fixed (recently) in CVS.
Patch at:
 
http://cvs.sf.net/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/lib/InlineParser.php.diff?r1=1.13&r2=1.14


If that's not the problem you're referring to, please complain again.

Re: [Phpwiki-talk] Bugs in the "oranges"

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

> When we search for orange
> 
> I get all words that have 
> "or" and all words that have "ange"

Thanks again for the report.  It's fixed in CVS.

Here's the patch:
http://cvs.sf.net/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/lib/TextSearchQuery.php.diff?r1=1.4&r2=1.5

Re: [Phpwiki-talk] Bugs in the "oranges"

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

> When we search for orange
> 
> I get all words that have 
> "or" and all words that have "ange"
> 
> Weird! Why is that? Can we fix it?

That is bizarre.  Dunno why it does that.
I'm sure it can be fixed.
I'll look at it tomorrow.

Thanks for pointing it out.

Re: [Phpwiki-talk] HTML in plugins

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

Hi Loyd,

Yes the HelloWorld plugin comments are a little vague and out of date, 
the returned value should now use the HTML class functions not raw 
strings. Try something like this:

     $MOTD = "One moon shows in every pool;\nIn every pool, the one 
moon.";
     $MOTD = explode("\n", htmlentities($MOTD)); // make an array to 
walk through later

     $html = HTML(); // new HTML object
     foreach ($MOTD as $line)
         $html->pushContent($line, HTML::br()); // add each line to the 
html object

     $html->unshiftContent(HTML::h2(_("Message of the Day")));

     return $html;

Carsten

On Monday, November 18, 2002, at 10:21  pm, Loyd Goodbar wrote:

> I just installed PHPWiki v1.3.3, and am very pleased with it so far. I 
> tried
> searching the archives, but they appear to be down at the moment.
>
> I'm trying to write a simple plugin for MOTD. I was under the 
> impression that
> HTML code I used in the plugin was not translated. For instance, if I 
> use this
> sample code in my plugin:
>
> function run($dbi, $argstr, $request) {
> // No arguments at this time
> // extract($this->getArgs($argstr, $request));
> $html = "One moon shows in every pool;\nIn every pool, the one moon.";
> $html = ereg_replace("\n","<br />",$html);
> return $html;
> }
>
> I expected to see the following in the wiki:
>
> One moon shows in every pool;
> In every pool, the one moon.
>
> However, I get this:
>
> One moon shows in every pool;<br />In every pool, the one moon.
>
> The source for which looks like this:
>
> One moon shows in every pool;&lt;br /&gt;In every pool, the one moon.
>
> Even replacing the HTML breaks with wiki line breaks (%%%) did not 
> work. (I
> thought wiki html transformation might still occur.)
>
> The note from the HelloWorld plugin states
> // Any text that is returned will not be further transformed,
> // so use html where necessary.
>
> This does not appear to be true.
> Is there a way to get line breaks from a plugin's text?
>
> Thanks,
> Loyd

[Phpwiki-talk] Bugs in the "oranges"

[Marjorie R. <mro...@ma...>]

Turns out both my brother and I submitted a recipe to my wiki that had an "orange" as an ingredient.

So the first thing my brother searched for on the wiki was "orange"

Alas, at both
http://www.rawfoodwiki.org/ 
 and even at
http://phpwiki.sourceforge.net/phpwiki/
(which won't come up for me at the moment)

When we search for orange

I get all words that have 
"or" and all words that have "ange"

Weird! Why is that? Can we fix it?

Sincerely,

Margie

[Phpwiki-talk] HTML in plugins

[Loyd G. <lo...@bl...>]

I just installed PHPWiki v1.3.3, and am very pleased with it so far. I =
tried
searching the archives, but they appear to be down at the moment.

I'm trying to write a simple plugin for MOTD. I was under the impression =
that
HTML code I used in the plugin was not translated. For instance, if I use=
 this
sample code in my plugin:

function run($dbi, $argstr, $request) {
// No arguments at this time
// extract($this->getArgs($argstr, $request));
$html =3D "One moon shows in every pool;\nIn every pool, the one moon.";
$html =3D ereg_replace("\n","<br />",$html);
return $html;
}

I expected to see the following in the wiki:

One moon shows in every pool;
In every pool, the one moon.

However, I get this:

One moon shows in every pool;<br />In every pool, the one moon.

The source for which looks like this:

One moon shows in every pool;&lt;br /&gt;In every pool, the one moon.

Even replacing the HTML breaks with wiki line breaks (%%%) did not work. =
(I
thought wiki html transformation might still occur.)

The note from the HelloWorld plugin states
// Any text that is returned will not be further transformed,
// so use html where necessary.

This does not appear to be true.
Is there a way to get line breaks from a plugin's text?

Thanks,
Loyd
--=20
"Why, you can even hear yourself think." --Hobbes
"This is making me nervous. Let's go in." --Calvin
lo...@bl...  ICQ#504581  http://www.blackrobes.net/

Re: [Phpwiki-talk] Re: fix files for PN; MyHeadlines

[Tony L. <la...@is...>]

On Mon, 18 Nov 2002, Jeff Dairiki wrote:

> > This is input as ISSHO-J, but appears as I SSHO-J. 
> 
> http://cvs.sf.net/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/lib/stdlib.php.diff?r1=1.72&r2=1.73

it was a feature. :) 
hadn't thought of that. 
the ln 530 fix works just fine. 

> > 2) PageHistory - Can't diff between two versions.  

> That looks to be a PN specific problem.   

Super, Jeff. 
Thanks. 

Tony Laszlo, Tokyo
http://www.issho.org/laszlo.html

Re: [Phpwiki-talk] Re: fix files for PN; MyHeadlines

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

> 1) Unwanted space in titles.  
> 
> This is input as ISSHO-J, but appears as I SSHO-J. 

Yes.  The wikiword splitter uses a bunch of (anglo-centric) heuristics
and is not perfect.  Leading A's or I's are assumed to be distinct
words, so are split.  (This is to handle things like IAteNewYork.)

The splitting is performed in the function split_pagename() in
lib/stdlib.php.  This patch makes the splitting slightly less
aggressive, and will fix the particular example you site:

http://cvs.sf.net/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/lib/stdlib.php.diff?r1=1.72&r2=1.73

You could disable all splitting by adding a line
   return $page;
at the top of the function body of split_pagename().


> 2) PageHistory - Can't diff between two versions. 
> http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=PageHistory&page=WikipnRss

That looks to be a PN specific problem.   (The wrong URL's
are being generated.)  Someone who knows the PN code will
have to look at that.
  
> I notice that the phpWiki site has a different look. 

(Actually, the main phpwiki wiki is the older code.
The demo and test wikis are running off of recent code.)

Re: [Phpwiki-talk] PHPwiki newbie questions/suggestions

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

Russ Miller schrieb:
> From: "Reini Urban" <ru...@x-...>
> 
>>A WikiFarm may share config variables, but not the page database.
>>So you have to setup an external user/group database table to share the
>>users and groups. But the page permissions are completely seperate.
> 
> 
> Generally, I like all the thinking going on for permissions. In the WikiFarm
> instance, it might be nice if there were a convenient way to map different
> wikis to permission groups.
> 
> Another thought I had for the WikiFarm -- it might be nice if different
> wikis could live separately, but in the same actual database. Commercial
> providers often only give you one db (in my case, one MySQL db) for a
> certain pricing point... maybe there could be a hack to give each separate
> wiki a prefix for table names? Does that seem reasonable? When I get around
> to my implementation (heh), I'd be happy to submit a patch to do so.

ISP's generally charge for a single Mysql DB Namespace
(like "username_%") and not for a single database. In that namespace you 
should have the CREATE permission.
So you may create the databases "username_wiki1", "username_wiki2", ...
Otherwise you will have to change the $DBParams['prefix'].

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

Re: [Phpwiki-talk] Re: fix files for PN; MyHeadlines

[Tony L. <la...@is...>]

changing 'dc:description' to 'description' in
 lib/plugin/RecentChanges.php satisfied the validator. 
http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=WikipnRss
I suppose that syndic8 will find the feed acceptable after 
a few days.  
Thanks for the tip, Jeff! 

There are two other minor irritations. 
I couldn't find mention of them among the "known bugs." 
They are minor, and we can live with them. 
But please let me know if there is a way to fix these, 
when you can spare a moment.  
Thanks very much. 

-------------------------------------------------------------

1) Unwanted space in titles.  
For example, on the following page. 
http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=ISSHO-J

This is input as ISSHO-J, but appears as I SSHO-J. 


2) PageHistory - Can't diff between two versions. 
http://www.issho.org/modules.php?op=modload&name=phpWiki&file=index&pagename=PageHistory&page=WikipnRss
 
I notice that the phpWiki site has a different look. 
Perhaps the older code in the module had this problem, and it was fixed? 

Re: [Phpwiki-talk] Re: fix files for PN; MyHeadlines

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

> ...syndic8 also finds fault with the phpWiki recentchanges feed from the
> ISSHO site... :( That's a bit of a bummer.  

Hi Tony,

I think this patch fixes the warning:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/lib/plugin/RecentChanges.php.diff?r1=1.67&r2=1.68

(Just change 'dc:description' to 'description' in
lib/plugin/RecentChanges.php.)

(I don't think that's what's causing the rest of your troubles with PN...)

> Sounds like the module rss feed issue is not only a matter of rss v0.9
> vs. 1.0. 

How so?