alangrainger / obsidian-frontmatter-modified-date Goto Github PK

I would like to be able to exclude a single file, for instance by adding a property in the YAML.

So far a workaround is to enclose all the files I do not want to update inside a specific folder ("No_update" for instance), however the option could be very useful.

I'm getting the "Merging Changes" pop-up frequently when using Obsidian Sync, and rather than being just an annoyance, it is actually erasing recent changes (e.g., I'll type out a sentence and then see half of it disappear when the sync conflict occurs).

Steps to reproduce: Obsidian running on a desktop (Windows 11) and mobile (Android 13) with Obsidian Sync. Edit a note on desktop. Stop making changes, but leave it in edit mode. Switch to mobile. Open the same note and start typing -- frequent "Merging Changes" pop-ups occur and text is often erased shortly after it is typed.

After some experimentation, I think this is because I had sync turned on for "Installed Community Plugins" and "Active Community Plugin List". Thus, this plugin was installed and enabled on both desktop and mobile, which is probably not an optimal setup...? I suspect the edits were being synced appropriately, but then the mobile and desktop instances of the plugin were racing to update the modified date.

If that is what's going on, I guess it's not really a bug, but I would suggest emphasizing in the documentation somewhere to NOT enable the plugin on multiple devices, as it was a bit of a headache for awhile.

I would be nice to have the option to specify UTC.

After I got familiar with your extension, I found myself wanting to keep both a log of my edit history and my last modification date for all new notes. Currently, the extension can either store the edit history or the last modification date but not both. In order to store both we would need to modify both the functionality of the extension and the extension settings.

We could have a toggle in settings that enables an edit history on all new notes. Additionally, we should also have a setting where we specify the edit history property name to keep it consistent with the last modification date property. Then, the extension functionality would need to be updated to respect the new toggle and to save edit history to the separate edit history property.

Since I wanted this functionality, I went ahead and implemented it in my own fork of the repo. After I implemented it, I noticed that this fixes issue #14. I also noticed that there is another fix in PR #19 by @smallstepman that has some of the same functionality. Feel free to compare them.

I also took the liberty of adding a UI for a couple of settings that were accessible in data.json but not through the settings GUI.

I would appreciate if @alangrainger could review and possibly merge the PR I will be creating soon in for these changes.

"Only update existing fields" option doesn't work if the property/key doesn't have a value.

With the option enabled, the following will not have the timestamp added after an edit:

modified: 

But this will:

modified: test

Expected: When enabled, only update files with modified:(or custom) present, regardless if it has a value or not.

Thanks.

If you try to expand the input box for "exclude folders" in the settings page (so that you can actually see what you are adding), you encounter very strange behavior:

An up/down mouse motion expands and contracts the control vertically as one might expect, however, since the grab bar is in the lower right corner, you get a mirrored expansion/contraction horizontally. In other words, if I want the box to expand to the left, I need to move my mouse to the right. Moving right makes the left edge travel further to the left while the right edge stays basically in place, and vice-versa. This is not intuitive.

To make matters even worse: The size and position of the control does not remain when visiting the settings page a second time, so the user has to take this non-intuitive action every time they want to see their whole list.

Since we seem to have no ability to move the grab bar to the lower left corner (according to my research on TextArea), might I suggest the following:

Put the text on top of the box (rather than to its left), and make the box fill the entire width of the space below the description by default. This way the top, left and right sides of the box can appear locked in place, and the user would only be changing the bottom edge position. The description wouldn't need to change its shape at all, since it wouldn't be sharing any horizontal space with the input box. It would be on a separate line above the box. That might require making raw text for the description, and then having an unlabeled TextArea beneath it.

Thanks for reading this feature request, and happy coding!

For some reason when obsidian-frontmatter-modified-date plugin updates the modified date of a note it removes the " " enclosing a URL in the image property. For Obsidian Publish users this breaks the image property which is required to specify a social media preview image.

The other popular plugin that does this (https://github.com/beaussan/update-time-on-edit-obsidian) has the exact same issue but for some reason the linter plugin does not.

Before:

---
alias: [Academic research dashboard]
created: 2022-08-20
modified: 2024-01-21
---

After:

---
alias:
  - Academic research dashboard
created: 2022-08-20
modified: 2024-05-12
---

What I want:

---
alias: [Academic research dashboard]
created: 2022-08-20
modified: 2024-05-12
---

I want all elements of a list on the same line. I didn't find anything in the code that would change lists explicitly, so maybe this is just what Obsidian's processFrontMatter is doing? Is there a way to avoid this?

I've thought about fixing this with the Linter plugin. But if Linter lints on file close and then this plugin updates a list to be multiline in 10s, the file is saved with the undesirable formatting still.

          > You're talking about this message:

This is to be expected, and is due to the way Obsidian itself handles the frontmatter update. If you are typing into a note at the same time that Obsidian updates the frontmatter field, it will show that message. There is no "external" process modifying the file, it is Obsidian itself.

My plugin works by waiting for 10 seconds after you stop typing before updating the frontmatter. By doing it this way it reduces the chance of that message popping up. However, if you start typing again the exact instant Obsidian is updating the frontmatter field, you'll see that message. It won't affect anything, it's just annoying. Hopefully they resolve this at some point.

Please note that you do not need to have the file open for the frontmatter to update. The updates go into a queue and the file will update even after you close it.

I think there may be a bug with this still. You said the plugin waits for ten seconds after you stop typing before updating it. I regularly find I pause to think for a few seconds and carry on typing to look up and see that this message has popped up and the middle of a couple of words is missing.

Originally posted by @creativefibro in #3 (comment)

I have a folder named "Test" with a note inside of it. "Test" is also written in the "Exclude folders" option. Yet after 10 seconds, in this case, the front matter of the note is being deleted (probably because it contains Templater syntax and therefore not valid front matter).

• Why is the "Test" folder still being manipulated despite the exclusion? I've tried excluding "Test/" and "/Test" without luck. Also tried a differently named folder.
• If the folder isn't excluded, the front matter shouldn't be being removed because this plugin believes it's invalid.
• I have the "Only update existing fields" option enabled, so I would've thought even without an exclusion this plugin wouldn't cause any modification/deletion due to the front matter being Templater syntax. Edit: This seem to work fine on non-excluded files with valid front matter.
• I am also using a custom front matter property key name.

Thanks.

If I add a template to a note, that includes the modified date property. And the I decide I don't need properties in that note and decide to remove them all (by going into source mode and selecting and deleting everything). Or if I simply remove the modified date property by right clicking and removing, the property will reappear.

Thanks.

I added the field a gave it the value true (actually a checkbox) but the field specified in the options (modifiedDateTime) is still updating.
My fields:

exclude_modified_update: true
modifiedDateTime: 2023-09-14 16:26

I also tried to close Obsidian and reopen but this still happens.

Hi, I keep getting a message about external process modifying my file. Merging. (Not the exact words but I haven't been able to take a screenshot of the message).
This keeps happening even after selecting Use typing events and restarting obsidian.
Do you know if this is expected behavior? Thanks.

Hello @alangrainger, this plugin is exactly what I was looking for, thank you for making it! One thing though, I intend to always append the modified dates into a list in the front matter for all my files and therefore do not particularly want to have to add the "append_modified_update" checkbox to each of my files. Is it possible to get a global setting to enable this, which could be added as an OR argument into the if statement? Thanks for your time, Lawrence.

Hey thanks for this plugin!

I wanted to see if it would be possible to add link support for dates. I prefer to have the date linked for create/update stamps instead of just flat text.

I found that if I gave the following moment.js format it created the shape I wanted:

[[[]YYYY-MM-DD[]]]

But unfortunately is considered an invalid date and so when doing a comparison, it just always appends every 10 seconds as line 147 always returns false:

now.isSame(previousEntryMoment, this.settings.appendMaximumFrequency)

The only way I could think to implement would be have a toggle for dates-as-links or something which would just concat onto the entries, and peel them off when having to re-parse.

Let me know if this is something you'd be open to adding, I may just do it myself locally.

I really appreciate having a reliable field for date modified that's separate from the file system - thank you.

Given that file systems can't maintain date created across various operating systems and syncs, I would LOVE to see an internal "created" field included here as well.

• Restart Obsidian
• Modify a file
• Wait until the modified time changes
• Wait until the next modified debounce expires
• Notice that the modified time updates again
• This repeats forever. (Until Obsidian is restarted)

It seems the way the files are being listened to for changes (this.app.vault.on("modify", (file) => {..etc})) is being triggered by both manual edits AND then the actual change to the frontmatter the plugin does, entering an infinite loop.

I fixed it locally with the following changes:

Track files in a grace period

constructor() {
    super(...arguments);
    this.timer = {};
    this.gracePeriod = {};
  }

Wrapping the entire body of the vault.on("modify") call with:

if(!this.gracePeriod[file.path]) {
    // original code
} else {
    this.gracePeriod[file.path] = false;
}

And changing the timeout function to do:

this.gracePeriod[file.path] = true;
// Existing code

It's not perfect as technically someone editing at just the right time would trip it up. But it's working for me so far.

I'm using the plugin to update a property called last updated with the date format DD/MM/YYYY. This is what I've input in the settings:

Today is November 13th 2023, thus I would expect the last updated property to show 13/11/2023, but this is what is shown instead after an edit of the file:

I've not tested a ton of other date formats, but for example inverting the day and month (thus using MM/DD/YYYY) does seem to work, as well as omitting either the day or month. It seems that specifically the format DD/MM/YYYY breaks.

Note that the Obsidian property is of date type.

I've also tried using the format L (for my locale date) and it works, but it is treated like a string by Obsidian and throws a warning because the property is of type date.

EDIT:
I'm using Obsidian v1.4.16 on Windows, with the plugin version being v1.3.2.

Hi, I like you plugin a lot. It's really useful. there is just one problem. If the plugin is enabled, every time I update a note, the modified date gets automatically added to the frontmatter. And sometimes I don't want frontmatter in certain notes or I simply don't want to know the modified date for a specific note.

Solution: Add an option to only add the modified property if the modified value is already present in the frontmatter, that way we avoid the property being added automatically to the frontmatter.

Thanks.

This is exactly the plugin I was looking for; relying on the operating system for retrieving modified date metadata is flawed. Unfortunately, your plugin also seems to have some limitation, namely the rate at which it detects and updates the modified key.

There's probably a good reason behind not checking for a change every second and rewriting the key's value, but it's possible to edit a file and switch away or close Obsidian before the plugin updates the modified date (according to the developer of the obsidian-linter plugin, the latter doesn't have a good solution). This isn't so much of a problem of files you edited a moment ago, leading to inaccurate modified dates from seconds to minutes (which still irks me), but what if the file is one edited yesterday, or a week ago?

I saw in your commits you switched from modify to an editor-change event to avoid issues with Obsidian Sync (5d8abe3). Was the former more accurate at detecting and updating the modified date? If there's no other solution to improving the accuracy, maybe a way to opt-out of being Sync-compatible for more accurate modified dates? I see Obsidian saves the file / updates the modified date on the system within 2-3 seconds of any edit.

Thanks.