Can you have frontmatter in a template that pertains to the template itself and not what comes from the template? Can you have both? How?

[Blahboybaz]

As the title says… Based on the nature of a template the questions arise:

• Can you have frontmatter in the template file that pertains to the template file itself and not what the template produces?
• Can you have frontmatter in the template file that pertains to what the template produces (the note that comes from it) and NOT to the template file itself?
• And, can you have both?

Why? How?

[AlanG]

Absolutely to both!

At the end of your template you can remove template frontmatter fields from the created note like this:

<%* 
// Add this at the end of your template file

// Remove some template 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) => {
    // and delete the properties you don't want
    delete frontmatter['Some frontmatter field']
  })
}, 300)
%>

For a much more advanced example, see the Templater script on this page: New Note template

[holroy]

@AlanG

Absolutely to both!

Here’s an example of my new note template which has metadata regarding to how I want the template to function, which won’t be present in the final note:

Do I understand your post correctly though that the only reason the frontmatter don’t appear in the final note, is because you’ve removed it at the end of your template?

In other words, if you include a frontmatter in your template, it can of course be accessed as normal frontmatter in other contexts, but when applied in a template it’s still included in the final note, unless you remove it somehow.

I think the OP kind of wants frontmatter that only is valid/present in the template, not the final note, without the hassle of removing it theirselves. And that scenario, I’ve not seen (other than some variant like AlanG describes).

[AlanG]

@holroy

you include a frontmatter in your template, it can of course be accessed as normal frontmatter in other contexts, but when applied in a template it’s still included in the final note, unless you remove it somehow.

Correct, I don’t think Templater has any built-in way to do it, you have to remove those properties yourself as part of your template.

[AlanG]

@holroy I updated my original post with a much simpler example which you can copy/paste into any template.

[Blahboybaz]

So it sounds like the default is that frontmatter in a template ends up in both the tamplate and the note created by it. In order to eliminate frontmatter from the note that comes from the template you have to use code in the template to intentionally remove it. This leads to 2 possible states…

1. You have frontmatter in both the note and the template that made it (presumably the same frontmatter)

   or…

2. You have frontmatter in just the template but not in the note

But the cases that could be applied to the question are a lot more nuanced than that. It is noteworthy that there may be a reason to want different frontmatter in each of the template and the note that comes from it. Conceptually this would look more like a situation where the frontmatter in the template applies only to the template by default and any frontmatter desired in the note that comes from it must be intentionally put there using code in the template. That’s a very different scenario than the one being described so far. The idea is this - templates are things that (arguably) should have frontmatter (frontmatter that pertains to the template and nothing else) AND the notes that come from templates are things that (arguably) should have frontmatter (frontmatter that pertains to the note and nothing else). This suggests that some or all of the frontmatter in each of the template and the note might be unique to that thing. Frontmatter is a good thing - notes need it, templates need - everything needs it!

[Blahboybaz]

@AlanG

app.fileManager.processFrontMatter(newFile, (frontmatter) => {
    // and delete the properties you don't want
    delete frontmatter['Some frontmatter field']
  })

I’m not super familiar with Templater code (since I’m new to it) but I am familiar with coding in other contexts. I thought Templater code always begins with tp and that snippet does not have that. Is this code block related to some Obsidian API or something?

[stef.rausch]

Correct you are. Look at the Obsidian Developer Documentation for more in-depth information.

[holroy]

@Blahboybaz

So it sounds like the default is that frontmatter in a template ends up in both the tamplate and the note created by it. In order to eliminate frontmatter from the note that comes from the template you have to use code in the template to intentionally remove it.

Yes, this is true. However, using the code above it’s not that hard to fully replace the frontmatter from (and for) the template to something dedicated for the note. Maybe it could/should be easier for these to be separated.

Then again in my use case, I’ve not needed to have dedicated frontmatter for both cases, and I’m using the template folder instead of something is pertinent to the template (and for exclusion of the template folders in normal queries).

But one could conjure up various schemes which could automate switching frontmatter, from the template case to the note case. Like triggering a function which when the template runs replaces all of the current frontmatter, with a custom note frontmatter object.

So the options are there, just not a current implementation which out of the box supports one separate frontmatter for the template and one for the ending note.