TL;DR - why does Wordpress remove file:// from file links?
Our intranet page has a section containing icons with links behind them. All of a sudden (our guess is after an update), one of the links stopped working. The link is as follows (1):
<img src="/img/meetings.jpg" style="width:75px; height:75px;"/>
The expected behaviour (in Internet Explorer (2)) is that the file explorer opens, and points to the share \vmdata\meetings, which has always worked up until now.
When I hover over the icon image I see the following code however:
http://vmdata/meetings
and when I check the HTML by viewing the source of the page, I see that the file:// prefix is indeed gone:
<a href="//vmdata/meetings" target="_blank" rel="noopener noreferrer">
To work around this issue, I had a look at a page on which the original creator had added the same type of links. My idea was to create a similar page, copy the HTML code on the page and link the icon to said page. I added the page and HTML link but after viewing the page, the result is exactly the same: the file:// prefix is gone.
My guess is that something within Wordpress is rewriting/removing the file:// link. My question now is twofold: how do I stop this rewriting/removing behaviour, and/or how can I add a link to a fileshare as before?
PS: the creator of the website is no longer available, and the website is running yet unmanaged. Only content creators are left. We have no Wordpress knowledge in house, so we're basically just trying to keep the site up and running (in wait for a new site).
(1) I realise that pointing to a server share from an intranet site is a very ugly way to publish files. However, as stated before, we're in a situation of if it ain't broke don't fix it with this website, so we just want to go back to a working situation. Creating a page to link to (hosted) documents would be a lot better, but is for various reasons not feasible.
(2) please don't bother pointing out NOT to use Internet Explorer (anymore), we all know that but we are stuck with it because it is a requirement for one of the major tools we all use everyday. As long as that tool doesn't support other browsers, we're stuck with IE (unfortunately).
I found another question regarding this issue: can't save network share path as a link in wordpress 3.1
Apparently the correct way to add an allowed protocol into WordPress is to modify the functions.php file and add the following code:
function allowed_link_protocols_filter($protocols)
{
$protocols[] = 'file';
return $protocols;
}
add_filter('kses_allowed_protocols', 'allowed_link_protocols_filter');
More information can be found in the following article: https://developer.wordpress.org/reference/hooks/kses_allowed_protocols/
Adding the code above solved the problem for me, so I hope this helps others to solve similar issues in the future.
Related
Recently I've been tasked with redesigning a website for the current company I'm working at. I've been using weebly to make the site, and then exporting the HTML to be re-hosted on the company's servers.
However, I've noticed that some functionality in weebly's code has stopped working. I imagine this might be due to weebly hosting some elements on their own servers, but this is merely a beginners best guess.
1. The picture for the logo on the banner does not appear once the HTML is rehosted
For comparison, here's the site while hosted on weebly:
http://mjmacoustique.weebly.com/
and the site on the company's servers:
http://www.mjm.qc.ca/redesign2015/
When weebly hosts, the ''MJM'' image should be on the top left and function as a return to home page button when clicked. However, when it's hosted on the company's server, the image is not found.
2. On Firefox, the background image of the home page is replaced with an all black background
When opened in firefox, it fails to load the background image of the main page.
Any help or solutions to these problems would be greatly appreciated.
Thanks.
I can help with question #1: the logo is hosted on weebly's servers, but in the html it's written in a shortcut method like this example: /uploads/2/6/8/5/26851316/1434298489.png"
the easy workaround would be to keep the weebly version of the site working, in in the html change the src value of the missing images to something like this http://mjmacoustique.weebly.com/uploads/2/6/8/5/26851316/1434298489.png
So you haveto add the http://YOURSITE.weebly.com before all the src values of your images.
otherwise, just load all the images you need on a blank page of the site on your servers, copy image urls of those and replace the urls in the html with that.
Hope that helps?
The firefox issue might also be solved if all your src values are linked correctly but I cannot be sure about that.
When I tried exporting a site from weebly, some assets were missing from the zip it produced. This resulted in some images failing to appear because they simply weren't there. I don't know how often this happens (or if it happens only for some sites), but weebly's export feature definitely seems to have bugs.
I worked around this by using wget to recursively fetch the content that weebly was hosting. Then I hand-copied the missing assets (and only the missing assets) from the directory structure saved by wget and merged them into the directory structure from weebly's export zip. This is time-consuming, but necessary since the directory structure fetched by wget includes dynamically-generated content (meta data for weebly's editor, assets with decorated names, etc) that you probably don't want in the content you host elsewhere.
Every other website I visit, the inspector works as expected:
But in many of the sites I'm editing within apache server (using xampp) somehow they doesn't show the "filename.css:lineNumber" data
Also, every change I try to do in the inspector in thse sites, doesn't do anything to the code shown in the source tab.
I've tried refreshing, hard refreshing with cache, closing and opening the tab, closing and opening chrome again. The same problem occurs.
In other sites the inspector works well, but not in many of the localhost sites.
Has someone experienced this before? Is there a way to fix this?
If you are using a client-side CSS generator library such as Lea Verou's excellent -prefix-free or client-side Less, you will not see source information as it has all been processed and reinjected as style elements.
Client-side Less has a property [dumpLineNumbers] to include source line info as a comment in the generated source. (I'm not sure if this will display in Chrome's inspector - but I think it might)
The only "fix" I know of for -prefix-free is to temporarily remove it, obtain the source info for reference, then put it back in.
I have had the exact same problem (not using a css generator), and it appears to be a known bug with the current version of Chrome, the solution is to use the more up to date Beta version known as Chrome Canary - Here's the link :)
https://www.google.co.uk/intl/en/chrome/browser/canary.html
Try to check what the format of your CSS file is. I had the same trouble with the UNIX and Macintosh formats. For example, try to open you CSS file in Notepad++ and in the bottom right corner of the window you'll see your current format. If you see UNIX or Macintosh there, click it with the right button of your mouse and change to DOS/Windows. Then save your file and refresh your page in Chrome. It definitely helped in my case.enter image description here
I have a really simple piece of CSS which is applying a background image to <li> elements
.icon-facebook { background: url("./images/icon_facebook.png") no-repeat; }
This works fine when I view it locally, without a web server, i.e. by double-clicking the .html file.
But as soon as I serve the same page via Apache - whether on localhost or a production server - the background images disappear.
Other background images on the page work fine - and all have identical (relative) paths.
Specifying an absolute path to the background-images does not work either.
Renaming the files did not work.
The images can be displayed just fine if navigated to directly in the browser.
Monitoring Apache's access log, the browser doesn't even attempt to request the images (!), even if an absolute URL is supplied in the CSS.
When I inspect the <li> Firebug says "could not load the given URL" but when I copy and paste the background-image URL straight from the CSS in Firebug into a new tab - guess what? It works.
I have a <div> on the same page with a different background image from the same folder which works just fine. When I replace its filename with one of my "problem" files I notice it isn't displayed any more.
The images in question are 20x20px PNGs (but I tried JPGs too).
All other browsers work fine.
This is truly driving me crazy.
Unbelievable. Truly unbelievable.
The culprit was Adblock Plus, which I had installed on Firefox but not any other browser. It was interpreting the names and/or class names of the background images as being either advertisements or social media annoyances, and therefore silently blocking them.
I had previously added my production domain to its white list, but when it changed I forgot to update it.
That explains why some image filenames worked (e.g. icon_f.png whereas others - icon_fb.png or icon_facebook.png - did not).
Let this be a lesson - do not run any kind of addons on your development browser.
I was ready to cry... and think I will now. Cry for my stupidity.
Thank you to all for your input.
Specifically, the culprit is Fanboy's Social Blocking List, which is one of the filter subscriptions included in Adblock Plus. It has already caused me a lot of distress in the past.
To disable it, click on the Adblock Plus toolbar button and choose Open filter preferences. You'll then find the list of subscriptions and you can simply unsubscribe to that one.
It's better than disabling Adblock Plus completely so you can continue using it for what it was originally intended: blocking ads.
I am currently building an asp intranet site.
There are various helpful links that I need to include and some of them happen to be .xls files that are located on a local network within the company.
I link these documents just like I would any word docs (which work fine by the way).
<span>Schedule</span>
The link above works if I simply copy and paste the raw address into my browser (a pop-up window comes up asking me to open the file in Excel). But when I make this a link on the intranet site and try to click on it, nothing happens. I can see the link when I hover over it on the status bar but that's it. It is non-clickable. Anyone have any idea what is causing this and how to fix it?
I should mention that two of these .xls files are password-protected but one of them is simply a read-only file which can be opened by anyone.
I am 100% sure this has nothing to do with css styling because the same thing happens in the current (old) intranet site made by someone else and I use these links on different menu bars as well.
I think you use wrong syntax for shared files, try this:
file:///P:\-Projects-\SCHEDULE.xls
Backslashes are still valid for the path part. Moreover, I'm not sure whether Sharepoint may recognize correctly path to most likely network drive P:.
For me such link to local share works:
file:///\\fs-1\Install\Windows\Servers\DB\MSSQL\SQL2005\en_sql_server_2005_service_pack_4_x64.exe
The solution to this problem is to add the site to the "Trusted Sites" list.
Opening intranet files without the user knowing is considered a secruity threat.
In IE go to Internet Options -> Security -> Trusted Sites then add the site.
http://answers.microsoft.com/en-us/ie/forum/ie9-windows_7/after-latest-update-ie-wont-open-network-file/172e4ac3-1c1f-4948-8a3f-c8c344eae06d
I'm trying to provide a link to chrome://newtab (the new tab page) for my distraction-preventing page for when I need to access it, however clicking the link gives the error Failed to load resource.
I've tried:
Linking to it using <a href="chrome://newtab">
Attempting to redirect the user using window.location.
The chrome: prefix aliases to chrome:// but still fails to load.
Does anyone know if this is possible or has any ideas to try?
I am not sure why it doesn't work, but I think it is for security reasons.
Pages on the internet should not have access to local resources and the new tab page is a local resource.
Format your link thusly (also will work with firefox and other tabbed browsers):
Click me
EDIT: of course, that's not actually the new tab page. It's just a blank tab. Going to leave it anyways.
I think you'll have to write a Chrome extension to get access to the chrome://newtab link, it doesn't seem possible for an ordinary webpage to access it.
Edit: This solution no longer works, but I'll leave it for anyone that might try to hunt down why it stopped working.
I finally found that https://www.google.com/_/chrome/newtab will open chrome://newtab, thanks to this post.
Don't ask me why.