Hi, Dmitriy!

Thanks a lot. I´m  doing this conversion from tag to parser function not only with FileProtocolLinks extension, but also with SyntaxHighlight_GeSHi, so that I´m able to output semantic properties as highlighted source code.

I'm almost there! I converted both extensions according to your suggestions, but now the only problem I have in both of them is how to omit the "[[propertyname::" and "]]" from the output.

In my previous FileProtocolLinks example, I have in a template
{{#file: [[path: {{{path}}}]] }}

and, in a page which uses this template and has path=c:\whatever\foo.txt, I get the link to
file:///[[path::c:/whatever/foo]], with caption [[path::c:/whatever/foo]]
instead of
file:///c:/whatever/foo, with caption c:/whatever/foo

If I change my template to {{#file: {{{path}}} }}, ommiting the brackets and the prefix, everything works perfectly with FileProtocolLinksExtension, but on my modified version of SyntaxHighlight_Geshi the source is in a "text" variable and needs the prefix to be correctly rendered in a textarea of a form, instead of a textfield.

So, do you know if is that possible to fix this?

Here is my actual renderFileProtocolLink function, I´ve played with 'noparse' and 'isHTML' values, but no changed in the result.

function renderFileProtocolLink(&$parser, $input, $param2 = '')
{
    global $wgParser;

    $exploded = explode('|', $input);
    $uri = htmlentities($exploded[0], ENT_COMPAT, "UTF-8");

    if (!isset($exploded[1]) || empty($exploded[1])) {
        // no linktext has been specified ==> use the URI as linktext
        $linktext = $uri;
    }
    else {
        $linktext = htmlentities($exploded[1], ENT_COMPAT, "UTF-8");
    }

   $linkResult = sprintf('<a style="color:green" href="file:///%s">%s</a>',
        $uri, $linktext);

   #
   #
$linkResult here is c:\whatever\foo 
   #

  return array($linkResult, 'noparse' => false,'isHTML' => true);
}

[],
Matheus

CNIT escreveu:
28.12.2009 21:27, Matheus Garcia Barbosa de Figueiredo пишет:
Thanks again, Dmitriy!

I've converted the extension code to be a parser function, and now the semantic property was expanded! But there´s still on issue, now I´m getting the HTML code corresponding to the link as a string in the text, instead of having a link in the file.

Eg, I can see the text "<a href='c:\whatever\foo.txt'>c:\whatever\foo.txt</a>" in the page that uses {{#file:c:\whatever\foo.txt }}. This didn´t happen when the extension were using tags.

I´m looking at parser.php, but, as it´s a little big, I´d appreciate any help to try to fix this issue.

I´m posting below my modified version of the FileProtocolLinks extension

$wgExtensionFunctions[] = 'registerFileProtocolLinks';
$wgHooks['LanguageGetMagic'][]       = 'registerFileProtocolLinks_Magic';

function registerFileProtocolLinks() {
    global $wgParser;
    $wgParser->setFunctionHook('file', 'renderFileProtocolLink');
}
function registerFileProtocolLinks_Magic( &$magicWords, $langCode ) {
        $magicWords['file'] = array( 0, 'file' );
        return true;
}
function renderFileProtocolLink(&$parser, $input, $param2 = '') {
    $exploded = explode('|', $input);
    $uri = htmlentities($exploded[0], ENT_COMPAT, "UTF-8");

    if (!isset($exploded[1]) || empty($exploded[1])) {
        // no linktext has been specified ==> use the URI as linktext
        $linktext = $uri;
    }
    else {
        $linktext = htmlentities($exploded[1], ENT_COMPAT, "UTF-8");
    }

    $linkTextW=$parser->recursiveTagParse( $linktext );
    return sprintf('<a style="color:green" href="file:///%s">%s</a>',
        $uri, $linkTextW);
}

[],
Matheus

Hi Matheus!
You may try to fix this by some of the following options:
1. Remove or comment the "manual" expansion line: $parser->recursiveTagsParse(). The inner context should already be expanded automatically for parser functions (not tags).
2. If you want to preserve the output of your function as html, try to return not a string, but an array instead:
http://www.mediawiki.org/wiki/Manual:Parser_functions#Controlling_the_parsing_of_output
with 'noparse' and / or 'isHTML' elements.

It may be not necessary to take all steps. First of all, I would try to remove recursiveTagsParse(). If that wouldn't help, try to "protect" the output with array (step 2).
The parser of MediaWiki is large and quite complex, there are not many experts on that. Even SMW originally has some troubles until Daniel Friesen had patched it. I know only two experts of parser, Tim Starling (an author and extremly busy man) and Daniel Friesen. If nothing helps, try to mail Daniel, he was subscribed to this list.
Dmitriy

--

Matheus Garcia Barbosa de Figueiredo
Tel.: (31) 2108 - 7018
Analista de Sistemas
Gerência de Desenvolvimento de Sistemas - GDS
Gerência-Geral de Sistemas de Informação - GSI
Assembleia Legislativa de Minas Gerais - ALMG