Talk:UNC links
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>
- 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)
template doesnt seem to work...
editthe 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!
In localsettings.php set $wgPFEnableStringFunctions = true; Bob.spencer (talk)
I'm having the same problem and the same result as described here with MW 1.23.6 and PHP 5.4. I have $wgPFEnableStringFunctions = true; in LocalSettings.php as Bob pointed out. Tried $wgUrlProtocols[] = "file://"; too, to no avail. Pompelpilt (talk) 10:29, 14 April 2015 (UTC)
To Resolve the problem
editPHP 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 ) {
Encoding still a problem
editI'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:
No one else
editI'm using php 5.3.0 / mediawiki 1.15.4 / -> unc does not work...
It doesn't work for me either....
extension doesn't work with Google Chrome
editI installed the extenstion for our internal wiki and when using it with Google Chrome it doesn't work.
- Try installing this extension: LocalLinks
resolving the | |%20}}|\|/}} issue
editI 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
To use these functions in the ParserFunctions extension (as of r50997) you need to set $wgPFEnableStringFunctions = true; in LocalSettings.php.
Using MW 1.24.2 I found that the '| |' part of the template can be changed to just '||'. The parser code sees that no character has been given and assumes a space. The template then displays correctly.
Secondly, I have found that spaces anywhere in the UNC address/name (in the wikitext) also causes problems, but by removing them then the link displays correctly on the page. The problem, of course, is that the link is now invalid. It seems that the handling of spaces is generally the problem, but I'm not sure where that occurs (probably deep in MW somewhere).
--141.163.60.243 15:38, 25 August 2015 (UTC)
My mistake. Using UNC's, including spaces, works fine with 1.24.2 provided you put the '$wgPFEnableStringFunctions = true;' after the extension name specification :-)
--141.163.60.243 11:58, 26 August 2015 (UTC)
This fixed all issues for me as well. Thanks! MediaWiki 1.26.1, PHP 5.4.16 --Chazbot7 (talk) 16:09, 7 March 2016 (UTC)
Can´t save template
editI´ve done everything good so far, but when editing the template and saving I get error call_user_func_array how do i solve this?
Can we replace the default "1" if no description is enter?
editAll is describe in title. I want to write something else instead of "1" is I don't enter a description.
Thanks