Forum Moderators: open
How can I force the pages to display always inside an specific frameset? I've seen sites doing that.
Thanks for helping.
1. have frame content page check to see if it's in its frame. If not, write the page url into a cookie.
2. relocate the page, except load tne frame container instead of the content page.
3. have the frame container read the cookie, after checking if it exists, then write the content url into the frame src url.
That's about it, but it's much harder to do this right than I can outline quickly, you also have to supply a way for the visitor to get back to the search engine, otherwise you can get into some eternal loops which aren't very user friendly.
If it's just a single page, you don't need the cookie, but I don't know why someone would use a frame with only a single page.
If you want to preserve tha ability to use the Back Button, use the replace() method instead of just assigning a new href.
FORCE MANY PAGES INTO FRAMES
with one simple script
With search engines now indexing framed pages, lots of traffic is being sent straight to pure content pages, orphaned from their parent frameset. Building a separate frameset for each possible content page is one solution, but it can be a maintenance nightmare. This script handles the problem.THE MAIN IDEA
You can add ANY page's name to the end of a URL [after a "?"] Then you only need ONE frameset page to catch an indefinite number of orphan pages and put them into their frameset. This method offer very easy maintenance, especially when there are lots and lots of possible orphans for one frameset.THE CODE
Call this javascript code from the HEAD section of each child page. The code creates a variable from the URL of the page, and then passes that variable in the new location's URL. This means a "master" frameset can load this exact page in the content section:passpage = document.URL
if (top.location == self.location)
top.location.href="master.html?" + passpageThen create just one "master.html" page. It holds the JavaScript code to decipher whatever URL is passed after the "?" and it writes that page into the content frame:
<html>
<head>
<title>Master Frameset</title>
</head><script language="JavaScript" type="text/javascript">
origURL = parent.document.URL
contentURL = origURL.substring(origURL.indexOf('?')+1, origURL.length)document.write('<frameset cols="20%,80%"><frame src="leftnav.html" name="nav"><frame src="' + contentURL + '" name="content"><\/frameset>')
</script>
</html>
In a sense, the best strategy could be to just switch the pages over to nonframes, maintain the file names, add the navigation elements through server side scripting, and just give up on using frames. Much as I like frames, getting this search engine stuff working without annoying bugs is just too hard, all the scripts I found were based on query string url passing, and not one of them actually worked in real world tests, especially when it came to the back button problem, though using replace() is not something I tried.
This is my code now. It looks like the document.write is not wrtting the document
<HTML><script language="JavaScript" type="text/javascript">
origURL = parent.document.URL
contentURL = origURL.substring(origURL.indexOf('?')+1, origURL.length)
document.write('<frameset rows="103,*" BORDER=0 FRAMEBORDER=0 framespacing="0" ><frame name="top" src="snowbrasil/top.htm" FRAMEBORDER=NO
marginwidth="0" marginheight="0" scrolling="NO" ><frameset cols="128,*" BORDER=0 FRAMEBORDER=0 framespacing="0"><frameset rows="340,*" BORDER=0 FRAMEBORDER=0 framespacing="0"><frame name="menu" src="snowbrasil/menu.htm" marginwidth="0" marginheight="0" scrolling="no" frameborder="no" noresize> <frame name="amazon" src="amazon_rotator.htm" marginwidth="0" marginheight="0" scrolling="no" frameborder="no" noresize></frameset><frame name="principal" src="'contentURL'" marginwidth="5" marginheight="5" scrolling="auto" frameborder="no" noresize><\/frameset><\/frameset>')
</script>
</HTML>
<frame name="principal" src="' + contentURL + '"...
The structure here is: "write everything between the single quotes, plus the value of the variable contentURL, plus everything between the next set of single quotes."
There may be other errors here as well that just aren't jumping out at me. Turn on the javascript console when you try to open the page and see what errors it reports.
Good!
Thanks!
I think the script without knowing where the user is coming from will cause problems, for instance when there are absolute links inside the website. Correct?
Different browser handle this return process quite differently, so you have to test it on opera, mozilla, and IE, also ideally safari and mac ie.
The main source of the problem is that you now have a query string on the frame url, it's very hard to make that go away, and when you hit the back button, you're going to land back on the content page, which is going to run the javascript again, since it's not in its frame. Using the replace() function might solve that, but I can't say from personal experience if that actually works, I sort of doubt it though cross browser. So what does the page do at that point? How does it know you've already done this? Cookie is the only solution I found. And on detecting that cookie, the pages have to do a double jump back, not a single jump, there was also some browser specific fixes for this. You don't want to see how much code is required to get this stable, trust me.
Again,, all, and I mean, all the query string method scrips I found online failed to function correctly when it came to a transparent return cross browser to the search engine or other external link. Despite being posted as solutions, not one actually was a solution. It took me several months to realize this.
It's not really necessary to write out the frame page with javascript, all you have to do is fill the main container with the right page, you put that function call into the onload even in the main frameset tag.
You mentioned about using an onload() on the main frameset. How exactly do I do that?
Thanks again.
You can hard code in the name of the frame element into the function if you only use this in one place, or if you r container frames have the same name site wide.
I don't know where the replace() goes, maybe tedster can tell you, I assume it replaces the location = thing, or if it works. Getting this to work is not trivial, and not easy, or else all the scripts I found online would have worked.
Debugging this crossbrowser can drive you crazy almost, but it can be done, I just wouldn't recommend doing it unless you are comfortable with javascript and cookie logic.
You definitely do not want your frame page scripted, since you need that to work if javascript is off, then it can give the user a default page for the content.
Also, using iframes is marginally easier than using frames, there's less to get indexed, only one frame instead of the content and the index section. Functionally it's the same, just easier to code iframes, but of course then you lose ns4 support, which is a tossup to do, not worth it this year, maybe next.
My corcern here now is to test if javascript is on or off. It it's on, then use the redirection with the frames, if off, just open that page by itself like it used to be.
Is it possible?
I also would like to test if user is coming from an different IP, if no, run the script and open page in frames. If no, then just open that page. And, this can be done?
Thanks a lot
I also would like to test if user is coming from an different IP, if no, run the script and open page in frames. If no, then just open that page. And, this can be done?
It would be nice if it could be done this easily, but unfortunately you have no control of whether a user agent has it's referer on or off, apparently many offices for example switch this capability off in their setups.
It's the useragent that passes the referrer information, not the site itself if I understand this correctly.
I can't remember if you can check through javascript the equivalent of isset() in php, that would cover you from some of the problem if you can.
This was my preferred solution too, simply check the referrer, if it's your site, don't run the script, if it isn't, run it. This was such an attractive idea that I was going to implmement it server side, since that can be checked by things like PHP, that would have removed all questionmarks from the process.
I'm not sure how you're testing, this method runs fine on your local machine to lift you up to the frame page and load the content, the problem is when the request comes from outside the site, is it returning you to the search engine correctly?
I'm not sure how you're testing, this method runs fine on your local machine to lift you up to the frame page and load the content, the problem is when the request comes from outside the site, is it returning you to the search engine correctly?
I just tested if the redirection with frames was working and it is. I think the back option doesn't work. Once I know where to put the replace(), I will give it a try.
DO you know how to test if javascript is on or off and then make it take different paths?
I think the back option doesn't work. Once I know where to put the replace(), I will give it a try.
This is the entirety of the problem, this is the essence of the problem. Lifting somebody up to a frame/iframe container is trivial, that's not, and never was, the problem. You haven't implemented any solution at all until the user can return to where they came from, it's that simple.
DO you know how to test if javascript is on or off and then make it take different paths?
the thing that makes it take diffent paths is javascript, only javascript or a server side thing can test if there is a referrer, only javascript can check if the document has a frame around it or not, if javascript is off nothing happens.
If javascript is off that's the end of the story, the user lands on the content page and stays there, you can put a small note in a <noscript> tag that says 'this document is supposed to be in a frame, click here to load the frame, but then you couldn't reload the page into the frame.
You can do a crude test using server side programming to see if javascript is on, it involves reloading the page with a query string, like content.htm?javascript=false
that php would read then deliver whatever you needed done, that requires a meta reload tag though to run right, bad solution.
This is the entirety of the problem, this is the essence of the problem. Lifting somebody up to a frame/iframe container is trivial, that's not, and never was, the problem. You haven't implemented any solution at all until the user can return to where they came from, it's that simple.
What if I the back doesn't work? I knwo it's not good, but I can leave it like that if I want, right?
And the user can always go back by opening the dropdown next to the back button and going 2 steps back.
user can always go back by opening the dropdown next to the back button and going 2 steps back.
How many users do you think know that? When I was testing the query string method, I would often have to close the browser to get back to google. That's not an acceptable solution.
Ask yourself this: how many sites have you had to do that on? If you haven't have had to do this yourself, why would you make your users do that? That's not very nice. I have never had to do this on any search that I can think of, for very good reason, you want users to be happy with their visit, not to curse your site for locking them into a loop.
This is the main problem with using frames or iframes, absolutely top of the list, there should have been either a browser side or javascript object to solve this problem, which would have been fairly easy to do, for example make the main content be accessible through a url code or something, but this didn't happen.
This problem can be solved, but not as easily as has been suggested. And you can never get around these issues: if javascript is off, that's the end of the story, the user is not in the frame; if you are relying on cookies or referrers, if the user has these off, that's also the end of the story, although in those cases you can lift them up to to a default start page in the frame/iframe through js if cookies are off and js is on.
<added>I would suggest that for people who are running frames or iframes, and have problems with figuring this exact thing out, you might be better off just popping the iframe/frame content pages into straight non frame/iframe html template pages that have the old frame navigation bar, it's easier, always works, and solves all the problems, except that you lose the frame/iframe scrolling, which is definitely a drag.
passpage = document.URL
if (top.location == self.location)
top.location.href="master.html?" + passpage
Becomes:
passpage = document.URL
if (top.location == self.location)
location.replace("master.html?" + passpage)
Note: I've added this bit to the javascript reference thread - thanks for bringing it up.
[edited by: tedster at 5:26 am (utc) on May 28, 2004]
Thanks
I'm especially interested in Opera's handling of that, Opera was I think the browser that gave me the most trouble with getting people back to where they came from.
I ran a quick test on icapture's safari test, and it looks like safari does not support replace, opera less than 7.5 did not support it when I tested it, I doubt IE mac supports it. To double check I tested one of my cookie method pages and it worked decently.
I would tentatively say that this is a good solution for people, much better than nothing, and if you can't do the cookie method, which is way too complicated, but does work on all browsers out there that I've ever tested it on, this is a really good solution.
Since I like supporting Opera and Mac browsers I couldn't use this method, but I think it is a pretty decent way to go, it's definitely WAY more easy to implement than a full cross browser solution.
<added>replace() does not seem to work with the default tabbed browsing setup of firefox either, although it does work with Opera 7.5's tabbed browsing.
You are going to lose the tabbed mozilla browsers, but again, for the amount of work it would require to keep macs and tabbed mozillas and pre 7.5 operas this is a pretty good solution, quick and dirty, there's definitely something to be said for that.
The tabbed browsing failure on Mozilla is odd, and will happen on all os's out there, some day those numbers might start adding up, but they don't today so you're in decent shape.
I'd say if a browser isn't supporting it now, they certainly should figure it out in future versions.
The replace() method was made a part of JavaScript in version 1.1 - that's August 1996.
Yes, it's sad, this kind of totally inconsistant browser support for javascript is one reason I've lost interest in javascript, also another reason I just can't get that excited about Opera browsers, they just now got this working, in May 2004...
It is a great method, I'm annoyed I missed that one, but thanks for mentioning it. But unfortunately since it also doesn't work on mozilla tabbed browsing, at least not on any version I tested it on, it's still not going to do me any good, even though it solves all of the problems of location.href and history back. Since it probably doesn't work on Mac IE (somebody want to test it?), and doesn't appear to work on Safari, it's still unfortunately not a solution cross browser/os.
I wish there was a way to do server side testing of [if location = top], that would solve all the problems, I thought maybe using referer would work, but then read here that many offices block referer from being sent, so that also would do no consistent good.
