Map published file to md file name

[rinkug]

Need an easy way to find the name of the md file that a published article is based on.

Right now, we need to look at the source of the published html page and find "file path" to get the name of the md file.

[bernhold]

I don't think we want this viewable in the public page. So it seems that the two options are to embed it in the generated HTML, which is what we currently have. Or to follow conventions for the relationship between the filename and the article title, which we kinda do in some cases, but for blogs and events, I believe that a date-based file naming convention is more helpful.

If anyone has alternative suggestions, please speak up.

[bernhold]

My suggestion would be to figure out something more memorable than "file path", and/or see if it is possible to move it to the very top or very bottom of the file.

Maybe "markdown-source"?

[markcmiller86]

Would the equivalent of something like an Edit this page on GitHub button or link solve this? Honestly, any such link anywhere out of the way on the page would do this. Why not added to footer material among all the logos and other stuff we have down there?

[bernhold]

@markcmiller86 that might work, as long as it does not become an attractive nuisance. I have seen it on a variety of web sites, do I'm guessing that its not terrible for most of them.

Does anyone have experience what happens when someone who does not have write access to a repo follows such a link? I supposed they're prompted to fork the repo and create a PR? That should be safe enough, I would think.

[bernhold]

I just tried it on another site. The link there was "View on GitHub" and it took me to the top of the repo rather than the file. In our case, we'd want it to go straight to the file in question. When I tried to edit a file, it opened the editor as usual, but with a notice at the top saying that if I submitted the change, it would create a fork and from it a PR.

[markcmiller86]

Does anyone have experience what happens when someone who does not have write access to a repo follows such a link? I supposed they're prompted to fork the repo and create a PR? That should be safe enough, I would think.

If the link is setup correctly (for an edit this file like button and to the actual file and in edit mode) then the fork might happen as part of the act of following that link. That may be undesireable. The solution is to setup the link to the file and not put it in edit mode.

[markcmiller86]

I just tried it on another site. The link there was "View on GitHub" and it took me to the top of the repo rather than the file.

I see that a lot in jekyll templates that get copied and site developers don't bother updating the logic in their layouts that creates that button. Its very easily fixable though.

[markcmiller86]

Another option...have backend add some balloon text to a link somewhere inconspicious. Editers can know to hover over that link and get the actual file name.

I think these approaches are a bit nicer than searching the raw html or maintaining a manual mapping somewhere or forcing filenames to take a certain convention (though conventional naming is very nice for other reasons).

[bernhold]

I originally mentioned conventions for file names as an option, but I would actually prefer not to go that route-or at least not based strictly on the title. One reason is that titles tend to be long, and are not infrequently modified as the article is developed. Meaning the author would have to to remember to follow along with the changes and the longer the title/filename, the more error-prone and unwieldy that becomes.

But also, for blogs and events, I strongly prefer a convention that starts with a publication/event date. The rest could be based on the title, but usually a keyword or phrase suffices once you've got the date. When I'm looking at files in these areas, key dates are almost always the easiest thing to key on. This is not so useful for cc articles, of course.

[rinkug]

@bernhold and @markcmiller86 : I no longer, personally, care about this issue. Perhaps I have become adept in finding the md file names from source data, file names etc. :)

If any of you still care about this issue, we can keep it open else I recommend we close it

[markcmiller86]

@rinkug I think you should feel wholly comfortably closing issues you think should be closed without seaking others' approval ...especially those issues you opened. We can always re-open them if we need to 😉