Ghost: “Delete all content” doesn’t delete images

[chris-morgan]

Issue Summary

The “Delete all content” button deletes all pages and tags, but not images in /content/images.
This leaves you no way to remove old files, which can be a disaster when importing content from another system or if they may have had sensitive information, and is very wasteful of space.

Steps to Reproduce

1. Create content with images. Maybe by importing, maybe manually; I don’t care.
2. Observe the paths to any images.
3. Use that shiny “Delete all content” button.
4. Observe that the image files are still there. And in consequence, the content at their URLs are set in concrete, because if you try to add an image with the same URL it’ll get -2 (then -3, -4, &c.) appended to its basename.

This is particularly bad when writing a script to export from another system—you often end up doing multiple imports, so you can rapidly end up with many copies of each file, and if anything was wrong with the contents of the file the first time you created it, tough luck, old chum, you can’t do anything about it unless you have access to the underlying filesystem where you can delete it yourself.

Technical details:

• Ghost Version: 1.20.3
• Node Version: n/a
• Browser/OS: n/a
• Database: n/a

[chris-morgan]

I observe that at the time when delete all content was implemented, four years ago (#1445), media files weren’t imported, but the orphan images issue was known (and not considered urgent because media files weren’t imported). The situation has clearly changed since then, and I think it’s well and truly time for media files to be deleted when deleting all content.

[kevinansfield]

media files weren’t imported, but the orphan images issue was known (and not considered urgent because media files weren’t imported). The situation has clearly changed since then...

Nothing has changed here, media files are not imported through any mechanism provided by Ghost, the only way to get an image into the content directory through Ghost is to use the private API to upload images one at a time. As such media management is still a manual process, if you are running multiple imports and copying directories of files across then it's up to you to work out how to manage that. Ghost doesn't have enough information about which files are used where to make any sensible decision about which files should be kept/deleted/renamed etc.

[kevinansfield]

Sorry, it looks like I was mistaken and images will be imported with a correctly formatted zip file.

In general the orphaned media files issue is still a known issue when deleting individual posts but there's not a huge amount that can be done about it until we have a full media library and/or we store more information about which media files are referenced within Ghost. "Delete all content" is clearly a different situation.

[kirrg001]

Thanks for your time!

We only keep Github issues open for bugs and in-progress feature work. I'll add the idea to our internal ideas board. As soon as the feature get's requested often enough, we discuss and schedule the feature for an upcoming sprint.

For now, you have to remove the affected images manually yourself. If you are hosten on Pro, you can contact the support :)

[chris-morgan]

My firm opinion on this is that it is a bug.

[kirrg001]

The admin panel says:

Permanently delete all posts and tags from the database, a hard reset

[chris-morgan]

The admin panel also says (emphasis mine):

Delete all content

and

a hard reset

Media files are emphatically content. That such content is still accessible after a hard reset is a bug. To extrapolate a plausible situation, some sensitive information is posted, with a sensitive image following a consistent naming scheme attached. A hard reset is performed to purge all sensitive content—or so the admin thinks. In fact, it’s still there, and discovered later (or perhaps it was indexed by a third party earlier) to the harm of the publisher of the content.

This isn’t an implementation bug—it does what the programmer intended. But it is a design bug—what the programmer intended is wrong—and one that’s seriously annoying for certain patterns of usage, and subtly dangerous for certain other patterns of usage.

[kirrg001]

I'm looping @peterzimon in.