abdab7a0a8
Rework the upload process so that files are saved to Danbooru first before the user starts tagging the upload. The main user-visible change is that you have to select the file first before you can start tagging it. Saving the file first lets us fix a number of problems: * We can check for dupes before the user tags the upload. * We can perform dupe checks and show preview images for users not using the bookmarklet. * We can show preview images without having to proxy images through Danbooru. * We can show previews of videos and ugoira files. * We can reliably show the filesize and resolution of the image. * We can let the user save files to upload later. * We can get rid of a lot of spaghetti code related to preprocessing uploads. This was the cause of most weird "md5 confirmation doesn't match md5" errors. (Not all of these are implemented yet.) Internally, uploading is now a two-step process: first we create an upload object, then we create a post from the upload. This is how it works: * The user goes to /uploads/new and chooses a file or pastes an URL into the file upload component. * The file upload component calls `POST /uploads` to create an upload. * `POST /uploads` immediately returns a new upload object in the `pending` state. * Danbooru starts processing the upload in a background job (downloading, resizing, and transferring the image to the image servers). * The file upload component polls `/uploads/$id.json`, checking the upload `status` until it returns `completed` or `error`. * When the upload status is `completed`, the user is redirected to /uploads/$id. * On the /uploads/$id page, the user can tag the upload and submit it. * The upload form calls `POST /posts` to create a new post from the upload. * The user is redirected to the new post. This is the data model: * An upload represents a set of files uploaded to Danbooru by a user. Uploaded files don't have to belong to a post. An upload has an uploader, a status (pending, processing, completed, or error), a source (unless uploading from a file), and a list of media assets (image or video files). * There is a has-and-belongs-to-many relationship between uploads and media assets. An upload can have many media assets, and a media asset can belong to multiple uploads. Uploads are joined to media assets through a upload_media_assets table. An upload could potentially have multiple media assets if it's a Pixiv or Twitter gallery. This is not yet implemented (at the moment all uploads have one media asset). A media asset can belong to multiple uploads if multiple people try to upload the same file, or if the same user tries to upload the same file more than once. New features: * On the upload page, you can press Ctrl+V to paste an URL and immediately upload it. * You can save files for upload later. Your saved files are at /uploads. Fixes: * Improved error messages when uploading invalid files, bad URLs, and when forgetting the rating.
22 lines
977 B
Ruby
22 lines
977 B
Ruby
# frozen_string_literal: true
|
|
|
|
# A component for uploading files to Danbooru. Used on the /uploads/new page.
|
|
class FileUploadComponent < ApplicationComponent
|
|
attr_reader :url, :referer_url, :drop_target, :max_file_size
|
|
|
|
# @param url [String] Optional. The URL to upload. If present, the URL field
|
|
# will be prefilled in the widget and the upload will be immediately triggered.
|
|
# @param referer_url [String] Optional. The referrer URL passed by the bookmarklet.
|
|
# @param drop_target [String] A CSS selector. The target for drag and drop
|
|
# events. If "body", then files can be dropped anywhere on the page, not
|
|
# just on the upload widget itself.
|
|
# @param max_file_size [Integer] The max size in bytes of an upload.
|
|
def initialize(url: nil, referer_url: nil, drop_target: nil, max_file_size: Danbooru.config.max_file_size)
|
|
@url = url
|
|
@referer_url = referer_url
|
|
@drop_target = drop_target
|
|
@max_file_size = max_file_size
|
|
super
|
|
end
|
|
end
|