Included markdown file in content files

This was originally mentioned in the comments of #439, and later I mentioned it again in #532. This is a different topic though, so it gets its own issue.

There is a common desire to in some way include a markdown file by reference in a content field of a contents.lr So instead of a markdown body field whose section in a contents.lr looks like

body:

**Some Markdown here**
and here.

The value for the body field would point to an external .md file. The ability to separate out a (large) field’s value can make it easier to maintain that field (it could be outside of a project repo, it could be “hot swappable”, etc), and break apart a large contents.lr into more conceptually digestible chunks.

This could be done for a variety of different field types, and potentially arbitrary field types, though I think it makes the most sense for multi-line string-like types.

So how do we accomplish this? An option is to allow for attachments of other various types, detected by file extension, and then allowing the ability to select attachments via the CMS. Another option is to add a way for someone to input a relative path in the CMS / contents.lr that can point to any file. Do we let users define file types in models? Do we force them? There are lots of ways this could be done and discussion is welcomed.

[nixjdm]

I’m not talking about treating a contents.lr as a markdown file, but more like the comment that follows the one you cite - including an external file by reference in an contents.lr. My question is, what method is best?

I realized that one way this could work is by virtue of my plugin Jinja Content. For instance, with this, you could actually reference any other file and pull it in with a standard jinja include. E.g.

body:

{% include "my_content.md" %}

This nearly works right now, but I think Lektor would need a couple small updates to https://github.com/lektor/lektor/blob/master/lektor/environment.py, and the plugin would need to add some paths to support “templates” being in the contents dir.

Some points about this approach:

• This won’t require a ton of effort I think. I hardcoded a few things to test it quickly, and the proof of concept works.
• Standard jinja tagging, which is nice
• More flexible than the idea of having either markdown in contents.lr directly or included by reference, being mutually exclusive. With this, you could mix and match, or even have multiple includes in the same field.
• I was originally envisioning some helpers in the CMS. A file select widget for instance to find and select a file. This is just coded in manually, which is kind of less friendly, but on the other hand it enforces working only in certain “template” paths, which is good. That means someone can’t reference something outside their project.

If that’s the route we take, Lektor itself would only be changed to allow the functionality by the plugin, and the plugin’s doing most of the work.

[xlotlu]

That feels like to much magic, I would rather have it be explicit

Yes, it shouldn’t be auto-magic. I was thinking it could be a global setting, or per-field:

[fields.body]
type = markdown
include = true

Then we’d have a single content-type for any given format, and the only change needed to the existing types would be to give them a set of extensions to look for where appropriate. Or (also) make it explicit in the model:

[fields.body]
type = markdown
; this could be implied if any of the below are true: 
include = true
; I don't particularly like this one:
include-file = body.md
; I'd rather have the filename implied
include-extensions = md, markdown