Here is my Code of Addthis:
<script type="text/javascript" src="addthis_widget.js"></script>
<script type="text/javascript">
var addthis_config = {
services_expanded: 'facebook, twitter'
}
</script>
<a addthis:services_compact="facebook,twitter" addthis:services_expanded="facebook,twitter" addthis:url="#" class="addthis_button" href="#"><img id="btn_share" name="btn_share" style="cursor:pointer;" src="path to image" alt="Share" /></a>
If I put this Addthis code in simple HTML file and try to run through any server for example in my case I'm using Apache. And try to run from the browser through localhost/myaddthis.html, than its work fine (show the proper popup to share specific link to facebook and twitter).
But the problem is: when I try to run simple html file direct inside browser, then its just show the image, don't show the proper addthis share popup.
It's just a simple .HTML file (there is no server side code inside the file), than why its not running without server.
I want to use this code without server. How I do that?
You're probably viewing your pages by opening them as local files rather than loading them from a web server. So instead of the URL of the page in your browser starting with http:// it starts with C:\ or file://
Here's what the AddThis buttons look like when viewed via http:// - http://i.imgur.com/IDGUD.png
And here's the same file viewed using file:// - http://i.imgur.com/gpCco.png
We currently are using protocol-free URLs in our code - ones that start with // instead of http:// or https:// - to make sure our SSL implementations are cross compatible without extra work. However, if you're loading the test page with the file:// protocol it causes the CSS and other JavaScript files not to load, since it's looking for them on your local machine rather than our web servers.
I've submitted a ticket to our developers to fix this for people previewing pages using their file system rather than a web server, but until they can get that implemented you should either understand that the buttons won't show up if using the file:// protocol or use a web server in order to test how your sites display in browsers.
I believe it's normal since AddThis is to share stuff on social websites.
If you're not on a server, you won't be able to share stuff because it's a local file.
It's probably inside the addThis code to check for the server. If it's not a server then it doesn't have to share.
This is common sense if you ask me but I could be wrong.
Addthis will check for the current url - http://localhost/etc. is a valid location, but file://path/to/yourfile.html is not.
Related
I am writing a mobile web page which has both a redirect and two manual backup links (for when the redirect doesn't work) to a Facebook Page.
The link takes the form:
fb://page/[PAGE ID NUMBER]
The redirect and link work in Chrome Mobile and Firefox Mobile but (surprise) they don't work in Facebook Browser which, instead, gives me the error:
Page can't be loaded.
I am perplexed that a link to the Facebook App doesn't work from within the Facebook Browser.
How can I resolve this? Are there any creative solutions or workarounds... or have I missed something obvious?
Additional Info: It looks like the redirect is working in at least one version of the Facebook Browser on the Facebook iOS App. So the issue may be isolated to the Facebook Android App.
UPDATE 1
I've made some progress. I've discovered that Facebook's in-app browser doesn't always (or doesn't ever?) acknowledge / load / execute external script files.
Added: (To find out why not, see Update 8, below...)
In this case the href attributes in the links were being re-populated with fb:// protocol links by an external script after page load.
I have moved the relevant javascript functions from the external script to the bottom of the actual page. I have tested the functions and I can see they are now activating. Although the links still don't work.
UPDATE 2
It struck me that there may be some security mechanism going on behind the scenes which doesn't allow for any javascript-driven re-population of href attributes and that instead of the fb:// protocol links not working, it was maybe the case that the initial, default http://www.facebook.com/ links were never even being replaced and it was those http:// protocol links that weren't working.
So I updated the PHP template, so that the initial default links were the fb:// instead of the http:// links (so nothing in the page delivered to the Facebook in-app browser would need to be updated by any client-side script at all at any point).
Nope. Still not working.
UPDATE 3
I added a plain vanilla link to the bottom of the page, linking to the site's homepage. The link functioned entirely normally.
Later, I pointed the original links to an external domain. They didn't work.
So... I concluded that only http:// protocol links to the same domain would work and that's why the links wouldn't work if they pointed to an external domain or to an fb:// protocol address.
Wrong conclusion.
I pointed the original links at the site's homepage and they still didn't work.
UPDATE 4
In a moment of inspiration, I removed the reference to the external script which I'd set up to customise the links to the OS + browser environment (even though this script reference was being entirely ignored by Facebook, according to the FB Debugging tool.
The links worked.
So the reason why the plain vanilla link I had added earlier had worked, was nothing to do with where it was pointing and simply to do with the fact that at no point had a script tried to access it or update it.
Added: (This isn't the reason. See Update 8, below...)
I pointed the original links at the external domain. They worked.
I pointed the original links at the fb:// protocol. They didn't work.
UPDATE 5
Now that I've got rid of the external script reference, I can point the original protocol links at any http:// protocol address and they work.
Including the http://www.facebook.com web equivalent of the page I am trying to open in the Facebook App.
Let's review that:
The Facebook website is opening in the Facebook in-app browser.
I know, right?
UPDATE 6 [.HTACCESS REDIRECT]
I changed the link destination to /fb-custom-redirect/.
Then I added a line to the mod_rewrite section of my .htaccess file:
RewriteRule ^fb-custom-redirect fb://page/[PAGE ID NUMBER]
Naturally the server didn't understand what I was asking for.
UPDATE 7 [PHP REDIRECT]
I created an index.php for /fb-custom-redirect/ and added the following:
<?php
header('Location: fb://page/[PAGE ID NUMBER]');
?>
Guess what? This works in Firefox Mobile. It also works in Chrome Mobile.
But in the Facebook in-app browser, it returns the same error:
Page can't be loaded.
UPDATE 8
I've only just discovered - and this is not insignificant - that when the Facebook Debugger Tool (https://developers.facebook.com/tools/debug/sharing/) refreshes Facebook's cache of a given page, it only refreshes the .html.
Pressing Scrape Again does not refresh any external resources like .css and .js files.
Instead Facebook continues to refer to its own cached versions of those files, regardless that the .html file cache has just been updated.
The workaround (in PHP, at least) is to append the filepath with a new, randomly generated query string every time the page is loaded:
<link rel="stylesheet" href="/styles/mystyles.css?'.uniqid().'" />
Now the Facebook in-app browser is fetching up-to-date versions of my .css and .js files.
This explains my initial observation in Update 1:
I've made some progress. I've discovered that Facebook's in-app
browser doesn't always (or doesn't ever?) acknowledge / load / execute
external script files.
I'm going to conclude that the Facebook in-app browser was parsing the external .js file reference every time, but it was repeatedly accessing an old, cached version of that file.
Nevertheless, even after all the hypotheses and experimenting above, I'm still no closer to discovering why fb: protocol deeplinks don't work in the Facebook App's in-app browser.
I give up.
Apple apps are sandboxed. This means they cannot access other apps and execute code. Facebook is running a browsing instance and when you try to call the fb:// protocol, the iPhone is blocking you from doing this to try to create an infinite app loading loop. I.e, you open a page in FB browser and it opens itself in FB browser and it opens itself in FB browser...
I've implemented this script on my Squarespace website using the wexley template to make images in a gallery act as links (Wexley does not support clickthrough URLs natively).
It works fine, but if I add any thumbnails to the gallery it will not work until the browser cache is cleared.
I am wondering if there is a way to fix this? Perhaps through:
1) setting an expiry on the cache? I am not in developer mode so this would have to go into a header injection
2) Versioning? I tried hosting the javascript as a file elsewhere on my site. This worked (it pulled the script from another location) but still get the same issue, even when I upload a new script file and point to that after updating the page!
You can force the client to download the field again. To accomplish this you need to make the clients browser to think it doesnt have the script in cache. You can do this changing the file name.
Imagine you have this folder structure:
index.html
index.js
If in your index.html you reference the script like src="index.js" you may force clients to download just apendding a query string to the import: src="index.js?0"
Now clients browsers will check if this file is in cache, and since it isnt, they will fetch from the server.
Checking the resource loading on my page I realized that the script was not being cached so it was something else getting cached that was interfering.
Because I am not in dev mode, I implemented a fix that relies on appending the URL with the date of the update, and then setting up 301 redirects.
The URL and redirects (2 total) would have to be updated when any content is added.
If anyone sees issues with this (relating to SEO or some unknown), I would appreciate your feedback.
I have WAMP installed on a network machine. I have a table with file links, for people could open those files directly from a web page.
Those files are in another server, in the same network as WAMP.
When the users click on the link it appears the following error:
"not allowed to load local resource: file:///networkdrive/directorie/file.xls"
How can I resolve this?
I have this:
<button type="button" onClick="openfile('networkdrive/ptlr/Sectorial/LRCD/Horários/Equipas Turno.xls')">botao</button>
<script>
function openfile(file) {
window.location = "file:///" + file;
}
</script>
Just read the error: "not allowed to load local resource (...)"
Or on Firefox I get "Access to (...) from script denied".
It seems you are looking for a magical solution that will solve it, but no, it's exactly as the description of the error says: you are not allowed to do that because of security reasons.
The problem is that you're trying to make the browser open a file on your local drive, and that's not allowed from any protocol other than file:/// itself. So, what you'll want to do is either make sure the local file is also accessible via a server, or open the webpages that contain this script from file:/// too.
You can see this at work by first opening http://jsbin.com/OYObEMA/1/ and seeing this same error occur, then pressing CTRL+S and saving it as a single HTML file, and opening that HTML file then. The JSBin one opens via the internet, so isn't given access to the file:/// protocol, but the local (downloaded) HTML file can access it.
One way you could kind-of do this is to just provide the url the user needs to go to instead. So, just make an <input> that has a value set to the url the user would need to go to, and then provide the instructions "please copy this url into your url bar to open this file". That's not an elegant way to do it, but it would kind-of work.
About your answer to my initial comment: sure, I understood that. The question was not meant in a literal way, but to make you start thinking about what you actually try! You mix different environments.
either need to use webdav for this, if your client side applications are able to use that http extension to load and save files, or
you have to do the old scheme known from the IT middleages which is still typical for MS-Windows systems: offer the file for download via http and add an additional upload service (which will give you versioning pain), or
deliver your web page via the same protocol (network share) so that it is opened with as a local file on the client side, since then your are allowed to open additional local files referenced inside the web page.
My asp.net mvc application runs under https and it is working just fine.
The problem is when a user goes to the secure portion of the website they get the warning asking them if they want to view only to content that was delivered securely. If they click yes, then non on the javascript or jquery will work. If they select no, then it all works just fine.
How then can I provide the .js files securely? Or is that totally up to the user?
Also the warning gets very annoying at it shows it on every new page that is navigated to.
thanks!
also, this is only a problem when the user is using IE, Firefox has no issues
twal,
use the following approach and it should fix the issue:
<script type="text/javascript" src="<%= Url.Content("~/Scripts/jqGrid/js/jquery.jqGrid.min.js") %>"></script>
this will then use the approriate path to the file resolving the protocol on it's way.
Make sure you're referencing HTTPS for full URL.
You can often avoid this if they are relative URL as it will normally use the same protocol you are currently on.
I noticed that when I open HTML file locally by double clicking on it, it will not "run" the same as if I had it on a web server and opened it by HTTP GET request.
I need to have a local HTML file a user can open by double clicking on it. This HTML file has several JQuery load calls such as this:
$("#content").load("http://somepage.com/index.html");
I want to update several divs with content from remote sites.
This works fine If I have this file on a web server but not if I double click it under windows explorer... How can I "make" the file "run" as it would on a web server?
I think you pretty much cannot. This has to do with domain-access restrictions, which are there to avoid cross site scripting and the likes.
The files on your hard drive are especially limited - think what the life could be if they were allowed to treat your whole hard-drive as a single domain.
If you want things to work properly you need to be running a server. XAMPP is a pretty good bet as it's easy to install and set up.
Any non-AJAX javascript will work fine as is though, as long as the paths to include any css or js are relative.
You can't do this locally. You have to have it hosted somewhere for this to work. It's done this way for the sake of security.
What are you trying to do that you "need" to have this?