Talk:UNC links

From MediaWiki.org
Jump to: navigation, search

A proposed replacement that should generate XHTML-compliant links for both IE and FF:

[file:///{{#replace:{{#replace:{{{1}}}| |%20}}|\|/}} {{#if:{{{2|}}}|{{{2}}}|{{{1}}}}}]

The last part just displays the link's address if no display text was specified. You can take out the |{{{1}}} if you prefer the anonymous (numbered) links instead.

Are you sure that backslashes are invalid in XHTML links? I put the following code into the W3C HTML Validator, and it passed:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">
<head><title>Test</title></head>
<body><a href="file:///C:\Test">Test link</a></body>
</html>
--Ed Brey 12:59, 18 September 2008 (UTC)
No, I'm not sure, I got a warning about replacing backslashes with slashes from the HTML Validator extension (based on HTML Tidy). --IByte 24 Sep 2008 9:00 UTC
Tidy doesn't give any help on that warning within the validator, but I think I see where it's coming from. RFC 1738 section 3.10 says this:
   A file URL takes the form:

       file://<host>/<path>

   where <host> is the fully qualified domain name of the system on
   which the <path> is accessible, and <path> is a hierarchical
   directory path of the form <directory>/<directory>/.../<name>.
This leaves some ambiguity with what to do with UNCs. In the UNC \\Host\Folder, if you create a URI file://Host/Share, it doesn't work on Firefox 3. However, the URI file:///\\Host\Share does. IE7 automatically converts the latter form to the former. Both browsers convert the backslashes to slashes. Backslashes are good because they make it obvious in the source that a UNC is intended. Slashes are good because they make the source most closely match what the browser ends up with and they keep Tidy happy. In the balance, I'd say that converting to slashes is the best approach. --Ed Brey 11:18, 26 September 2008 (UTC)
I think that anonymous links are preferable to reproducing the URI in the visible text so that file hyperlinks are consistent with other hyperlinks in terms of formatting. The same rationale that applies for not showing the raw URI for a typical HTTP URI would apply to not showing the raw UNC. --Ed Brey 11:23, 26 September 2008 (UTC)

Contents

[edit] template doesnt seem to work...

the template is giving me some troubles.

i used

[file:///{{#replace:{{#replace:{{{1}}}| |%20}}|\|/}} {{#if:{{{2|}}}|{{{2}}}}}]

which when the template is saved it looks like this:

|%20}}|\|/}}

and it recodes this

{{unc | \\server\share | test}}

so that it appears as

\\server\share | |%20}}|\|/}} test

and redirects to

file:///{{#replace:{{%23replace:

please help!

[edit] To Resolve the problem

PHP 5.3 seems to be more strict with handing over of values/references. In this case the culprit probably is Language.php. Try to change

  • - function getMagic( &$mw ) {
  • + function getMagic( $mw ) {

[edit] Encoding still a problem

I'm using PHP 5.2.6-1+lenny4 and I'm getting the previous users error in which | |%20}}|\|/}} is added to the URL creating the following URL: file:///%7B%7B#replace:%7B%7B#replace:

[edit] No one else

I'm using php 5.3.0 / mediawiki 1.15.4 / -> unc does not work...


[edit] extension doesn't work with Google Chrome

I installed the extenstion for our internal wiki and when using it with Google Chrome it doesn't work.

[edit] resolving the | |%20}}|\|/}} issue

I was having the same issue with this in MediaWiki 1.17, and it turns out it needs Extension:StringFunctions to be available (for the #replace function to work). Note that this extension has been mostly integrated into Extension:ParserFunctions and needs to be enabled separately. -fai

Personal tools
Namespaces
Variants
Actions
Site
Support
Download
Development
Communication
Print/export
Toolbox