I need to link to files in my domain. I don't want to use the full https://my-domain.com/dir-1/file.gif
Assuming the file isn't in a subdirectory under my current page but is in another subdirectory off somewhere. How do I link to it with minimal coding?
There's a lot of info on the web about html links but usually after one basic example they diverge off into coding colored links or css.
This may also be an irrelevant question but is there any way I can have a unique page identifier and link to that page even if it's location or name changes? I do not want to use another #$%^&?! CMS system.
Say your index file is in the root directory, and you want to link to that gif in your dir-1 directory, you'd need to use dir-/file.gif as your url.
If as an image:
<img src="dir-1/file.gif" />
Related
How can I change the path of my site using HTML, CSS, or JS. I may be using the wrong grammar here using the word "path", but what I'm referring to is a subdomain, an example would be stackoverflow.com --> stackoverflow.com/questions
I attempted to use the element
<a href="about.html">
<img src="x">
</a>
but it did not work,
You could think of a server's public folder (the one that host your site's static files as HTML, CSS, Js) as a directory in your computer. For you to redirect the user to another path in your site you can use as you said Your link but keep in mind that if you want to go to another folder like yoursite.com/anotherfolder you must to have two things (for this example):
This folder structure in your site:
[ROOTFOLDER]/anotherfolder/index.html
In this case you need to add another file called index.html because is the default path that you get when no file is specified (file being specified: yoursite.com/anotherfolder/file.html).
The HTML anchor tag must to start with a slash like Your link.
Hope it answer your question.
Note
You are talking about a path http://yoursite.com/[PATH], a subdomain is like this http://subdomain.yoursite.com.
I just came up with an idea. Instead of using an .htaccess file to remove .html from the URL, why not just use a simple folder structure and in each folder add an index.html?
For instance:
example.com/index.html → Home
example.com/about/index.html → About
Now simply use a hyperlink on the homepage to the about folder, since typically index.html files are opened automatically.
The upside of this kind of navigation, is that it would be easily possible to create sub pages with no crazy database / .htaccess setup.
Now my question is: is there any reason not to create a webpage like that and is it legitimate to use multiple index.html files?
I appreciate all the help.
With the index.html route, there would be three URL's that can access the same page. For example for an about page:
www.yourwebsite.com/about
www.yourwebsite.com/about/
www.yourwebsite.com/about/index.html
Using the .htaccess file would likely give you more benefit from an SEO perspective. You can tell the search engine which one to use, by using 301 redirects. See more about how Google does this here:
https://webmasters.googleblog.com/2010/04/to-slash-or-not-to-slash.html
Of course you could set up your website using folders and index.html's, and still
use the .htaccess file to take care of the SEO. But, depending on your sites size and structure, this might be more work.
The only downsides would be having to create a folder in addition to a file whenever you want to create a new page, and having to take more time to navigate into a folder in order to edit a page.
As long as you are using Apache, or a similar server software, multiple index files will function normally and be served from each folder.
When I code my website, on my local computer i can use
blablabla.
However, I also can see this type of thing on other places as
blablabla.
I am not sure what I will need when my site goes live. If I try to do this on my local computer, it doesn't understand it. My question is, if I post my site up like this, will it work?
Ok, if I have all of the files of my site in the root directory that the main index.html file is located in, will it work when it is being hosted?
If you do not use a slash, the link will point to index.html in the same folder as the page the link is on.
For example, if you have a link to index.html on the page www.example.com/page2.html then the link will take you to www.example.com/index.html. If you include a slash, it will do the same thing.
However, if the link is in a page in a subfolder, like www.example.com/projects/page2.html, then the first link will take you to www.example.com/projects/index.html while the second link will still take you to www.example.com/index.html.
The slash denotes the "web root."
Note that these are still considered "relative" links: they refer to a resource on the same server, regardless of the server's name. If your domain name changes or you upload it to another server, relative links will still work provided they have the same folder structure.
I'm using Doxygen to create html output.
I'd like to customize the output so that the index.html file could be more noticeable, since at the moment it is buried half way down a huge list of files in the html output folder.
For example, if it were moved up one directory to be outside of the 'bits and pieces' html files then it would be much more accessible for others who will be looking for it. However, I can't just ass a line of script to copy it to that location, since all of the links it has would break.
If I could configure Doxygen to have the index file go to a different location, or if you can think of another solution to my problem, I'd be grateful for your response.
Thanks
I would leave the documentation in its place and instead use the meta refresh option of the HTML language. Place a file, for instance called, "Documentation.html" in any folder you want with the following content
<meta http-equiv="REFRESH" content="0;URL=RELATIVE/PATH/TO/index.html">
As I mention in comments to the OP the easiest solution is probably to create a symbolic link or shortcut to the index.html file generated by doxygen, rather than trying to get doxygen to change the layout of it's output files. This symlink/shortcut can then be placed in the root directory of your project (or elsewhere), pointing to ./html/index/html, and named anything you like to make it obvious to your users what it is.
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