In the new update, “We have officially removed support for the properties tag, alias, cssclass in favor of tags, aliases and cssclasses. In addition, the values of these properties must be a list. If the current value is a text property, it will no longer be recognized by Obsidian.”
Proposed solution
Please reconsider this. This breaks Obsidian for users who have been using it for years. I can understand new features such as Bases not having support for the old classes, but for “alias” to suddenly stop working will make the new versions of Obsidian unusable for some users. I am also open to changing my properties going forward, but the file modified date is important to me and I don’t want to modify my files in batch.
I understand why you don’t want to change them altering the modified date/time of files, but alias, etc., have been depreciated for a long time now and noted in the help docs:
Very fair - it’s just that opening files by alias is such a core feature, I still haven’t switched over completely. Completely understand new features not supporting but it would be nice if these extremely basic ones were left intact. I have 11,000 notes and over 4,000 were made in Obsidian before July 26, 2023.
I’ll just chime in. If you ever do find you need to batch edit your files, in unix and Mac there is the touch command which can edit the modified date. And in Windows, I think you can find a similar tool. You could store the current value as a date property, make your changes, and use the value to put the date back as it was.
(And I agree with your post, even though I don’t use those properties very much.)
I do understand your frustration, Rachel. But I would like to point you to a solution : in an editor like BBEdit — I think even in the free version —, it’s quite easy to make a batch find/replace across a whole directory (including subdirectories) of files. So you can
look for all the lines beginning with alias:
replace alias: with aliases:
and voilà, c’est fait !
Then go through your Dataview queries and do the same replacements. Unless you have more than, say, 50 queries, it won’t take a long time.
Coming at it from the support side of things (where I see when things go wrong or behave unexpectedly all too often), if you’re open to it, I would advocate for switching from relying on file mtime to a frontmatter-based modified time instead. The Linter community plugin can help with this, and even batch all those older files for you (make backups!).
The reason is that different operating systems, tools, and syncing services all handle modified times differently. It’s very likely that your current device and OS won’t be the final place you work with these files. By keeping the modified time in frontmatter, it’s stored with the content itself, versioned, and stays consistent no matter where or how the file is opened or synced.
