What is the logic behind relative paths here? about permalinks HOT 18 CLOSED

I also wondered at the functionality's purpose. I guess if you link to test.txt from index.html, the link will break once the permalinks are resolved. I personally added an option to turn the relative files functionality off entirely because I was bending over backwards to avoid it.

from permalinks.

If that is the problem that copying sibling files over solves, then I think a better solution might be in order... maybe metalsmith-permalinks could provide some metadata about the directories? For example:

Macbook:project me$ ls -R src/
css page1.html

css:
style.css

Could generate this build

Macbook:project me$ ls -R build/
css page1

css:
style.css

page1:
index.html

And then also create the metadata pl.css which could be the dirname of the css folder. You'd have to run metalsmith-templates after permalinks though. Not sure if that can be worked around.

from permalinks.

Using symlinks instead of actually copying over files is another option.

from permalinks.

ah yeah, i added that functionality because linking to things like images is super nice to be able to images/whatever.png in the markdown and not have to worry about where the file might end up (which would make it a leaky abstraction)

i'd be super down for a PR to have the copying of files be an option called relative or something that defaults to true

i'd also be down to accept a PR that adds a symlink option defaulted to false that would make them symlinks too.

both sound like great ideas

from permalinks.

I'm not sure about the global directory metadata feature. Consider this source dir..

$ ls -R source/
index.html post.html jobs css

jobs:
resume.html

css:
style.css

If index.html, post.html, and jobs/resume.html all linked to css/style.css, then what use would be the metadata about the css folder?

It's okay if the links from post.html and jobs/resume.html are different (i.e. {{pl.css}} and ../{{pl.css}} respectively), but the links from index.html and posts.html should be the same. They should both be {{pl.css}} as in the source file structure, but the one piece of metadata can't link both of them correctly since post.html would be moved one level deeper and index.html wouldn't.

Maybe you'd thought I meant file-local metadata all along, but I've been thinking about global metadata. File-local metadata would be the solution since permalinks can handle edge cases such as index.html and post.html needing different link directories.

from permalinks.

ah sorry, i'm not sure a metadata change is the way to do it. i'd rather it just be behind two options i think. updated my last comment there to make it clearer

from permalinks.

Are you sure? I think adding new file metadata about the original source directory structure would be a really clever and transparent solution. Would basically be a map of relative paths for each file.

Oh, cool. I've already done the relative / family option on my branch. I'll set up a PR tonight.

from permalinks.

Files could link to the value of link["css/style.css"], where link is an object that is generated for each file. And then templates can read that and put the actual relative link there.

from permalinks.

the only problem i see with that is that it makes using permalinks with markdown a lot more complicated. right now we can just do ![](/path/to/image) and it works like people would expect for a static site

from permalinks.

I see. That is a big problem. I wish there was a way to do this nicely! I'll keep thinking about it.

from permalinks.

I was thinking about the symlinks option, and realized that it should probably create new files that are marked as symlinks somehow and will be output as symlinks by Metalsmith. Do you agree?

from permalinks.

I.e. add to the files object some file with symlink: { source: '../path/to/foo/bar' } metadata, or something. Do you have any thoughts on this?

from permalinks.

mm yeah that makes sense. dang haha, one more thing to add to the metadata api. what are the other options for symlinks that you were thinking about being in that object? otherwise would be nice to just do symlink: 'path'?

from permalinks.

I didn't seriously consider any other options... A new symlinks object is obviously not a good solution since we'd have to pass that around (just to throw a new idea out in the air). Not sure if there's any better way to do it than adding a symlink metadata API.

I was thinking that files['path/to/symlink/dest'] = { symlink: 'path/to/symlink/src' }; would be kinda nice. Symlinks are files so it makes sense semantically.

from permalinks.

[ closed by mistake ]

from permalinks.

yeah that sounds like a good solution to me

from permalinks.

Cool. I was working on this night but ran into issue #41 in the metalsmith repo :P I'll work on it again tonight.

from permalinks.

TIL /link/from/root/ is a thing, and all my worries about writing links are resolved

from permalinks.