I want to create an html page and use it in the src attribute of the amp-iframe tag.
The amp-iframe tag then (as i understood from some examples) creates the iframe and loads the html page.
In drupal though, i can not find a way to use this html page in a twig template.
Is there a way to find a path inside drupal for this html page and use this path in the src?
I know drupal works with templates and twig files but in the amp examples everyone uses html.
Problem could be that you're trying to add amp-iframe content that's on the same origin as your page domain. That's forbidden for security reasons (mostly to do with the way the same-origin policy uses synthetic origins inside iframes).
The fix is to make sure that external JS is served from a different origin to your AMP. So if your AMPs are on example.com then you should serve the iframed JS from SOMEOTHERORIGIN.example.com
Share your code for better under standing of your issue.
Also refer - https://github.com/ampproject/amphtml/blob/master/spec/amp-iframe-origin-policy.md
Related
My site, Jekyll static pages and a blog, https://omnebonum.github.io/dsu/ on GitHub pages looks like it is supposed to (such as it is). I have a custom URL set up that points the repo to democracystraightup.org. That works but when I go that URL the pages show up without any CSS or pics.
I know this isn't super specific information, but you can check them both out if you like, and any general insights would be appreciated.
All your css, javascript and other assets are returning 404 errors:
The paths are all pointing to subdirectories of http://democracystraightup.org/dsu/ (e.g. http://democracystraightup.org/dsu/js/gallery.js).
Thats wrong.
You need to drop the /dsu to make it work.
For example http://democracystraightup.org/js/gallery.js works totally fine.
I'm mostly certain that I set up my HTML script correctly, and made sure that the needed CSS file would be hosted in a shared folder on Google Drive, correctly cited, etc.
However, when I copy my HTML code into the box, and save it all, the editor always throes this error: 1+12 - 125: failed to load external url navigator.css
While I would think that linking the CSS file to the HTML code regularly, as I posted below, I only see so many issues coming up with CSS linking, and even more worrying, is that the Google support documentation (here) says that an HTML box can't 'refer' to external code, including what I believe may be such a CSS file.
<link href="http://[mixed aplhanumeric subdomain].googledrive.com/host/[shared folder's 'mixed' address]/navigator.css" rel="stylesheet" type="text/css">
Given that, would anyone know a simple workaround to linking the HTML to the CSS code in the Google sites HTML box?
The documentation shows an example with the CSS in <script> tags. I don't perceive any indication that including CSS from an external file is allowed. The documentation explicitly states that <link> tags are not allowed. The reason why Google Sites can't load CSS in a linked file, is because link tags are not allowed. You're only choice is to include the CSS in <style> tags.
There is an alternative though. You can create an Apps Script HTML Service application with separate HTML and CSS files, and then put the Apps Script application into your Google Site.
Apps Script HTML Service
If you want to use Css on Google SItes , you can use directly. not to use link.
I've created a project with the moovweb sdk and have trouble editing the content within an iframe on one of the pages. For instance, moving a div around inside the iframe doesn't seem to work with the tritium I'm writing. What can I do with tritium to make this work? The domains are different FYI.
Unfortunately, Tritium only allows you to edit the attributes of the iframe itself, not the content within.
This is because the request for content in the iframe is made after the browser constructs the DOM of the main page. Tritium can only intercept the first request for the main page, not the second request for content from a different domain.
I know of two workarounds:
Add the second website as a Moovweb project and you will be able to use Tritium to manipulate the content. Then you can point the iframe of the original page to this new content.
Use JavaScript/AJAX to modify the iframe's content.
However there are implications for production domains... I'm afraid I may have rushed this answer and will update it after I do more research.
If the iframe is on the same origin (http://m.yoursite.com) or on an origin you have in your config.json you can absolutely use tritium! However, maybe not in the way you expect!
So, the iFrame is going to make a separate request to the src attribute's location. If you ensure this request is going through the SDK (by rewriting it) like so:
$(".//iframe[#src]") {
attribute("src") {
rewrite("link")
}
}
Then you can map that url and perform your regular tritium on it!
you need to analyses the src of iframe and need to write mapping in mappings.ts for the url in src. Include proper .ts file in pages folder and start transforming it.
I have a servlet that generates CSS for a given colorScheme name if it exists in the database. However, should the colorScheme not be found, it issues a response.sendRedirect() to the location of the actual file on our CDN.
This works in all browsers except for IE when the CSS contains relative links to images for icons, backgrounds, etc. Every other browser uses the redirected URL (CDN url) to resolve the relative URLs in the CSS file, but IE still uses the original request URL (servlet URL).
I can't change the relative URLs to absolute URLs in the CSS files for a number of reasons I can't go in to. Is there a way to get IE to use the redirected URL instead of the request URL for the relative URL resolution?
Sounds like more of a code design problem. Personally I don't rely on IE to do anything as it should. It always lets me down :(. I would always include your CSS from the CDN at the begining of the head using the HTML LINK tag, then let the JS import overwrite it afterword. This way your website will also look decent in noscript browsers.
As a workaround you can use css #import tag instead of redirecting to the external css file.
#import url('http://www.example.org/style.css');
Since we are processing our HTML/JS in another servlet before the call to the colorScheme servlet, what I did was check to see if the requested skin was dynamic (from the servlet) or not at this stage. If the colorScheme is dynamic, I write out the link tag with the address of the CSS servlet, otherwise I write out the address of the CDN.
I am using WebRequest to retrieve a html page from the web and then displaying it using Response.Write.
The resulting page looks different from the original mostly in font and layout.
What could be the possible reasons and how to fix it?
Most probably, the HTML you retrieve contains relative URLs for loading images, stylesheets, scripts. These URLs are not correct for the page as you serve it from your site. You can fix this by converting all of the relative URLs into absolute URLs or by including a BASE tag in the head of the HTML, pointing to the URL of the original page.
Be advised though that deeplinking to images and other resources is considered bad practice. The source site may not like what you are doing.
The reason might be that the original html page contains relative (to the original site) paths to the stylesheet files so when you render the html in your site it cannot find the css.
Does the remote web site include CSS, JavaScript, or images?
If so, are any of the above resources referenced with relative links (i.e.: /javascript/script.js)?
If so, when the browser receives the HTML from your server, the relative links (which were originally relative to the source server) are now relative to your server.
You can fix this by either changing the HTML to use absolute links (i.e.: http://www.server.com/javascript/script.js). This is more complicated than it sounds: you'll need to catch <link href="..."/>, <a href="..."/>, <form action="..."/>, <script src="..."/>, <img src="..."/>, etc.
A more limited solution would be to place the actual resources onto your server in the same structure as they exist on the original server.
The remote site might look at the User-Agent and serve different content based on that.
Also, you should compare the HTML you can retrieve from the remote site, with the HTML you get by visiting the site in a browser. If they are not different, you are probably missing images and/or css and javascript, because of relative paths, as already suggested in another answer.