logo       

Re: [pmwiki] Re: broken wiki links on home page fer an instalaltion: msg#00114

web.wiki.pmwiki.user

Subject: Re: [pmwiki] Re: broken wiki links on home page fer an instalaltion

Patrick R. Michaud wrote:

> So, I have an alternate solution. Instead of creating another special
> function call to replace what FmtPageName is trying to do in the first
> place, I've simply modified FmtPageName to allow some last-minute
> rewriting of any string containing '$ScriptUrl/' to put the pagename


Thanks. This is a great approach, IMHO much better than my function driven
approach. Am I right that pmWiki would then rewrite any link regardles where
it comes from (an FmtVariable, a function, link in a wiki page, or even
within php-script)?

Would it also rewrite links where $ScriptUrl is already resolved?

With $ScriptUrl= http://www.mywiki.com/wiki/pmwiki.php

<a href="http://www.mywiki.com/wiki/pmwiki.php/foo/bar?action=edit";>

will be rewritten to

<a
href="http://www.mywiki.com/wiki/pmwiki.php?pagename=foo/bar&action=edit";>

Very good approach.


> At the moment the code for converting '$ScriptUrl/' is hardwired in
> FmtPageName. If someone needs the conversion itself to be
> customizable,
> I can arrange it.
>

I guess on the first hand this should mainly be sufficient, because the
problem comes by $ScriptUrl.

> Finally, note that very little of the URL syntax is actually
> "hardwired".
> I think there's only two places (in pmwiki.php:HandleDiff and
> upload.php:FmtAttachLink) where the URL syntax is currently fixed by
> the code--all of the other URLs are controlled by configurable
> variables. However, I'll grant that reassigning all of those
> variables could be
> a pain to manage, which is why I've gone the $ScriptUrl/ replacement
> route. :-)
>

Fully agree. It makes installation of pmWiki on a non-Path_info system very
easy. I will do it tonight on the schlund server.


Bernhard





<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise