I need sort of a sparing partner...

R_J

I try to make the CKEditor a good alternative to the current editors. Why? That's not important.

Currently I focus on the upload process. There is the /api/v2/media endpoint which is quite handy. You just need to POST the file to that api endpoint and it gets saved and an entry is made in the media table. That's a great starting point. But there are two features missing:

1. The row in the Media table must show correctly ForeignID and ForeignType
2. There must be a thumbnail created (if applicable)

I've got the code for the thumbnail creation, but I'm unsure about the best process. Currently I tend to implement a process like that:

1. User (let's give him userID 7) drops picture flowers.jpg into editor
2. editor plugins JavaScript sends a POST request to /api/v2/media to reuse Vanillas upload endpoint
3. /api/v2/media a) saves flowers.jpg to /uploads/953/ZGHUJABS.jpg, b) creates row in GDN_Media, c) sends back Media information back to JavaScript (where Session->UserID is = ForeignID = InsertUserID and ForeignType = 'embed'
4. JavaScript saves MediaID to a hidden field in textarea#Form_Body
5. EditorPlugin hooks into AfterSave event and updates GDN_Media where MediaID in $formValues['MediaIDs'], UserID = session->UserID, ForeignID = session->UserID, ForeignType = embed with Discussion/Comment and the corresponding ID
6. Together with 5., also create a thumbnail file /uploads/953/thumbs/t_ZGHUJABS.jpg and update GDN_Media to keep the thumb information, too (I'll certainly do only one update call 5 & 6)

Does that sound reasonable and safe?

I thought about security problems when someone spoofes the hidden form field, but when the update checks for the InsertUserID, the ForeignID and -Type, I don't think there should be a problem. Current entries in the Media table can be changed and I will have to check if they will still work with the Rich Editor afterwards. But even if not: I wouldn't mind...

I had considered creating the thumbnail already during the main file upload (that's why I have implemented right now, but it certainly shouldn't stay like that) but if the post will be changed and the file will be deleted, than the rsources would be wasted. Also, if updating happens when the ForeignInformation is updated, there will be only one update call needed instead of two.

There are numerous ways uploading has been done in the past and nearly the same number of ways how thumbnail creation has been done in the past. Is there any reason to save the thumbs in another naming scheme? Which would be better and why?

Any feedback is welcome!

rbrahmson

I wonder whether thumbnailing is worth the effort for small images or small forums... Perhaps that could be a config option (css should still be used to display the image as a thumbnail).

As for syncing changes - they are probably less common and can endure the extra effort at save time which means that the method is not that important.

R_J

Creating thumbs as well as changing ForeignID and Type is not needed. There is no official use case for it. I'm aware of that.

A picture that has been uploaded with e.g. Comment#999 can be used in arbitrary other dicsussions and comments. So what is updating ForeignID and Type really good for? I don't know. But someone might want to make use of those existing fields and therefore I though I'll fill them.

It's the same for the thumbs. In my opinion, every plugin relying on thumbs must check if a thumb is available and if not create it. So should my editor really be responsible for creating thumbs? Don't know. But I can do it and therefore I plan to do it.

Are thumbs needed as such? If you want to use them, then yes. Loading 10 original files of several MB each in contrast to loading 10 files with 1 or 2 MB in sum is relevant.

Can I think of use cases? Yes for sure!

Thumbs: Load thumbs instead of original images in mobile themes

ForeignID: Mark discussions in discussion index which has images

Both: Create a panel widget showing a slide show of all images in current discussion

donshakespeare

Any feedback is welcome!

What is the official reason for Vanilla server-side (or any forum) to be aware of the various images present within the body/ content of discussions and comments? I would like to learn it.

I have always held it to be a superfluous burden on the script. I envision that the only images to be known intimately by the vanilla/plugins are ones with dedicated upload procedure, such as maybe a hero image, specific uploads etc. Any other random upload made by say, the RTE editor script, ought to be minimally acknowledged and regarded as mere HTML, with no other further record made any where in the DB.

For this reason, within the body of discussion and comments, I use elFinder integrated with with a custom RTE. A user uploads a non-special image, and it goes to whatever location I have prepared (common upload folder for all users, or private folder with even a username in the path) and then a link is provided as feedback to be used in that discussion/comment or wherever else on that site/internet.

With a third party robust filemanager as elFinder, I can specify auto thumbnail creation upon upload with dedicated readable thumbnail path.

So example.com/uploads/this-image-of-notredame.jpg shall always have a predictable thumbnail in example.com/uploads/thumbnail/this-image-of-notredame.jpg and can further have different sizes with predictable name appendages.

If the project site ever wanted to keep track of users uploads, a dedicated folder is created for the special users (group) in question

example.com/uploads/~username~/this-image-of-notredame.jpg

example.com/uploads/~usergroup~/this-image-of-notredame.jpg

I hope this info is not altogether useless.

Cheers!

R_J

You ask what a reason for having a Media table is? I think you already give one (in conjunction with what I have said above).

There are numerous ways uploading has been done in the past and nearly the same number of ways how thumbnail creation has been done in the past. Is there any reason to save the thumbs in another naming scheme? Which would be better and why?

If you work with a forum that has some history, the paths are not clear. The path doesn't have (and for privacy reasons shouldn't have) to have an user info in it. File names should (again for security reasons) not be saved as uploaded.

If the project site ever wanted to keep track of users uploads

Even if ignoring that files shouldn't be saved as /uploads/r_j/where-i-hide-my-keys.jpg, you have an additional problem if e.g. you like to have some upload gallery. You need to take roles into consideration. If a file is saved in the media table with the ForeignTable "Message", you might not want to expose it. If it has been posted in a category with custom permission, you need to take that into account.

Again: for displaying images in comments and discussions, that's not needed at all, but if you don't track that info when the file get's uploaded, it's gone forever.

If uploading files is a main feature of a forum, I would understand implementing a full blown file manager. If everything user might want is uploading files, then this might be somewhat oversized.

Bleistivt

As far as linking attachments to posts goes, the new standard way would be to parse the post when it is saved or updated for attachments by implementing Vanilla\Contracts\FormattingFormatInterFace::parseAttachments

https://github.com/vanilla/vanilla/blob/7ff99951dd896fd08a55352c87ccc64d0a8f0a3c/library/Vanilla/Contracts/Formatting/FormatInterface.php#L72

... and using the UpdateMediaTrait to keep track of attachments:

https://github.com/vanilla/vanilla/blob/b7452f95cec6e528699614ce67c64dd85b7f008e/library/Vanilla/Formatting/UpdateMediaTrait.php