1.4.7

Fixes for an unreadable data.json. Obsidian never throws when a plugin's own data file cannot be read or parsed — it hands back an empty-looking value — so this plugin had been treating "could not read it" as "nothing was ever stored here". Two things could follow from that: an order note whose json block had gone missing could get a fresh empty one written over it, and a settings save could replace a data.json it had failed to read, resetting every setting and dropping the backup copy of your orders.

Now it refuses to write over a file it could not read, and says so. Settings fall back to their defaults with a row in the settings tab explaining that they are defaults and will not be saved, and it recovers on its own once the file is readable again — repair or delete it and the plugin picks it up, or press Read it again. Settings changes are also verified after writing, so a full disk or a read-only folder no longer leaves a toggle that silently disagrees with the file.

Saved orders were never at risk in any of this: they live in the order note, not in data.json.

1.4.6

Fixes several ways a saved order could go missing with no error and nothing to point at.

• An order made moments before quitting Obsidian is now saved instead of lost. Quitting is not a plugin unload, so the previous save-on-exit never ran on that path.
• A write that fails now says so, instead of leaving the order reported as saved and gone at the next restart.
• The move commands no longer act on the note open in the editor when the file explorer has focus but no row does.
• While the tree auto-scrolls during a drag, the insertion line now follows the pointer, so the drop lands where the line says it will.
• Renaming the order note moves the setting with it instead of recreating a duplicate at the old path; deleting it now says what will happen.
• Closing and reopening the file explorer no longer leaves drag listeners behind.

1.4.5

1.4.5

1.4.4

This release is about one thing: what happens when the order note cannot be read, and making sure that never costs you the orders it holds. Ordering itself is unchanged.

• New: start over. When the note is unreadable and nothing can be recovered from it, settings now offers to rebuild it empty. The unreadable note is kept as a copy first, so this costs the saved orders and none of the bytes.
• Saved orders no longer go missing silently. Several cases where a bad hand edit, a sync conflict, or a move made while the note was broken could quietly replace your orders are fixed. Repair now works from the note as it actually is at that moment, and refuses rather than guessing.
• Repair says what it did. It names every copy it kept, and the row that deletes those copies is now available while the note is still unreadable — the state that creates them.

1.4.3

The plugin no longer reads a list of every file in your vault.

Two settings rows stopped enumerating the vault

Both are rows you only ever see when there is something to clean up: "Delete the kept copies of unreadable order notes" and "Remove orders for missing folders". Each of them used to answer its question by listing the entire vault and then discarding almost all of it.

A kept copy of the order note is always written next to the order note itself, so only that one folder is read now. And a saved order is stored under its folder's path, so asking whether that folder still exists is a single lookup per saved order — no part of the answer grows with the size of your vault.

None of this is visible on screen. The same rows appear at the same moments and do the same thing. What changes is that the plugin no longer needs, or takes, a list of everything you have.

Also in this release

• "Remove orders for missing folders" worked out which folders still existed before showing you the confirmation, then acted on that answer afterwards, so a folder deleted while the confirmation was open would have been missed. It now checks at the moment it writes.

1.4.2

Appearance fixes in the reorder dialog.

The "open this folder" button no longer looks like a broken border

It sat behind a hairline rule meant to separate it from the move-up and move-down buttons, and in light mode that rule read as one edge of a box whose other three sides had failed to render. The rule is gone. The real problem was that all three buttons were the same shape — two chevron pairs and a lone chevron pointing a third way — so a line was doing work the icons should have been doing themselves. The button is now a chevron inside a circle, distinct at a glance, and it nudges toward the folder it opens when you hover or focus it.

That motion is dropped if your system asks for reduced motion.

Also in this release

• The subfolder walkthrough in the README has been re-recorded. The old one predated 1.4 and showed a control this release has changed, on the one image the README points at for exactly that control.
• Two stylesheet rules that had outlived the features they styled have been removed. They changed nothing on screen; they were just shipping.

1.4.1

Polish for 1.4.0's Sort by.

Sorted by a date? Now you can see the dates

Each row shows the date it was sorted on, so a date sort can be checked rather than taken on faith — until now it arranged your files by a number nothing on screen would show you. The values line up as a column, and hovering one gives the full date and time that the short form leaves out.

Sort by name and the dates go away again: there, the names you are already reading are the sort key.

When a filename is long enough that it and its date cannot share a line, the date moves to its own line rather than costing the name its characters. Folders show no date at all — Obsidian records none for them, which is also why they always sort first.

The dialog got its vertical space back

Sort by has moved out of the strip it had above the list and onto the right-hand end of the path line, which was sitting half empty directly above it. That strip cost around 33px of the dialog's scarcest dimension to hold one button; the path line is already as tall as the button, so the control now costs no vertical space at all.

Part of that was self-inflicted in 1.4.0. Keeping Save and Cancel on screen meant making the dialog's content a flex column, which quietly stopped two adjacent margins from merging the way they had — so the gap under the path doubled. It is back to what it was.

1.4.0

Sort a folder by name or date

Obsidian's sort setting applies to the whole vault, so "keep this one folder newest first and leave everything else alphabetical" was not something you could ask for. Now you can: the reorder dialog has a Sort by button offering name, creation date and modification date, each in both directions.

It is also the fastest way to start ordering a large folder. Sort by modified date, move the two things you care about to the top, save — instead of dragging a hundred rows into place.

Picking a sort rearranges the dialog and nothing else. Nothing is written until you press Save, and Cancel leaves the folder exactly as it was — which matters, because sorting replaces an order you may have arranged by hand.

What gets saved is that arrangement, not a rule that keeps re-applying. A file added later joins the end of the folder, the same as any other item the order does not mention.

Folders always come first, whichever sort you pick: Obsidian records no dates for folders at all.

Fixes

• Save and Cancel could be pushed off the bottom of the dialog in a folder with many items, or in a short window. The list now gives up its own height instead, so the buttons stay put.
• Dragging over the file explorer felt sluggish, worst over a collapsed folder. dragover fires per mouse message — measured at 392 times a second on a high-polling-rate mouse — and the plugin was writing to the DOM on every one of them, in between layout reads. It now does that work once per boundary crossed rather than once per event.
• The settings rows that perform an action (repair, clear, delete) now have their own buttons, rather than the whole row being clickable.
• Two files whose names differ only by Unicode normalization could be ordered differently on different devices, because the comparison treated them as equal. They now have a stable, deterministic order everywhere.

1.3.1

Three fixes, all of them things that broke without looking broken.

Dragging in the tree stopped working after the file explorer was rebuilt

Moving the file explorer to the other sidebar, or closing and reopening it, left drag-to-reorder dead until the plugin was reloaded. The listeners were attached once to that view's element, and a rebuilt file explorer has a new one.

Saved orders kept rendering correctly the whole time, because that part is installed differently, so there was nothing to suggest the drag had come loose — checking that the tree looked right could never have found it.

An order could be written to a note the vault had not indexed yet

The companion to the startup bug fixed in 1.3.0, on the writing side. In the same startup window, a write would try to create a note that already existed. Obsidian checks the filesystem before creating and refuses, so the note was never in danger — but the write was lost while the in-memory order still showed the change, so nothing looked wrong until the next restart. It now waits for the vault to catch up.

A missing json block was not always recognised as damage

When the order note is changed from outside — another device syncing, a hand edit — a missing json block is only benign if nothing was ever stored there. That test consulted what was in memory but not the backup in data.json, so it could miss the case where memory was legitimately empty: a vault that had saved no order yet, or one just after "Clear every saved order". It now checks both, exactly as loading does.

1.3.0

Fixed: saved orders were ignored after restarting Obsidian

This affected every cold start since 1.0, and updating is worth doing now. If your orders applied while you set them but were back to the default sort the next time you opened Obsidian, this was why.

The plugin asked Obsidian for the order note during startup, at a point where Obsidian's file index has not been built yet. The answer — "no such file" — is correct at that moment and wrong a moment later, but it was read as "no orders have ever been saved", which left the plugin holding an empty index that reported itself perfectly healthy. Nothing rendered, no repair was offered, and nothing appeared in the console. The note itself was never touched, so the one place you would look for damage looked fine.

It now checks that answer against the vault's filesystem adapter, which needs no index, before concluding the note is absent.

One thing worth checking. While the plugin was holding an empty index, saving or dragging would have written that emptiness over the note. If you reordered something after a restart on 1.2.1 or earlier, open explorer-order.md and confirm it still lists every folder you had ordered. If it lists only one, earlier content may be recoverable from indexBackup in .obsidian/plugins/explorer-order-editor/data.json, from your vault's .trash, or from sync/version history.

Thanks to @jon0101010 for the report in #1, and for the detail that made it findable: that the order applied correctly when set, vanished on restart, and offered no repair row.

The right-click menu is now one entry

Everything this plugin adds sits under a single Explorer order item, with Set order and Clear order inside it — and the four move actions too, when you have them switched on. Since 1.2 most reordering happens by dragging in the tree, so the menu you open for something else should not be carrying six of our entries.

Move hotkeys can move folders

The four move commands act on the file explorer's focused row while the explorer has keyboard focus, and on the note you have open otherwise. Previously they only ever acted on the open note, which meant no hotkey could move a folder at all, since the open note never is one.

Clear every saved order

A new row on the settings tab clears all saved orders at once, after a confirmation naming how many folders are affected. It appears only when there is something to clear. Undoing an ordering pass over a whole tree no longer means revisiting every folder in it. Your files and folders are not touched.