Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimized Image Paths for Dynamic Src #406

Closed
michael-cantera opened this issue Sep 12, 2012 · 10 comments
Closed

Optimized Image Paths for Dynamic Src #406

michael-cantera opened this issue Sep 12, 2012 · 10 comments

Comments

@michael-cantera
Copy link

I'm working on a Yeoman BBB project and have run into an issue regarding the modified filenames for optimized images.

For anyone unfamiliar, after you run yeoman build, images are optimized and saved to /dist with a new file name, such as 11d610e7.yeoman.png. Conveniently, any <img src=... references to those images are updated to point to the optimized images with their new file names.

In my application, this feature works perfectly for three types of images:

  • static images coded directly in a page, such as an <img> src on index.html pointing to a logo image
  • images coded directly in a template that gets loaded by the application, such as BBB's main.html layout template
  • images coded directly in a template that gets loaded by another template, such as module templates in BBB

What doesn't work, however, is when you have an img src that is loaded into a template using an JSON/HTML from the server or a client-side data source.

So for example, if you reference an image path like this in your template...

<div class="edit">
    <%= image %> <input class="todo-input" type="text" value="<%= content %>">
</div>

...the image path imported via <%= image %> will continue to refer to the non-optimized img src even after running yeoman build.

Does anyone know how to make yeoman build aware of the dynamic image paths so that they are reflected in the post-build /dist?

@addyosmani
Copy link
Member

Just thinking out loud: I wonder if having some sort of local image/path config file that could also be populated with the paths of these images with some reference to the older image might allow you to match up the local filenames with templates being returned from the server. Theres prolly a much better soln.

@michael-cantera
Copy link
Author

I found a workable but less-than-ideal solution for the image renaming issue. It's pretty simple -- I just put all images that are loaded dynamically in a separate directory from the one that Yeoman/Grunt is using for the optimization step.

This means having to manually optimize those images, but it also prevents messing up the file names for SEO. I suppose this is logical since most "content images" wouldn't be available during the build phase and would require manual optimization anyway.

From the Yeoman/Grunt perspective, a better solution would be to "opt out" of the file renaming for images only. You'd think that would be possible by removing the img line from the Gruntfile's rev property, but this apparently breaks the image optimization step entirely.

If anyone knows how to tweak the build specs so that the images can be optimized but not renamed, please post it here since this seems likely to affect others also.

I'll leave this open for a bit in case anyone else knows the right way to customize the build. Feel free to close if needed.

@humantorch
Copy link

I'd like to second the motion for adding in some kind of true/false flag for image renaming during the build process. My situation is that I'm using Fancybox to generate an image gallery, and all of my thumbnails are coded as such:

<li><a rel="gallery1" href="/images/fb/500.jpg"><img src="/images/fb/500-c.jpg"></a></li>

The src attribute in the img tag is being updated correctly with the renamed image file, but the href attribute in the anchor tag is not, causing all of my lightboxes to display broken image references. Kind of a colossal pain to have to move images in/out of the directory every time I want to build. :(

@alexeygolev
Copy link

@humantorch try this

rev: {
      img: ['images/**','!images/dyn-src-images/**']
    }

just put all your dynamic source images into dyn-src-images

ps. respect for Guinness on your userpic:)

@humantorch
Copy link

Fantastic, thank you @alexeygolev! That pretty much fixes the issue. The only downside is that images in the dyn-src-images directory aren't run through jpegtran and/or optipng, but I can easily work around that. Cheers!

@alexeygolev
Copy link

@humantorch would love to see your optipng workaround

@humantorch
Copy link

It's not much of a "workaround" at this point, after running yeoman build I'll run optipng from the terminal on the directory with the dynamic images as a separate process since it doesn't rename images when run standalone.

If I were smarter in the ways of process automation and what not I'd bake that into the build process myself, but delving into the world of Grunt and build scripts beyond out-of-the-box functionality is still fairly new to me so I haven't figured that all out yet.

@rcolepeterson
Copy link

anyone else have a solution? other than the above workaround?

@kraftwer1
Copy link

I experienced the same when I was trying to dynamically include a .css-file. I found out that Yeoman parses and replaces href=""-attributes in all link-tags in all .html-files, but I needed that in a .js-file. It also seems to check the existence of that specific file. In order to work around I put a little script in the head of my index.html which saves the path to the .css-file in a variable:

var cssPath = '<link href="/path/to/an/existing/stylesheet.css" rel="stylesheet">';

It's not elegant at all, but it works. I think what we really need would be something like <% yeoman-url(/path/to/asset) %>-tags that works in every file.

@tylerbuchea
Copy link

I'm sure most of you have found this link, but if not here is a solution. http://stackoverflow.com/questions/14262460/prevent-yeoman-io-from-minifying-images

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants