On Tue, Nov 2, 2010 at 12:50 AM, Karl DeSaulniers <k...@designdrumm.com>wrote:

> On Nov 2, 2010, at 12:37 AM, Nathan Nobbe wrote:
>  On Mon, Nov 1, 2010 at 11:22 PM, Karl DeSaulniers <k...@designdrumm.com>
>> wrote:
>> I need to basically grab the source of the page as text. Then I can do a
>> replace() on the <link> tag. Then insert the text into an Iframe. In theory,
>> this I thought would be handled better server side. Is this possible?
>> yes, there are a few options, fopen wrappers, curl or raw sockets all come
>> to mind.  fopen wrappers sound like they may be easiest for you.
> Any examples or urls to make a fopen wrapper? Or is there a simple function
> for getting the source text from a URL?


$page = file_get_contents($url);

if you have the appropriate wrapper installed (http) in this case the html
will appear in $page.  you will also need to have enabled the
allow_url_fopen ini setting.

> I think the problem I'm having is that the domain I'm requesting from is
>> not the same domain as mine so their may be some security issue.
>> right, this is why you would setup a server side proxy, to avoid client
>> side cross domain security restrictions, however you'll have to change all
>> the instances of the remote domain to your domain, and ensure that your
>> server actually is able to fulfill requests for those resources.
> Server side proxy.. I have  heard of this, but do not know exactly what a
> proxy does to know if it would be a solution.
> I also have not seen one in action nor made one (that I know of), any
> beginner tuts you can lend?

yeah, all a proxy does is act on behalf of something.  so for example i ask
for a web page directly, the web page returns to me unaltered.  i ask a
proxy for a web page, it may return an older version of the page which has
been cached to boost performance, or perhaps, as in your case, a derivative
of the original page.

> I also thought about injecting a link tag into the iframe at the same time
>> I load the HTML.
>> when you say link tag are you talking about <a> tags?  you lost me on this
>> last line here.
> IE:  [code]
> Get the text from their source, something like:
> $htmlTextresult = <html>
> <head>
> <link href="css/fromtheirsite.css" rel="stylesheet" type="text/css"
> media="all" />
> </head>

o, right i understand now.  yeah, that sounds workable if the domain is the
same as where the page is being served from.

> Or is there a way to strip the text that is in the <head> , <body> and
> <script>  tags?
> I could then insert those into a blank html file?

once you have the html page in memory on your server, you can manipulate the
contents any way you wish before embedding those contents into an iframe.
 essentially the way it will work is you put a url in the iframe which
points to your site.  that page looks up the real page on the other site
then modifies it as need be before returning the page to the browser.

> Browsers load the last style sheet on top of others.
>> this is true, but i doubt you'll be able to have it load a css file from
>> your domain atop a css file from a remote domain.
> Well contrary, I think, only because all css tuts I found warned about
> using the "!important" in your css as it would override an external css.
> Imported css has the least priority out of all and their css is imported,
> maybe if I wrote the css as a <style> inline within the text I received from
> the source?

yeah, that could work.

> I know that would work as far as my css beating out theirs. And the idea is
> to get the source and replace the text that points to their css (the  <link>
> tag) with mine before its parsed.

i think if you just make sure your server can serve any relative pages from
the remote site and you replace occurrences of the remote domain w/ your
domain you will be fine.

> Hey thanks for your help Nathan. I was starting to think I needed to scrap.
> You have sparked the curiosity again.

again dude, no worries, but as i said even though its do-able it will take
some work to get 100%.  also, if the remote site changes it could break your
alterations quite easily unless you have assurances from the remote site
authors about how things will be changing over time, a contract so to speak.


Reply via email to