01067: WikiWords on included pages do not follow $EnableRelativePageLinks

Summary: WikiWords on included pages do not follow $EnableRelativePageLinks
Created: 2009-02-01 02:07
Status: Suspended - discussion, votes
Category: Bug
Priority: 33
Version: 2.2.0
OS: Unix/Apache2.2.1/PHP5.2.5

Description: When a page from group B is included within a page from group A, wikiword links are resolved as GroupA/WikiWord regardless of the setting of $EnableRelativePageLinks, while relative links enclosed in brackets correctly resolve to GroupA/WikiWord when $EnableRelativePageLinks = 0 and GroupB/WikiWord when $EnableRelativePageLinks = 1.

This problem is currently visible on the page http://solinvictus.stryck.com/PMTest/PMTest which includes the page Supplemental/PMTest.

We talked about in the chat room, I am copying here in case someone is interested in the discussion.

The problem is that such a solution needs to exclude PageVariables, PageTextVariables and normal links in brackets. Not very easy to achieve, especially when pmwiki can handle [[ WikiGroup . WikiLink ]] and even [[ (WikiGroup . ) WikiLink]] markup without problems. A conversion function cannot tell these are not free WikiWordLinks, too many possible combinations that are valid markup otherwise. I am not sure that this problem (WikiWordLinks fail cross-group) is fixable, I thought it was but I may be wrong.

For the moment, there are two workarounds:

  • use normal [[WikiLinks]] in brackets
  • use a Group/WikiWordLink which should display WikiWordLink but should work cross-group.

--Petko February 01, 2009, at 02:57 AM

After a little testing, it seems like inserting the following code

$QualifyPatterns["/\\b(?<![#&\\.\\/\\{:\\$`])($WikiWordPattern)(?=([^\\w]))(?!\\]\\]|[\\.\\/]($WikiWordPattern)(\\||\\]\\]))/e"] = "\$group.PSS('/$1')";

into config.php resolves the problem under normal markup conditions by qualifying instances of standalone WikiWords with their group names. It takes into account some obvious situations I imagined, like [WikiWord or WikiWord. or WikiWord/, but I'm sure there are even more persnickety exceptions that it doesn't catch.

-- charlequin

I am suspending this entry as there seems to be not much interest among the community. In fact, Relative Links were implemented years after WikiWord links had been disabled by default, and few wikis are likely to be affected by this inconsistent behavior. Thanks. --Petko July 08, 2009, at 09:21 AM

I came up with this problem in a fresh install few days ago. This behavior was really weird and I thought I was doing some mistake in the use of the include directive. I didn't realize this was caused by the use of plain WikiWords. I might not have enabled them if I had known before hand they could lead to this kind of inconsistency. Fortunately I found this thread; solution given by charlequin is working fine in my install at first glance. Just wanted to share my experience because other can have the same problem and I think this should be fixed. What kind of impact can have the inclusion of the $QualifyPattern presented by charlequin? --simkin November 29, 2011, at 09:42 AM

Warning: Using the above $QualifyPattern is not safe. I experienced problems in Site.AuthForm (interference with directives), the inclusion of Site.EditQuickReference (because of normal bracket links?) and others. This might have a difficult solution, as stated before. What a pity. --simkin November 29, 2011, at 10:26 AM