Ross Gardler wrote:
> Don't use relative paths would be my first thought. Forrest is designed
> to not need them since relative paths break easily when a file is moved.
> However, I'm guessing that this is legacy content being imported and so
> you don't have such control.
Thanks.
It is actually new html-content. I guess what you are suggesting is to
use references like /images/bla/imagexyz and create an entry in my
project sitemap to automatically rewrite /images/-references to point
to the correct directory. Which would work but I simply didn't
understand it when I doing this project :-)
And I guess other people will also use this very standard approach to
addressing so it should'n really make Forrest write in directories
that are (worst case) even below the project directory.
> The "semi-intelligent" approach you describe is the fallback mechanism
> that Forrest uses when resources cannot be found where they are
> expected. This is defined in the locationmap [1] :
> <match pattern="project.images.**.*">
> <select>
> <location src="{project:resources.images}{1}.{2}" />
> <location
> src="{project:content}../resources/images/{1}.{2}" />
> <location src="{project:content.xdocs}images/{1}.{2}" />
> <location src="{project:content.xdocs}{1}.{2}" />
> </select>
> </match>
Wait, this is Forrest 0.7. So no location maps to blame for it.
And I'm not looking for a solution that I could implement (see above),
I'm just worried about Forrest creating havoc on some unsuspecting
users hard disk.
--
Ferdinand Soethe
