image with relative path

[ikus060]

Hello, I'm trying to use Jekyll-assets. I'Ve having issue to understand how to make reference to a relative path. e.g.: /foo/download.md /foo/my_image.png

In download.md, how make references to my_image.png ? I've try the following but fail with an exception:

{% img "./my_image.png" magick:resize:300x300 %}

$ bundler exec jekyll build --trace
Configuration file: /home/ikus060/workspace/WWW/pdsl-www.git/_config.yml
            Source: /home/ikus060/workspace/WWW/pdsl-www.git
       Destination: /home/ikus060/workspace/WWW/pdsl-www.git/_site
 Incremental build: disabled. Enable with --incremental
      Generating... 
          Defaults: The 'post' type has become 'posts'.
          Defaults: Please update your front-matter defaults to use 'type: posts'.
          Defaults: The 'post' type has become 'posts'.
          Defaults: Please update your front-matter defaults to use 'type: posts'.
          Defaults: The 'page' type has become 'pages'.
          Defaults: Please update your front-matter defaults to use 'type: pages'.
          Defaults: The 'page' type has become 'pages'.
          Defaults: Please update your front-matter defaults to use 'type: pages'.
                    undefined method `start_with?' for nil:NilClass
  Liquid Exception: undefined method `start_with?' for nil:NilClass in fr/minarca/download.md
/home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/sprockets-3.5.2/lib/sprockets/path_utils.rb:113:in `split_subpath': undefined method `start_with?' for nil:NilClass (NoMethodError)
    from /home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/sprockets-3.5.2/lib/sprockets/path_utils.rb:128:in `block in paths_split'
    from /home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/sprockets-3.5.2/lib/sprockets/path_utils.rb:127:in `each'
    from /home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/sprockets-3.5.2/lib/sprockets/path_utils.rb:127:in `paths_split'
    from /home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/sprockets-3.5.2/lib/sprockets/resolve.rb:95:in `resolve_relative_path'
    from /home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/sprockets-3.5.2/lib/sprockets/resolve.rb:33:in `resolve'
    from /home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/sprockets-3.5.2/lib/sprockets/legacy.rb:66:in `resolve_with_compat'
    from /home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/sprockets-3.5.2/lib/sprockets/base.rb:64:in `find_asset'
    from /home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/sprockets-3.5.2/lib/sprockets/environment.rb:30:in `find_asset'
    from /home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/jekyll-assets-2.1.2/lib/jekyll/assets/liquid/tag.rb:149:in `find_asset'
    from /home/ikus060/workspace/WWW/pdsl-www.git/vendor/bundle/ruby/2.1.0/gems/jekyll-assets-2.1.2/lib/jekyll/assets/liquid/tag.rb:82:in `render'

[envygeeks]

We don't allow relative files, if it's not in the asset folders it's not processed. Sorry.

[ikus060]

Well, this make sense then. May I suggest to add this information into the README file.

[envygeeks]

@ikus060 yes, I do plan to in the next few days, I also plan on filing a bug in Sprockets as the error you got originates from Sprockets (I don't know if it's because of us or not) so I plan to address both the surface of this issue and the underlying throw that didn't just reject the relative path.

[nhoizey]

Wouldn't it be awesome if we could put images in the same folder as markdown files?

I'm doing this for my blog: https://github.com/nhoizey/nicolas-hoizey.com/tree/master/_posts/2015/06/24-un-moteur-de-recherche-sur-un-site-statique-facile-avec-algolia

I currently use my own patched version of the picture tag plugin to do this, waiting for #172… ;-)

I have many posts with images, which are almost always used only once, so having all these in assets/ doesn't make any sense, it's painful.

With images in the same folder as the post Markdown file:

• I can add a post to my blog just by dropping one single folder containing all content of the post
• I don't have to write long image paths in my Markdown

I think Jekyll Assets could first watch for images in the post folder, before watching in the global assets/ folder. It would keep existing behaviour, but also let us better organize our assets.

[nhoizey]

More on this topic: http://stackoverflow.com/questions/10363812/local-post-assets-with-jekyll/35270428#35270428

[envygeeks]

I know I know, I plan to get back to Jekyll Assets and make it more awesome soon, give me a few days.

[nhoizey]

@envygeeks no worry, it was just food for thoughts, I can't push you while doing nothing to help… ;-)

[envygeeks]

I am debating doing this tonight. It is mad easy to do, but we must come to a compromise.

1. Your paths will _not_ land anywhere but /assets when written.
2. Your assets will be saved without their sub-folders.

If you can concede to me making any imaage or asset available to you but the path being defined by the system I'll build this. Otherwise you just upped the game to a level I'm not willing to deal with (path sanitization, caring about all sorts of other stuff.) If you can concede to those, I can detect non-default paths, strip them down to the asset and just save them, making all your relative paths available wherever you want, but they'll land in the assets folder at the end of the day.

[nhoizey]

@envygeeks that would already be awesome, thanks a lot!

[envygeeks]

Consider it done in the next few days then, since I'm free to work on this when I'm bored.

[nhoizey]

Great, thanks!

[nhoizey]

By the way, does it mean you will also work on #172, after?

Sorry, just saw you moved it to 3.0.0

[envygeeks]

That one is iffy for now, but there are plans for responsive images and integrity for assets soon.

[nhoizey]

Great news, I'll be patient… ;-)

[envygeeks]

While I would like to support this feature, I kind of think the amount of work it would require is far too high for such little benefit (the community has expressed little interest,) and nobody is willing to sponsor this feature so development time is being put towards other sponsored features.

That said there are also technical difficulties:

• we heavily use a manifest
• if we add paths on the fly, they will never get recognized because of cache
• the manifest uses cached, which uses cache