I'm using urlrewiter.net in order to implement friendly url's.
It's a great and easy to use package!
Nevertheless, while using subfolders I had problems with the relative links to images and to other inner pages.
I tried to use ~ (server side) and it didn't do the trick.
Is there another solution?
Because of these issues, I've started to be always give relative (to the root) URLs, so let's say you have an images subdirectory:
http://www.contoso.com/images/blah.jpg
You'd always reference it via "/images/blah.jpg" .. and no matter what the base page/context is, that image will be accessible.
You should probably segment your site so static elements (images, css, etc) are in separate location from your dynamically generated urls. I've used URlRewriter extensively in the past, and it worked great, but our site was setup so that our resources were segmented like that.
You can simply add base tag to your HTML headers. This will force browsers to use specified location to resolve relative links. Maybe this article will help you: SEO-Friendly URLs and Relative Links
Related
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 turned on URL rewriting on Drupal, and some URL image are broken.
For example :
local/tw/sites/all/themes/tw/images/1-p1.jpg become
local/tw/content/sites/all/themes/tw/images/1-p1.jpg
or
local/tw/sites/all/themes/tw/images/2-p1.jpg become
local/tw/node/sites/all/themes/tw/images/2-p1.jpg
Any ideas?
If you used relative path, and you're talking about contents within nodes, it's perfectly normal, since "node/" is interpreted like a directory.
You could fix this problem adding a "/" before image src, or using module like Path Filter that provides a simple file:relative/path/to/file syntax.
I'm developing a site locally using xampp. The path the images are using is
/devsite/sites/default/files/icon_facebook.jpg
When I check out of the site on my server the path remains the same for the images, even though the image is now at
/~devsite/sites/default/files/icon_facebook.jpg
Are the image URLs just hard-coded by the wysiwyg including the wrong base path? Is there something I can do to make them work?
When you're using wysiwyg, the image path is saved along with the rest of the HTML, and the filters don't convert it. So under some conditions - especially if you're moving from a subdirectory to the HTML root - you'll have images that are misplaced.
The pathologic module might be of some help here. Otherwise you could use Views Bulk Operations to do a string_replace() operation your HTML fields.
Try setting the $base_url in sites/default/settings.php. I'm not sure how the WYSIWYG is setting images, but it's pretty standard that it should be using a path relative to the base url.
For example I have site http://localhost/site
In IIS I set that 404 error causes redirection to default.aspx
If I type something like http://localhost/site/nodirectory , (there are no such folder) all works perfectly.
But if I only add slah at end http://localhost/site/nodirectory/, page can't display css and images.
Images and css are located in their own folder. I tried different paths: "gfx/logo.gif", "/gfx/logo.gif"
Does anyone have some ideas about that?
If your css and images are relative paths, say ResolveClientUrl("~/gfx/logo.gif") this renders to the client as src="gfx/logo.gif", which the browser with a slash thinks is /nodirectory/gfx/logo.gif instead of just /gfx/logo.gif.
To resolve this, don't use .ResolveClientUrl(), use .ResolveUrl(), this will make the src render src="/gfx/logo.gif" The beginning / makes it definitive, it's that path from the root of the domain.
You'll see this same hebavior if you're doing paths that start with ../ or gfx/ yourself...make them relative to the application base so there's no chance of confusion.
There are a couple of options...
1)
In your HTML page, make the path to CSS and scripts relative...
"/scripts/myscript.js"
Where the scripts folder is the first folder after the root folder
2)
You can add the base tag to your page, which means ALL page resources will be treated as relative to the root location you specify...
<base href="http://www.mysite.com">
More info about these two options.
If you can, option 1 is perhaps a bit cleaner. You know explicitly the resources that you are affecting. Using the base tag will affect ALL relative paths on your page. Images, Links, Scripts, CSS et al. The second option works best if you developed your 404 page assuming it would be in the root folder, but it could actually be referenced from any non-existent directory. You just put your root address in the base tag and it will all behave exactly as you expect.
With either option, the images can be relative to the location of your CSS file.
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.