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:
With ^ 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.
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.
Although when I see in the Obsidian Help site that 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.”
In which case I’d say, “Why don’t you please support both?” – Which is no longer a semantic and syntactic question. It’s just the principle of the thing.
If you only use Source View to manage your properties, they will stay as you formatted them.
If you ever use Properties View to edit them, they will be reformatted.
I think if you view your properties in the new UI but don’t edit them, they won’t change, because I remember reading that deprecated forms of keys will still be recognized by Properties View for reading. But I might be mistaken.
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.
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?
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.
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.
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.