I want to make a template using Templater that meets all of the following conditions…
There is frontmatter written in the template file that applies ONLY to the template file it is written in (not the note that comes from the template)
There is other frontmatter written in the template file that applies ONLY to the note that comes from the template
There is frontmatter written in the template file that applies to BOTH the template file it is written in as well as the note that comes from the template.
Right now I just need to learn how to do each of these use cases so that I can apply them as needed in the actual templates I plan to make. Someone recently suggested a method whereby the frontmatter you don’t want in the note could be removed from the note after creation - but this is does not really satisfy the first or second use case - resulting in a situation where you may or may not have shared frontmatter in both the template and the note but not unique frontmatter in the tamplate that is not in the note. One ideal scenario would be if it is possible to designate some part of the template content as not be part of the template per se but as part of the file the template content is written in (if that makes sense). If that were possible then it could be used to solve at least the first use case.
Ultimately the goal is this…
To be able to write templates where the templates themselves can have their own frontmatter with its own values to the keys AS WELL AS having frontmatter in the template that becomes part of the note that’s created from it - those notes having their own unique values to their keys.
Any suggestions / solutions / direction would be greatly appreciated!
The answer to this request is the same as in the other thread: It can’t currently be done unless you implement your own scheme to handle the various cases.
@AlanG in his code example used code that comes from the Obsidian API (not just Templater) code. Considering that and the fact that in every other Obsidian note (when it is not a template) the frontmatter applies to the note / to the file it is written in would make me think that there is a way to designate frontmatter written in a template file to NOT be part of the note created from the template but rather to the file the template content is in. I’m not an expert with coding or with the Obsidian API but given the ability to write code for both Obsidian as well as Templater I would guess that there is a way to do this. I’m asking because I’m not expert enough to come up with that solution on my own.
I’d also like to point out that while this question shares a similarity (in part) with the other one it is not at all that same question. Only one of 3 things was addressed in the other thread and what was given was not really what was asked about in that thread. No offence - I appreciate the help I truly do - but what I’m after is not going to be addressed there. Now, after having some preliminary discussion about it, I was able to firm up my question and add to it (here).
I looked at that other thread more carfully (read and re-read the responses) but I don’t understand how there wouldn’t (in the absence of Templater code) be some Obsidian code that removes / extracts / excludes some designated chunk of content in a template file as pertaining to only that file (not having any “template” functionality).
There is, and it’s what I put in the other thread (the Obsidian code is app.fileManager.processFrontMatter):
<%*
// Add this at the end of your template file
// Add/remove properties from the newly created note.
// The reason for the timeout is to wait until after the new note exists in your vault.
setTimeout(() => {
// Get the path to the new file
const newFile = tp.file.find_tfile(tp.file.path(true))
// Process the frontmatter
app.fileManager.processFrontMatter(newFile, (frontmatter) => {
// Add a new field
frontmatter['A new field'] = 'some value'
// Or delete the properties you don't want
delete frontmatter['Some frontmatter field']
})
}, 300)
%>
Exactly like @holroy said, you have to do it yourself (using the Obsidian code that removes / extracts / excludes some frontmatter).
There is frontmatter written in the template file that applies ONLY to the template file it is written in (not the note that comes from the template)
these are the ones you delete.
If you wanted to make it more automatic, you could choose a field naming structure that only applies to templates, and delete any field that matches that.
For example, remove any field that starts with template_, like template_location, template_name etc:
There is other frontmatter written in the template file that applies ONLY to the note that comes from the template
Since frontmatter doesn’t “apply” to templates anyway, these are just the ones you don’t delete. You should be filtering your templates folder from any Dataview queries, etc, so their frontmatter is moot.
There is frontmatter written in the template file that applies to BOTH the template file it is written in as well as the note that comes from the template.
I’m sorry I must have been misunderstood and / or be misunderstanding what is being described. It doesn’t seem like we’re talking about the same objective. Probably I’m just not getting it. I thought about an idea for what I was hoping for but I guess that won’t work. Somehow I don’t feel like I’m being heard because when I read the responses they seem to give the solution to a different objective. Thanks for trying.
Its my fault. I didn’t know what I was asking about at first. After having dialogue about it the idea have kind of firmed up in my mind.
app.fileManager.processFrontMatter is the way. I’ve tried a few different examples online, and this is the only one I’ve been able to get to work concisely and reliably.
Adding a timeout is the key; the file must exist on disk before you update the frontmatter using this method.
these are the ones you delete.