Support for renaming entry files in collections

[mshick]

There are other ways to refer to this functionality — editable or customizable slugs being the most common — but the core of the feature is the ability to rename an existing file in a collection. There is a still open issue from 2017 on Decap CMS that gets into this sort of functionality and some of the attendant complexities, but to me the core of the issue boils down to this:

• For somebody working in a mixed environment — a CMS, but also, directly editing content in the repo — the file name is pretty important. This precludes giving filenames UUIDs, or similar.
• If you often create CMS content in a draft state, with titles or other fields that will inevitably change before publication, the fact that a filename is set on creation presents problems. It's pretty common for content creators to create initial / draft posts with nonsense titles like WIP-Post-About-A-Dog. Having wip-post-about-a-dog.md forever in your repo is not ideal.
• Filenames are brilliant as far as slugs go (for site urls, etc) in that they are guaranteed to be unique. For Markdown-based content workflows that work directly with the filesystem, you can derive site paths from filenames directly, with no need for an extra field that could get out of sync.
• The Decap issue rightfully points out that renaming has complex side effects and should be an explicit action, so that it can be handled if needed, e.g., by writing to a redirects file. The thread also suggests that how the rename is handled should not be a concern of the CMS, just that the CMS should be explicit when it does it.

The solution I propose would be as follows:

• Add a config field, either globally or at the collection level, rename_files: boolean.
• If this field is set, the path is generated and compared to the previous value on every save.
• If the path has changed, "rename" the file (for both GitHub's API and the Filesystem API, I believe this is a delete + create).
• Eventually, when CMS events are supported, a CMS event would presumably include the new and old path in some fashion in the event payload.
• Maybe at some point there would be feedback to the user that the change they are saving will result in a file rename.

I realize this is almost certainly a post-v1 concern.

[kyoshino]

Support for renaming entry slugs/files is of course planned as first pinged by @CarloBu in #140 (comment). I already have a WIP branch, but have realized that it needs to take Relation fields into account. Basically the CMS has to do the same as ON UPDATE CASCADE and ON DELETE CASCADE in SQL, otherwise broken references can break your site.

Sveltia CMS already has support for renaming asset files with referencing entries updated, and I’ll implement the same for references between entries. But things are more complicated — required Relation fields should not be deleted, for example. Here are relevant Netlify/Decap CMS issues:

• Dependency system for relation fields & editorial workflow. decaporg/decap-cms#192
• Relation widget: cascade deletes decaporg/decap-cms#717
• Relation widget does not change when referenced item is deleted decaporg/decap-cms#5750
• When title is updated on an entry, also update markdown files for related entries decaporg/decap-cms#6161
• Validation Widget Relation decaporg/decap-cms#6895

Decap CMS touts powerful Relation widgets, but it’s not powerful at all until these issues are solved. So my plan is to make Sveltia CMS more like a RDBMS, and it will be done before the 1.0 release (for marketing reasons) 🙂

[mshick]

That's great to hear.

Right, the relation fields are definitely a concern. I wonder if handling the side-effects / cascade could be reasonably driven by a CMS event? E.g., you internally listen for a preSave event, or a private precursor. Depending on the size of the project you might even want to spin it out into a web worker...

I'd also suggest that the relation field should probably be fault tolerant, assuming that the referenced key is a weak guarantee at best.

An interesting feature — if you open PRs before you get to this I'd certainly assist.