[Pmwiki-users] Comments on customizing pmwiki (suggestions,bugs)

Philip Jägenstedt philip
Wed Nov 3 05:56:37 CST 2004


Hello!

Over the last few weeks I've done some pretty brutal customizations to 
pmwiki at http://www.digifri.studorg.liu.se/wiki/en/wikifri . In the 
process I've found some things which aren't working for one reason or 
another, and things which could be improved. First I must say that I'm 
positively amazed with pmwiki -- I've been able to do all but very few 
customizations without touching pmwiki.php. This is what I've done:

Written a template which uses the common formatting function of my site. 
To do this I wrote intermediate functions since the passing of 
parameters in the <!--function:FunciontName--> syntax is rather limited. 
This works well. Improving the mechanism for passing arguments might be 
nice, but isn't a big deal.

Hacked multi-language support into pmwiki by letting the group names act 
as language identifiers. I've created some hacks to load XLPage for the 
language and had to work around some issues with DefaultPageTextFmt not 
being translated by doing
$DefaultPageTextFmt = XL('Describe [[$Group/$Title]] here.');
and also working around mixed languages in the RecentChanges pages by 
creating a CurrentTimeEn which is used for AllRecentChanges. Note that 
CurrentTime isn't being translated properly (this is in PITS), so I'm doing
$CurrentTime = strftime(FmtPageName('$TimeFmt',$pagename),$Now);

My translation directive is (thanks to help on #pmwiki)
Markup('translation','directives','/\\(:translation\\s*(\\S+)\\s*:\\)/e',
        "PZZ(\$GLOBALS['TranslationList'][]='$1')");
Then I have code to translate TranslationList into the translation 
format of the site globally, which integrates just beautifully.

This all works fine, but it's not completely clean. Perhaps adding 
customizable multilanguage capabilities to pmwiki would help other who 
want to do the same as me, although of course I'm not sure how it would 
work (using groups as languages is pretty ugly).

The last and perhaps most visible change is the look of the URIs. The 
members of our association felt strongly that URLs should be lowercase 
and not contain the letter ??? which are used in swedish, so for example 
what would be JagPlockarBl?b?r in an unmodified is not 
jag_plockar_blabar. For this I've written a WikifriMakePageName-function 
and disabled WikiWords. Problems arise when linking to [[jag plockar 
bl?b?r]]. This would previously have been a link to JagPlockarBl?b?r, 
but is now a link to a page where the case and special characters have 
been lost, disrupting workflow by forcing a user to set (:title Jag 
plockar bl?b?r:). To get around this I decided that when a link to a 
non-existing page is made, a title=... should be added to the 
querystring, which I then inspect and add the title-directive to the 
page automatically, a fair compromise I think. Visit the wiki and see 
the "jag plockar bl?b?r" link to see it in action. This is accomplished 
by setting
$LinkPageCreateFmt = "<a class='createlink' 
href='\$PageUrl?action=edit&title=\$URLEncodedTitle'>\$LinkText</a>";

and

$FmtP['/\\$URLEncodedTitle/e'] = "urlencode(ucfirst(\$FmtV['\$LinkText']))";

The title is then read in config.php as such:
if (isset($_GET['title'])) {
   global $PCache;
   $PCache[MakePageName($pagename,$pagename)]['title'] = $_GET['title'];
   $FmtP['/\\$EditText/'] = '(:title ' . $_GET['title'] . ':)';
}

This would work if it weren't for one thing. The %xx entities produced 
by urlencode interfere with the '%%' style markup. I don't know how to 
get around the problem, so for now I'm just commenting out
//Markup('%%','style','%','return ApplyStyles($x);');
in scripts/wikistyles.php
What happens is that when two or more %'s are in the output, some 
strangle <span class='...'> is inserted into the code. Probably what 
needs to be done is just change the pattern for '%%' to not capture 
entities of the form %xx, where x is a hexadecimal digit.

Also, to allow creating new pages without first linking to the, I wanted 
it so that if you visit /en/Jag_plockar_bl?b?r then the title of the 
page should be "Jag plockar bl?b?r" and the link to be created would 
then (automatically, due to my LinkPageCreateFmt) have the correct 
title. This has been the most troublesome change to make. What I needed 
was to set title to what was in the URL before it was parsed into a 
pagename. The only way I could find was adding in pmwiki.php
Just after configuration is loaded:
$Title = $AsSpacedFunction(preg_replace("!^$GroupPattern/!",'',$pagename));
In HandleBrowse, when DefaultPageTextFmt is used:
   else {
     // foolip: I added this
     global $PCache, $Title;
     $PCache[MakePageName($pagename,$pagename)]['title'] = $Title;
     $text = FmtPageName($DefaultPageTextFmt,$pagename);
   }

This is the most unpretty hack I've had to make, and I'd really 
appreciate a suggestion how to not have to edit pmwiki.php. If pmwiki 
could supply the unparsed title used in the URI in a variable that would 
be helpful, but that should only be used as the title when you get a 
DefaultPageTextFmt page. Having a callback function to call when a 
non-existent page is encountered and is not handled by PageNotFound 
could be the answer, for example HandleDefaultPage or something.

Finally, there seems to be a problem with search. When searching for /, 
not all pages are found, only the ones containing a /. I've tracked the 
problem down to pagelist.php where the regex in FmtPageList doesn't 
appear to be working as it should 
('/((?<!\\S)[-+]?[\'"].*?[\'"](?!\\S)|\\S+)/').
When there are not any options ($opt) a space will be inserted before 
the search string, and the preg_split will return ' ' as the first 
string (because it _wasn't_ matched). I've tried modifying the regex, 
but I think that it's very hard to get it working reliably by using 
preg_split with the PREG_SPLIT_DELIM_CAPTURE option. I did a quick hack 
be replaced $terms in the preg_split call by trim($terms) which actually 
makes it work, but this is something that needs to be fixed in a better way.

Final question: which, if any, of these problems can be fixed 
immediately, and which should I report to PITS?

I've also done some painless changes to different Page...Fmt-variables 
and changed the location of search and help.

Thanks for the great software, and for all the help I've gotten so far!
// Philip



More information about the pmwiki-users mailing list