I have 2 cfm pages in the same folder, doing very similar things. They both produce some reports for user related data. I recently added a loading image to one because some of the queries to generate the reports can take a while.
The second page is a new but very similar page. Since the pages are in the same folder I figured the relative path to the loading image should be the same. However the new page is giving a 404 response for the image request, and when I check the http request header it is adding an extra folder to the relative path and thus unable to find the image.
<img src="../../../Graphics/General/loading.gif">
They are both very similar pages in that they display a simple form, then run some queries and generate a table to display the relevant data to the user. However the relative path above produces "Dev/Menu/Graphics/General/loading.gif" in one page and "Dev/Graphics/General/loading.gif" on the other.
I've since figured out that adding an extra "../" to the image path in the new file has fixed it for the new page, however I am at a loss for why this fix was necessary and why it worked.
<img src="../../../../Graphics/General/loading.gif">
I would expect that since both pages are in the same exact folder, that the relative path to the given image would be exactly the same. I am mostly just curious why that is not the case.
The two reports are in the same folder. Are you loading these pages directly?
yourSite.com/reports/report1.cfm
yourSite.com/reports/report2.cfm
Or are these files loaded via other parent pages?
yourSite.com/some/other/folder/with/include_report1.cfm
yourSite.com/yet/another/folder/that/contains/include_report2.cfm
Often, it's better to load images directly from web root in order to avoid relative pathing issues like these. If the Graphics folder is at the root, then just reference the image in both files like so:
<img src="/Graphics/General/loading.gif">
This way, it doesn't matter what file includes them and renders the final HTML to the browser, the image will be referenced from the web root no matter what.
I am trying to include some images in a Genshi template for my Trac plugin, but it always shows only the alternative text because it cannot find the images.
I have the following (X)HTML code:
<div>
<img src="file://c:/path/to/image.png" alt="asdf" />
</div>
When I use this code with a simple html file and open it in the browser, the image is displayed correctly, which means that both the path and syntax are correct.
But when I insert the code snippet into a Genshi template and use it within Trac, the image cannot be found. However, when I look at the HTML source code in the web browser and copy the URLs into a new browser tab, it is again displayed correctly. This means that only the server cannot find the image.
The images are in a directory inside the python-egg file, and the path points directly to the directory created by Trac, which also contains my CSS and HTML files, both of which are loaded correctly. The images are correctly referenced in the setup script which creates the egg.
How do I have to reference images in (X)HTML documents when using them with a server?
Is there a special way to include images in Genshi documents? (I haven't found one.)
Thanks to the comment of RjOllos and this site I was able to fix it by trying all of the URL types. Although it says for a plugin to be /chrome/<pluginname>, it was actually just /chrome that worked. See the edit below! So the full URL is then <ip>:<port>/chrome/path/to/image.png.
EDIT: I discovered I actually used the /chrome/pluginname version, just that I did not use the name of my plugin as "pluginname". See my comment below. It seems like /chrome/pluginname should actually be /chrome/htdocsnameor something like that, in case you use a different name rather than the plugin name when implementing the ITemplateProvider. In my case I called it images, which was the same name as the folder. END OF EDIT
Another mistake I made was forgetting the initial slash (chrome/path/to/image.png), which caused Trac to assemble the URL to <ip>:<port>/<current page>/chrome/path/to/image.png.
I just started using google app engine. In order to use templates, I'm using jinja2.
I want to add images dynamically after I set the width and height of the img tag. I used
PIL in order to read the image size and put the one I want.
However when I open the image with PIL, I need it not to be in a static_dir
and to put the image in the img tag, I need it to be in the static_dir.
As a testing solution I've copied the folder to see if I get results and I did. But as
you can see having each image saved twice is kind of bad.
If you want the file to be both static (served fast by not having to pass through your app) and available to the app, note the application_reabable option in the description of static file handler patterns. It does want you want without you having to duplicate files.
I work on a very large enterprise web application - and I created a prototype HTML page that is very simple - it is just a list of CSS and JS includes with very little markup. However, it contains a total of 57 CSS includes and 271 javascript includes (crazy right??)
In production these CSS/JS files will be minified and combined in various ways, but for dev purposes I am not going to bother.
The HTML is being served by a simple apache HTTP server and I am hitting it with a URL like this: http://localhost/demo.html and I share this link to others but you must be behind the firewall to access it.
I would like to package up this one HTML file with all referenced JS and CSS files into a ZIP file and share this with others so that all one would need to do is unzip and directly open the HTML file.
I have 2 problems:
The CSS files reference images using URLs like this url(/path/to/image.png) which are not relative, so if you unzip and view the HTML these links will be broken
There are literally thousands of other JS/CSS files/images that are also in these same folders that the demo doesn't use, so just zipping up the entire folder will result in a very bloated zip file
Anyway -
I create these types of demos on a regular basis, is there some easy way to create a ZIP that will:
Have updated CSS files that use relative URLs instead
Only include the JS/CSS that this html references, plus only those images which the specific CSS files reference as well
If I could do this without a bunch of manual work, if it could be automatic somehow, that would be so awesome!
As an example, one CSS file might have the following path and file name.
/ui/demoapp/css/theme.css
In this CSS file you'll find many image references like this one:
url(/ui/common/img/background.png)
I believe for this to work the relative image path should look like this:
url(../../common/img/background.png)
I am going to answer my own question because I have solved the problem for my own purposes. There are 2 options that I have found useful:
Modern browsers have a "Save Page As..." option under the File menu, or in Chrome on the one menu. This, however does not always work properly when the page is generated by javascript
I created my own custom application that can parse out all of the CSS/Javascript resources and transform the CSS references to relative URLs; however, this is not really a good answer for others.
If anyone else is aware of a commonly available utility or something like that which is better than using the browser built in "Save page as..." option - feel free to post another answer.
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