The plural is standard to indicate that the data type is a list (array), even if there is only one value.
Here’s a Python script for bulk updating your metadata which I haven’t tried but looks good. GitHub - natelandau/obsidian-metadata: Batch updates to metadata in an Obsidian vault
People who don’t know Python:
Go into your text editor program (VSCode or Notepad++; Sublime Text I don’t recommend here if you have many thousands of notes with [prospective] properties), tick the regex function, may want to filter for *.md and run on your full vault/folder:
Match: ^alias:$
Replace: aliases:
^ and $ we make absolutely sure we only make changes to what’s needed.Because your Templates are also located in your vault, this will update your templates as well. I just went through my templates first and double-checked if every key or property is correct. So my regex changes did not update my Template files, I had done those manually.
When you restart Obsidian, the program will start reindexing your vault.
To edit the Linter plugin’s YAML section is rather easy.
Also: you can run a similar search and replace for cssclass: > cssclasses: as well, but I only changed those I had assigned in my frontmatter myself, not those that were inserted or are possibly still maintainted by an external plugin or js source.
In case anybody was wondering – the Various Complements plugin’s handling of internal links with these alias changes ostensibly won’t change as the plugin should be using Obsidian’s internal index/cache.
Brother, your Notepad++ workflow saved me a ton of work. Thank you.
I must say, I really dislike the new name convention for “cssclasses”, “aliases” or “tags” but i bet this was just an example and plurals will become the standard for more properties, sooner or later
This new naming sounds not just more complicated but is, visual speaking, more clutter to write and more clutter to read for users.
Also, adding an es or s might sound like a little, innocent change but messes with the old way to deal with properties and requires more typing as well.
My guess is, this name consolidation must be more a technicality, other reasons aren’t very much reasonable, imo.
Hopefully I don’t need to rename all my old notes to keep my tags, aliases and cssclass properties in the future .
No matter if a property contains one value or an array of values, properties are just a very quick description to identify very quickly values,
Properties have nothing to do with the values itself, they aren’t meant to be a nice, formally correct thing to read like a book text, therefore plurals should be avoided in code projects at all cost, imo.
@Jopp I mostly agree, but as @biscotty hinted as well, these syntactic changes are down to how Obsidian YAML formatting itself was changed to favour multi-line values.
alias is now deprecated (?!!), I don’t see how a developer who needs to insure base backward compatibility could not account for both alias and aliases in the code. The only motive I’d see for enforcement was monetization but neither Properties nor core Obsidian is a paid feature/app.I would really like(?) someone to come out and say for confirmation “Yes, you can use any xyz frontmatter key you set yourself but we only support aliases to work for frontmatter key/properties and internal link management.”
How it works is:
This had been discussed a lot and the team has explained their reasons (mainly in the insider-desktop channel on Discord) but I’m having a hard time finding those posts now. There’s a brief partial explanation at Properties: Do not strip hashtags in tags - #16 by WhiteNoise, and the user post right after that goes into some detail, but I know I’ve seen other posts about different aspects of it.
Aha! Here’s a post from Obsidian cofounder Licat:
I can see the value of these changes, and reckon I will come to appreciate & enjoy them; but currently the aliases v alias issue is doing a real wrecking on my dataview tables.
I’ve got use cases where it’s helpful to list all the aliases, but I stupidly used singular instead of plural in my templates.
My understanding is that the underlying API rewrites (and has for some time) the YAML whether source mode is selected or not. Think the toggle removes properties from the editor but not what it is doing in the background.
Have I misunderstood this post by WhiteNoise? There is only one API handling the YAML, yes? So that API rewrites the YAML in all circumstances, because even if properties is off in the editor, it is still on in the app itself?
Thanks
Whitenoise says, “you indirectly interact with that API (and the underling parsing library) every time you use the properties UI”. I believe if you use the source view setting then you aren’t interacting with the properties UI and so won’t experience rewriting. Perhaps I’ve misunderstood (I only use properties for an occasional alias), but, it’s easy to test.
Around v1.4.3, I did a small and hardly scientific test, but I think it was sound, watching for file changes. As long as I didn’t touch the Properties view UI in the note or the sidebar, no YAML was changed by Obsidian.
I think what they were saying is that Obsidian (and plugins) has had the ability to do it for some time, but Obsidian hasn’t itself until now (out of necessity to get Properties view to work). That’s how I read it.
Thanks for the replies. Would be nice if the team made it crystal clear.
Was just skimming through info here so I may not have the relevant input (as usual 
):
In an another thread I already pointed out that in my v1.3.5 Obsidian, the Linked Data Vocabularies and Link with Alias plugins were already making changes to my YAML format: it was not about the alias key being changed to aliases but alias values turned to multiline versions, which is why I made vault-wide changes to my YAML (and felt my installs even a little bit lighter and faster for some reason) and set different settings in my Linter afterwards. So under the hood it was Obsidian making these changes, before Properties for Insiders came out.
So I start with a file created in TextEdit with the following YAML:
---
alias: [the cat, sat on, the mat]
tag: kitty, kat
cssclass: mewot
---
I put the file in a folder and open the folder in Obsidian as a new vault.
I open the file properties pane in the sidebar, and alias is shown as aliases with three different aliases. If I remove the commas in the alias, it is shown as a single alias.
tag is changed to tags and cssclass is changed to cssclasses.
In source mode, the YAML header in the note shows the original text.
In preview and reading modes, the YAML header in the note shows the rewritten properties.
When I display all properties in the sidebar, I see alias (1) and aliases (0); cssclass (1) and cssclasses (0); and tag (1) and tags (0).
So properties changes how a YAML header is displayed but doesn’t rewrite the underlying text?
And now try editing the YAML in Obsidian, first in source mode and then in live preview:
If you do it in source mode, all formatting stays, but if you do it in live preview, the formatting changes (forever: unless you CONTRL+Z out of it and make changes in source mode, then one can go back).
Interesting. I am interested to know if this is intended. I think it could be worth leaving it like this as a “feature”.
Ah, yes. As soon as I edit in live preview (in the middle pane in my screenshot), the YAML is rewritten and I can see the changes in the source pane (in the top of the screenshot).
Not entirely transparent. Would all the files in a vault be rewritten if only one file is edited in live preview, or just the file being worked on? (Guess I can test that.) Wish this was clear in the documentation rather than leaving it to users to figure out.
I think you need to go inside the properties.
But I wonder what Linter or plugins that update date modified would do to change it. Probably you need to go inside to have the YAML be rewritten.
My head → 
and 
My head when trying to figure out where other people’s GIFs start and end: and .
:)))
*Then Gino finds pause button and plays with it and not watch USA get beaten by Germany.*
In the hope that this is a little clearer:
