OFFLINE-GmbH / octobertricks.com

October CMS resources and help articles
https://octobertricks.com
MIT License
40 stars 17 forks source link

Add support for trick screenshots #7

Closed tobias-kuendig closed 6 months ago

tobias-kuendig commented 5 years ago

This would make clearer what a trick does.

aniket-magadum commented 5 years ago

Is anyone working on this?

tobias-kuendig commented 5 years ago

I am not.

This could be impemented as a first version using the Responsiv.Uploader plugin. This won't allow screenshots in the content itself but they could be displayed above or below the content.

LarryBarker commented 4 years ago

Would be great to figure out copy/paste behavior right in the editor, like github. I'll do some looking into it!

UPDATE So a quick search revealed how to capture images from the clipboard with Javascript. There's also talk on Ghost forums about how to handle this.

  1. What format would be best? blob vs base64?
  2. Setup events to capture the clipboard content
  3. Need to check that it is actually an image?
  4. Use AJAX to send the data to the backend (POST /tricks/upload/policies)
  5. Place to store the images?
  6. Handler to inject the MD for displaying the stored image
SamBrishes commented 2 years ago

Hello there.

I know, this topic is a bit older... but... anyways...

EasyMDE already provides the possibility to upload images since version 2.8.0 (released in 2019). However, I created a quick prototype how it could work and came along with the following solution (The component method, shown below, still misses some validation stuff like filesize, mimetype and so on).

The EasyMDE related JavaScript code (I updated EasyMDE to the latest version)

var easyMDE = new EasyMDE({
    showIcons: ['strikethrough', 'code', 'upload-image'],
    hideIcons: [],
    element: document.querySelector('#trick_content'),
    toolbar: [
        "bold", "italic", "strikethrough", "heading", "|", 
        "code", "quote", "unordered-list", "ordered-list","|", 
        "link", "image", "upload-image","|", 
        "preview", "side-by-side", "fullscreen","|", 
        "guide"
    ],
    uploadImage: true,
    imageUploadFunction: (file, resolve, reject) => {
        jQuery(this).request('onUploadImage', {
            data: {
                'image': file
            },
            files: true,
            success: function (data) {
                if (typeof data === 'object' && (data.status || '') === 'success') {
                    resolve(data.path);
                } else {
                    reject('An unknown error occured');
                }
            },
            error: function () {
                let message = (this.responseJSON || {}).result || 'An unknown error occured';
                reject(message);
            }
        });
    },
    renderingConfig: {
        singleLineBreaks: false,
        codeSyntaxHighlighting: true,
    },
});

The required method on the TrickForm component:

public function onUploadImage()
{
    if (!Input::hasFile('image')) {
        throw new AjaxException('The passed form is invalid.');
    }

    try {
        $file = new File();
        $file->fromPost(request()->file('image'));
        $file->save();
        return ['status' => 'success', 'path' => $file->getPath()];
    } catch (\Exception $e) {
        throw new AjaxException($e->getMessage());
    }
}

Anyways, one issue stays: What happens when the user aborts the Trick creation, after uploading x pictures? I've two solution for this scenario.

  1. Each file is referenced via the system_files db. Theoretically, we could clean unused images by checking the field or attachment_id / attachment_type columns and remove them respectively. This can either happen manually via the backend or using a cronjob.

  2. Alternatively, we "skip" the upload path on the EasyMDE function and handle them after the user submits the Trick itself. This should be possible with some JavaScript magic and a simple replacement on the backend side. However, this COULD be a horrible user experience when the user uploads huge or many images (which both could be restricted, of course).

Anyways. Would do you think?

~Sam.