I have a site with static HTML pages in the home directory. These HTML pages use relative paths to refer to images, css, and links i.e.
<img src="images/myimg.gif">
and
Contact Us
I also have a monolithic script whose URL is, i.e. http://mysite.com/myScript which uses "extra path info" to select functions... i.e. http://mysite.com/myScript/products shows a list of products. So in HTML generated from the script I need to refer to images, css and links like this:
<img src="../images/myimg.gif">
and
Contact Us
The problem is now I want to start moving common HTML into include files, (e.g. common header and footer), but the fact that the script and the static HTML refer to relative resources in different ways is complicating matters.
I don't want to use absolute paths because that messes up my colleague's work when she tries to work on the pages in DramWeaver, and it also makes the site less flexible.
What's the best way to solve this issue? One idea I had was to use URL rewriting in Apache to allow the URL to http://mysite.com/products to really use http://mysite.com/myScript/products but I don't have experience with URL rewriting so I don't know how easy that would be. Another idea I had was to use the META BASE attribute in HTML but I don't like the fact that I would have to hard-code that into every HTML page, and it would have to have the full URL hard-coded (e.g. http://mysite.com/) into each one. Any advice?
Can't you refer to your images with a slash at the beginning so all files linked to are from the root, no matter how deep you are in the directory structure you are? E.g:
<img src="/images/myimg.gif" />
EDIT:
You could use $_SERVER to get the path then use substr_count to count the number of slashes in the path. Add as many ../'s as you need based on that number. Would that work for you?
Related
We have a qa/dev server and a prod server. The two differ by a directory like this
https://domain/service/envQA/sitename
https://domain/service/env/sitename
In some static html I'm trying to put in src and href that are relative to avoid having the markup reference QA if a developer migrates the content and doesn't update an absolute path that includes the envQA. We aren't very fancy and just move most documents over by hand and a busy developer might miss a reference in the middle of several pages of markup -- it happens.
So I'm trying to use relative paths like this.
<img src="assets/backgroundimg.png" />
This works when the user is at our homepage url of https://domain/service/env/sitename but unfortunately our site also has navigational elements that return the user to https://domain/service/env/sitename/ (note the closing slash).
Is there any way (without javascript) to handle a relative path that would work from either of those "locations"?
Have you considered using the <base> tag?
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base
This would allow you to set a base per environment allowing configuring all urls at once.
I am developing a website on a web server which can be accessed by 2 URL: mywebsite.example.com or example.com/mywebsite. For example, when I access mywebsite.example.com/images/abc.jpg and example.com/mywebsite/images/abc.jpg, I get the same picture.
The problem is, I have many links inside my website, and I am not sure should I use an absolute or relative path.
From another question
Absolute vs relative URLs
I found someone suggesting using URL relative to root (like /images/abc.jpg), however when I access the website using example.com/mywebsite, every link just break.
For relative paths, I found it hard to manage since webpages are in different folders, but using the same template which contains some links. It means I have to manually set some links as ../ and some as ./.
I have also tried using <base> tag however it messes up with anchor. Even if I try to include the full path before the # symbol, some jQuery libraries does not function properly since they get the value inside the attribute href directly, but not extracting the part after #.
Would there be any better practice or suggestion?
I think you should use relative urls, and concentrate your searchs on how to use relative urls in templates, that would be resolved relatively to the final page.
I don't know the technology you are using for templating, but I see two common solutions :
declare a "relative path" variable in the template, and then override it in the different pages, with the new relative path. Use this relative path as a prefix for all urls
delegate urls construction to a service that would know the final page. Somethinkg like resolveUrl(..)
My website code sample:
<a href=/post/64/page-name><img src=/img-folder/2015/09/image.jpg></a>
<div id=cont2><a href=/post/64/page2>page 2 link</a></div>
My first question is, can I start links just with /? Is it a bad practise? because all website sources that I looked it starts with www.website.com/... not just /
Second question is quotes. It is not needed since html 2.0, but is it important in the example above?
My website is having some problems on google to show correctly... may it be because this problems?
It isn't bad practice. A URL starting with / is merely a relative URL that's relative the the base path. You're using it just fine.
Another example usage is when you want to reference a CSS or JavaScript file and you're deep down into the path.
<script src="/scripts/main.js"></script>
Then, no matter where the user is on your site, they'd always request http://example.com/scripts/main.js. Where example.com is your site's domain.
Additionally: Always quote attribute values. (attribute="value" and not attribute=value).
/ means start of where you are currently. So if your resource is located under same directory, you are allowed to use / to start with. If you refer to external resources, you can't use / to start. (E.g. www.google.com means google website, while /www.google.com means folder under your current directory named www.google.com, like http://localhost/www.google.com)
Quotes are needed when you use white-space in your attributes values (e.g. class="my super classs-name that has white-space" | class=my super classs-name that has white-space).
My website is having some problems on google to show correctly SEO stuff. What problems? Your page is not under first page of Google search? It's separate topic about that.
It is not forbidden. When you start your link with slash / it just a path relative to base element.
You can read more about BASE element here: http://www.w3.org/TR/html4/struct/links.html#h-12.4
For example, if you are already at: http://example.com/folder/index.html
/posts/index.html would link to: http://www.example.com/posts/index.html
posts/idnex.html would link to http://www.example.com/folder/posts/index.html
if you reference external sources you have to add the full path/adress
if you reference local resources its up to you.(more or less) take a llok at How to properly reference local resources in HTML?
You should use either double " or single ' qoutations - thats a good practise at least.
But you dont have to if there is no whitespace.
When you start your link with "/" its mean that you start from the root directory.
Example: Your website is in the directory /web/html.
When you now start your link with "/" its goes to the root folder. In this case the web folder.
I know this is old and answered, but it came up on Google when I was searching for something similar, so I just wanted to add to the answers.
Sometimes, when I need to do something real quick with simple HTML site that doesn't require a server, I usually just open index.html in Terminal to quickly preview the page in browser. However when you open your site like that, using the leading slash to load resources (ie. /js/main.js) won't work. That's because when you load your website by opening a file in your browser, the browser takes the root of your drive as the base path for your website.
So if you have your files like this for instance:
drive/Users/username/Documents/www/index.html
drive/Users/username/Documents/www/js/main.js
And you reference your script like this:
<script src="/js/main.js"></script>
The browser will think you're actually pointing here (if you open the file directly in browser):
drive/js/main.js
Because / in this case means drive and not the website's root (www in this case) folder as it would on a server.
Nope, it is not a bad habit to put '/' when starting links. But not having a quote in every html attribute? I don't think so. But i would suggest to put quote(") in every html attribute for it to be more readable.
Using has all of the issues on anchor-tags that were described in this question on base tags making it hard to use on my site.
I have a navigation menu in my site which references different parts of my site
for example
main/
|_index.html
|_section1/
|_1a.html
|_1b.html
and the navigation section on each page looks like
<div id="nav">
<ul>
<li>home</li>
<li>1a</li>
<li>1b</li>
</ul>
</div>
This works fine for all the pages on in the main folder but for pretty obvious reasons fails when I'm viewing a page in the section1 folder. I can't use <base> because I have a large number of anchors in documents (and I'm using markdown so I cant change the reference format easily).
I'm concerned that if I use absolute references on all my pages, when I upload this site to a server it will be a huge amount of work to replace the absolute reference on each page with a different one.
In addition main is a few levels down in my /home/ directory and I would prefer not to have to type a long path-name each time I refer to something if possible
I guess if I was pushed I could use sed to change all instances of the absolute path with something else but I wondered if there was an easier, obvious way of dealing with this in html that I'm missing. thanks
You can make use of htaccess, if you can't use <base> in HTML
I was wondering how other people are organising their assets for individual posts when using Jekyll. For example, if a post has an image, do you just dump it in a shared images folder? I don't really like the idea of doing this - it means that an image is completely separated from a post, when I think they should be paired.
I wrote a plugin to let me organise assets in subdirectories easily:
https://github.com/samrayner/jekyll-asset-path-plugin
{% asset_path my-image.png %}
in post 2013-01-01-post-title would output:
/assets/posts/post-title/my-image.png
in page my-first-page would output:
/assets/my-first-page/my-image.png
I prefer to think of images as stand alone assets that are included in zero or more pages. Most of the time, my images show up in a single page. There are times when I want to have them in multiple pages and in other cases I don't link an image at all. If your workflow is to put each image in a directory with a post, finding them starts to require a significant amount of searching and you have to come up with something different for images that don't belong to a specific post.
The approach I use is on the opposite side of the spectrum. I have a single image directory (served from "/images") and 100% of my images are housed there. Benefits of this are:
When I'm adding an image to a post it's easy to know what path to use. It's always:
/images/{image-name}
For example: http://alanwsmith.com/i/aws-20111017--0906-02. This makes it possible to write a plug-in so all you have to enter is the image name and the rest of the known path is filled out automatically.
With an application like Photo Mechanic, it's incredibly easy to browse the single directory locally and see every image. If I want to include an image on another page, this drastically reduces the time to find it.
There isn't a separate location/process if I want to send an image to someone without actually including it in a page (i.e. send them a direct link to the image file). I just throw the image in the standard directory and send the direct link.
If you want to get a little more advanced, keeping all your images in a single directory makes some nice tweaks possible as well. For example, even though the URLs for my images start with "/images", the images are actually stored in a directory outside of the ones jekyll uses. In my case, the top of my source tree looks like this:
./html
./source-files
./image-files
All of my images are stored in the "./image-files" directory. In my apache config, I've setup an alias so that the URL "/images" points to the "./image-files" directory. For example:
Alias /images /webroot/image-files
When I run jekyll, it process everything in "./source-files" and drops it in "./html". Because all of the images are outside those two directories, jekyll never sees/touches them. As your image library grows this will help speed things up and will prevent a tremendous amount of unnecessary file copying.
Another tweak I like in Apache is turning on:
Options +MultiViews
This lets you call your images without having to use the file extension (e.g. no '.jpg', '.png', etc...). You can see that in the example link I provided above. It doesn't really matter for performance. I just like the way it looks and it saves me from having to type the extension every time I'm calling an image.
MultiViews also makes it possible to replace an image of one format with another without having to recode anything else. For example, if you remove "some-image.gif" and replace it with "some-image.png", you wouldn't have to touch any HTML. It would still be served form "/images/some-image". Needing to make changes like that is probably exceedingly rare. I just think it's an interesting thing to be able to do.
Finally, you can make a single decision about allowing or disallowing your image directory to be browsed. Personally, I only want my images to show up where I place them. So, I've set the .htaccess file in my images directory to:
Options -Indexes
If you are going to be working on a site with many thousands or tens of thousands of pages and images, this might not scale. For a normal sized, personal site, I find that this approach makes maintaining images easier.
I have now managed to develop a Jekyll plugin that helps keep posts assets alongside the Markdown file:
https://nhoizey.github.io/jekyll-postfiles/
Just like you, I really hate having all images in one single shared folder.
Most, if not all, of my images are useful in one single post, and keeping them alongside the Markdown file is really better for posts management:
I can drop a new post as one single sub-folder of /_posts/ in one step, without having to put the Markdown at one place and the image(s) at another
When I want to edit the image(s) of an existing post, I don't have to find the right image in a huge /assets/ folder, it is located just near the Markdown file
In my Markdown, I can use the image file name directly, without any path
If I want to use any Markdown editor with live preview, it works, no need for a specific assets folder configuration
I tried to have this for my blog (example post here).
For responsive images, I used the Jekyll Picture Tag plugin, but I had to fork it, because the Pull Request to deal with such paths was not accepted.
Now that Jekyll 3 is there, I wish it could let us use images both in a post folder AND in the /assets/ one, looking for an image marked with  in both, in that order.
For JavaScript and CSS, you may want to consider an asset pipeline. You can get a good performance improvement through bundling and compression. I also use CoffeeScript and Sass, so I needed a preprocessor to convert my assets. I use Jekyll Asset Pipeline to manage this whole process automatically when I run the jekyll command.
For images/video, I recommend you develop a convention for naming folders in your project. I generally have an "assets" folder then subfolders with the date of each post that holds the images related to those posts. If you have multiple posts per day, you might consider including the name of the post.
This answer:
Does not use plugins (works with GitHub Pages)
Allows you to keep images directly next to their relevant posts
Allows you to edit using Typora locally and see the images WYSIWYG
Just name your folders like _posts/2020-10-10-My-Title/ and include files like index.md and hero.svg or other images.
Then set your permalink: key in _config.yaml to :path.
Caveats:
Your folder names must be sluggified
Your images must all be SVG