I'm using the following history.go in search results with acceptable results cross-browser. I'd prefer a PHP solution but this filled the needs until I realized a larger issue.
Return To Search Results
My only issue is when the viewer comes from a page NOT originating from the search page http://www.domain.com/search/
Is there a way to modify this to use the simple script but if the previous -1 history is NOT the search page URL to redirect to the search page URL if the href is clicked?
the php variable $_SERVER['HTTP_REFERER'] will give you the page the current tab / window was on before it got to you.
this value might be empty if someone opened your page directly by typing in the url or by preventing this value to be transmitted to the server.
all in all there is no way to access the browser history at all due to security reasons.
$_SERVER['HTTP_REFERER'] is all there is that you could make use of. sorry to disappoint you.
btw.. its commonly used in hot linking prevention through out various blogs so people cannot "link" to pictures and files etc.
in your case you just need to figure out if the url equals the search site.
Related
I have an existing site to which I am adding AJAX Hash navigation. There are a couple situations that concern me.
I am using the onclick event of links to update the hash when appropriate:
My updateHash routine simply updates the hash to be #!Galleries/Colored-Pencil/71/1/
So - all links work for non-js visitors... the problems arrive when a hash-encoded link appears on an external site.
QUESTIONS
1) Inbound Links... Say someone copies and pastes a hash encoded url (i.e. www.mysite.com/#!Galleries/Colored-Pencil/71/1/). What can I possibly do for a non-javascript visitor that clicks the link? It seems to me they would just end up at my default page. The server won't know if the client has js enabled or anything about the requested hash. I have to imagine there is no work-around for this... I would have to display the home page. Besides showing the default home page, is there any way to support non-javascript visitors that stumble upon a hash-encoded url?
2) Google... Since all of my urls are presented without the hashes (which are only used on a js click), I don't feel I need to implement Google navigation of hashed links (i.e. the ?_escaped_fragment_= scheme)... but what about external links that contain the hashed navigation? I want the link juice to go to the 'normal url' (without hash-encoding). Should I handle '?_escaped_fragment_=' calls with a redirect to the non-encoded url? (doing so would also prevent duplicate content in Google's index)
I can think of ways to alleviate some of these issues (suggesting a permalink, trying to intercept 'copy' operation of url [not sure if possible or wise] and replace with desired url) - but I don't like these options and don't plan on investigating them... especially because the original problem would still need to be handled (being hash-encoded urls appearing on external web sites).
THANKS!
Im loading the content of my sites via ajax&jquery into a area of the "main" page, so loading goes faster. but the problem is that with that method im getting serious SEO problems, because the URL is not getting updated. and search engines only index the homepage not all the other content too. So how can i update the URL of the site everytime when im loading new content? How can i let the page load the content needed when a updated URL is given?
you can view the whole sourcecode here: http://boxcomp.111mb.de/luxus/html8
can you maybe directly suggest me what i should add to existing jquery code? you can find it on top of the index.html file.
sorry for the "mess"
thank you very much!
All current browsers, including IE10+, do support HTML5 History API that allows to alter URL address without reloading page. For older browsers, you can just not use Ajax.
Search engines should not be affected by Ajax at all. They should see regular static links with regular href attributes.
I have to disappoint you.
You can't change the browser's url without reloading the page.
The only thing you can do is add anchors to the page:
index.html -> index.html#page1
But I think, these are not really relevant for search engines.
So you have to decide: either SEO or Ajax - but both is not possible...
I am using window.location.replace for various things on an app and passing variables in the URL (www.website.com/?clicked=2).
The problem is that it absolutely floods the history with new entries (at least in Chrome). Is there a way to just have 1 entry for the page? I thought window.location.replace was supposed to replace the entry or so I have read?
Are there any other methods out there? If you use the app legitimately for like a minute clicking things, it will take up a page of history.
I do not think you can do that. window.location.replace will simply change an URL and reload page. As it is a different URL - it will be added to navigation history. Suppose the only thing you can do here - download full page with ajax. Little strange usage of ajax, but it will solve your problem with multiple entries in history. With things like History.js you can control what is in browser history, but page will be loaded with ajax anyway.
Location.replace( does not make a history entry.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What’s the shebang/hashbang (#!) in Facebook and new Twitter URLs for?
I was wondering how Twitter works its links.
If you look in the source code, you use the links are done like /#!/i/connect or /#!/i/discover, but they don't have a JavaScript function attached to them like load('connect') or something, and that it doesn't require a page reload. It just changes out the page content.
I saw this page, but then all of those files would have to exist, and you couldn't just go straight to one of them. I imagine that on Twitter each of those files don't exist, and that it is handled in some other method. Please correct me if I'm wrong, though.
Is there a way I could replicate this effect? If so, is there a tutorial on how to go about doing this?
"Hash-Bang" navigation, as it's sometimes called, ...
http://example.com/path/to/#!/some-ajax-state
...is a temporary solution for a temporary problem that is quickly becoming a non-issue thanks to modern browser standards. In all likelihood, Twitter will phase it out, as Facebook is already doing.
It is the combination of several concepts...
In the past, a link served two purposes: It loaded a new document and/or scrolled down to an embedded anchor as indicated with the hash (#).
http://example.com/script.php#fourth-paragraph
Anything in a URL after the hash was not requested from the server, but was searched for in the page by the browser. This all still works just fine.
With the adoption of AJAX, new content could be loaded into the current (already loaded) page. With this dynamic loading, several problems arose: 1) there was no unique URL for bookmarking or linking to this new content, 2) search would never see it.
Some smart people solved the first problem by using the hash as a sort of "state" reference to be included in links & bookmarks. After the document loads, the browser reads the hash and runs the AJAX requests, displaying the page plus its dynamic AJAX changes.
http://example.com/script.php#some-ajax-state
This solved the AJAX problem, but the search engine problem still existed. Search engines don't load pages and execute Javascript like a browser.
Google to the rescue. Google proposed a scheme where any URL with a hash-bang (#!) in lieu of just a hash (#) would suggest to the search bot that there was an alternate URL for indexing, which involved an "_escaped_fragment_" variable, among other things. Read about it here: Ajax Crawling: Getting Started.
Today, with the adoption of Javascript's pushstate in most major browsers, all of this is becoming obsolete. With pushstate, as content is dynamically loaded or changed, the current page URL can be altered without causing a page load. When desired, this provides a real working URL for bookmarks & history. Links can then be made as they always were, without hashes & hash-bangs.
As of today, if you load Facebook in an older browser, you'll see the hash-bangs, but a current browser will demonstrate the use of pushstate.
You might wanna check out more on Unique URLs.
It's loading the page via AJAX, and parsing the "hash" (the values that come after the "#") to determine which page it's going to load. Also, this method is used due to the nature that AJAX requests don't count to the browser's history thus the "back button breaks". But the browser does however store into history the hash changes.
Using hashes plus the fact that you can use hashes to determine pages, you can say that you can keep AJAX requested pages "in history". Added to that, hashed URLs are just URLs, and they are bookmarkable including the hash, so you can also bookmark AJAX requested pages.
Im hosting a rails app on heroku. It runs on the client on a touchscreen with Google Chrome in Kiosk mode, so no browser chrome or keyboard. The login/home page is different for every kiosk.
Error pages are static assets, so I'll have to do this with Javascript. If there is an error I want to display a button that will let the user get back to the home page.
I can't just use a back button script b/c of the potential for multiple errors. I thought about using localstorage to store a reference to the home page, but the error pages are served from a different domain so they wont have access.
Any ideas?
Edit:
This works in Firefox onClick="window.home();" If I set the browser's home page to that particular kiosk. But apparently isn't supported in Chrome. Is there any way to store some kind of variable that any domain can access on a per browser/kiosk basis.
I think you're making this too hard. You already have the information you need to go back stored in "local storage" -- the browser history. Simply use javascript to look at the history and go back as far as you need.
As far as returning to the home page, isn't the home page a well known URI? What's wrong with go home?
Update
Isn't the home page always going to be the first page in the history? You seem to be saying that you're in a situation where you want to return to a page for which you don't know the base URI, don't know how you got where you are, and don't know where you started.
I suppose you could put the place you'd like to go into a cookie, but if you don't even know the base URI, how would you retrieve it?
I'm beginning to think the real answer is "you need to rethink your design, there's something deeply wrong."