Support image uploads to a default directory from the admin interface

[aprescott]

It would be great to be able to upload images from within the admin editing interface. Inspiration can probably be taken from the way GitHub issue attachments work.

The default upload directory can be something like /files/<year>/<month>/<name>, but configurable.

Thoughts:

1. Orphaned uploads if you use lots of images while drafting?
2. Having a separate view of, e.g., files/ to browse stuff outside of the editing interface?
3. If you draft on 2012/12 and publish on 2013/01, the file should probably end up in 2013/01 to keep it related to the post it's on. Temporary holding area for "unpublished" images?

[aprescott]

http://blog.alexmaccaw.com/svbtle-image-uploading

Svbtle is ahead of the game, obviously. :)

[aprescott]

I've been trying to think about different approaches to this, looking for something sensible.

One idea:

• For draft posts, place images in /images-tmp/<post-slug>/ first.
• On publish, move /images-tmp/<post-slug>/ to /images/<year>/<month>/, so that the draft can be long-lived, and somehow delete any files not mentioned in the post.
• For editing published posts, place the file directly in /images/<year>/<month>/, and again delete on save.

All images for a given post will then be in the same month folder, no matter when the image was added, so you can find a file quite easily if you know the post it's used in. This also makes finding orphans easier, I suppose?

That feels too complex, though. Especially with the move. An uploaded file's path should be independent of publish status. Plus, a file could be reused across many posts.

Simpler:

• Uploaded files go to /images/<year>/<month> where the year and month are of the current date and time.
• Deal with orphans through some other separate process.

This seems better, but then two images might be in separate month folders even if they're used on the same post, so the hierarchy is pointless, and would affect finding orphans.

No hierarchy, include the post slug in the name:

• Create uploads as /images/<slug>_<timestamp>.png.
• Deal with orphans separately.

This looks reasonable enough, although if post permalinks are /<year>/<month>/<day>/<slug> then it's possible that <slug> would be the same for two posts, which might be confusing.

Makes it harder to go hunting for images, but do we care? The file system would have timestamps, so probably not?

The slug might change, and if it's an initial draft then there is no slug. Maybe there could be user interaction?

User interaction:

• Files are saved at /images/<name>_<timestamp>.png.
• <name> defaults to the slug of the post (if there is one), but is ultimately set with user input taken before the file is sent to the server.
• Orphans are dealt with separately.

The name would get sanitised, but this makes it much less magical.

Or, the minimal approach:

• Files are saved in /images/<timestamp>.png.
• Orphans are dealt with separately.

This is basically how GitHub does it. I guess it's fine, although there is a total lack of some kind of user-friendly structure. Paranoia. 👻

Instead of a timestamp, it should be something suitably harder to guess.

[aprescott]

d0de2cb adds this functionality to all admin textareas. It adds the handler to document, but for some reason with body { width: 50%; } it'll only pick it up over the center column of text.

The file format is <unix_timestamp>.<original_extension>, with <original_extension> based on the client-side file.name value.

Some things I need to consider:

• Switching back to the markdown editor if you're on the preview panel.
• Dealing with inserting "\n\n" first, when you drop a file on it, unless you're on a blank line, just for a minor bit of usability.