feat: markdown editer support paste image

[myml]

[belac9615]

I really want this for our company and would love to have it reviewed and merged. I can contribute if changes are needed.

[adroslice]

I really want this for our company and would love to have it reviewed and merged. I can contribute if changes are needed.

Same here. It's an extremely useful feature for productivity, one that I would have wanted to work on in the very beginning if I started a project like this. I think physihan makes a good point about only uploading on save, and I think there's an opportunity to add a small dialogue to customize the file name and location on save (that has good defaults to make just pressing enter viable, default field should be name).

[zhuzhzh]

This feature is really useful and important for the productivity. hope it can be merged soon.

[cAttte]

who IS is in charge of this project? this is literally the top feature request on the feedback website, yet not a single official comment has been sent here regarding merging, reviewing, or closing this PR in favor of another one. and no, it's not sufficient to place a big label saying PLANNING then proceed to do nothing, especially not when the release of v3 has been in the PLANNING for two years now.

[defteame]

@NGPixel is there any possibility you will review/merge that?

[NGPixel]

There're many issues with that PR:

• It uploads to the root directory, which is a big no. Many users have page rules that only allows asset uploads to specific paths and most likely only the same path as the page itself.
• Not fond of the filename being hardcoded to a datetime string. It should keep the local filename unless it already exists.
• It shouldn't read the token from the cookie. Read it from the vue user store instead.
• There's no error handling if the upload fails and gets a forbidden error.

[myml]

There're many issues with that PR:

* It uploads to the root directory, which is a big no. Many users have page rules that only allows asset uploads to specific paths and most likely only the same path as the page itself.

* Not fond of the filename being hardcoded to a datetime string. It should keep the local filename unless it already exists.

* It shouldn't read the token from the cookie. Read it from the vue user store instead.

* There's no error handling if the upload fails and gets a forbidden error.

1. Done!
2. The image in the clipboard does not seem to have it original name ? here is discussion https://github.com/requarks/wiki/pull/6017
3. jwt is not in vue store, The media manager module also uses cookie. https://github.com/requarks/wiki/blob/main/client/components/editor/editor-modal-media.vue#L318
4. Done!

[yfdoor]

It's really a useful feature, hope it can be merzed soon...thanks @danieldll099, @NGPixel

[P4R4DiSi4C]

Any news on this guys?

[parksj10]

and here I am... very useful if it's added

[P4R4DiSi4C]

@NGPixel is there any possibility you will REreview/merge that?

[parksj10]

FYI, this is a somewhat related feature.... https://github.com/requarks/wiki/pull/6017#issuecomment-1470934515

[yfdoor]

@NGPixel Could you pls review this PR with #6017 ? thx

[R0Wi]

To circumvent most of the mentioned problems in https://github.com/requarks/wiki/pull/5441#issuecomment-1367574668 regarding permissions and "finding the right place to upload the file", an alternative approach would be to embed the image directly into the markdown like this:

![MyImage](data:image/png;base64,<BASE64_STRING>)

I think the draw.io integration does something similar here. @NGPixel would that be the preferred solution? Please let me know if any help needed since I'm also very interested in this feature.

[codiflow]

@R0Wi I really like your idea and digged a bit deeper into it. I also found some solutions which already can be used 😎

So adding base64 images to a wiki page is already possible, BUT...

• we would need some "collapsible" like with the draw.io integration, because the base64 makes the wiki source area completely unmaintainable

For supporting base64 copy of images within Firefox you can just install a simple plugin like this one. Now you just have to right click on the image you want to paste in your wiki and choose "Copy image as base64". Adapting the source code of the plugin to reflect the markup like ![MyImage](data:image/png;base64,<BASE64_STRING>) in your clipboard would also be possible.

• BUT this does not solve the problem if I want to paste images from within my clipboard

---

So I found another solution for this:

Just use the Firefox plugin Clipboard2File (Source here) to get the current image from your clipboard and present it to the upload function in Wiki.js. You manually have to set dom.events.asyncClipboard.clipboardItem in about:config to true to make this work. After doing this the plugin works like a charm.

This solution would still need more clicks than just copying & pasting an image but you can skip the steps to save the file locally, upload it and delete the local file afterwards.

I really like this as a temporary solution because pasting images from the clipboard into Wiki.js might be supported natively one day.

[codiflow]

Here's a short screencast of the "Clipboard2File" solution (which I personally prefer):

https://user-images.githubusercontent.com/43847817/233721878-a04c54e7-766d-48cd-9d9b-9bc11919ba6c.mp4

[zhuzhzh]

is anyone reviewing the new fix?

[xumenghe1989]

Any news on this pr ?

[novachem-admin]

How is this not released yet? Massive hinderance to adoption on my team.

[dberardo-com]

How is this not released yet? Massive hinderance to adoption on my team.

it has been almost 2 years since v3 was firstly announced and i assume that the team is working more on that rather than fixing stuff for v2 ... thats my guess, could also be that this project was sadly abandoned altogether ...

i think it would be easier to fork the repo from this PR and build an own version of the gui instead of waiting for this PR to be reviewed.

btw i am evaluating alternative tools to wikijs, has anyone had any experience with https://www.getoutline.com/ _

[NGPixel]

@dberardo-com Please stop spreading FUD, this project is definitely not abandoned and I have no idea how someone can possibly come to this conclusion. Updates about v3 are posted on https://blog.js.wiki/ and you can see regular activity on the vega branch (and even try it yourself if you're comfortable enough).

v2 has regular updates, almost every months, with the last one being from 2 weeks ago. This is not a full-time project and most of it is put towards v3. The reason I'm hesitant to put time into reviewing and improving larger PRs like this one is that while it does solve a problem, it's still a very imperfect solution and can introduce new problems, e.g.:

• what if you don't have the rights to the current folder path, or to create the folders required to get to the current path? The PR doesn't handle these scenarios right now.
• the filename is hardcoded to a long timestamp + random bits. Some users will complain that it's not keeping the original filename.

I'll try to put some time into getting this PR in soon, but it will likely end up behind a toggle, as the experience is not polished enough yet.

[novachem-admin]

I'll try to put some time into getting this PR in soon, but it will likely end up behind a toggle, as the experience is not polished enough yet.

@NGPixel Thank you. My team will be extremely happy to see this enhancement! With regards to the upload location, we've used both Azure DevOps and Git and it seems the default functionality is to upload to an attachment folder and set the file name to a guid. Perhaps not the cleanest, but realistically I doubt an entire IT team will follow a consistent approach if given the opportunity to store images wherever they want anyways.

Looking forward to 3.0 as well! Looking great. M

[dmc6297]

@R0Wi I really like your idea and digged a bit deeper into it. I also found some solutions which already can be used 😎

So adding base64 images to a wiki page is already possible, BUT...

• we would need some "collapsible" like with the draw.io integration, because the base64 makes the wiki source area completely unmaintainable

For supporting base64 copy of images within Firefox you can just install a simple plugin like this one. Now you just have to right click on the image you want to paste in your wiki and choose "Copy image as base64". Adapting the source code of the plugin to reflect the markup like ![MyImage](data:image/png;base64,<BASE64_STRING>) in your clipboard would also be possible.

• BUT this does not solve the problem if I want to paste images from within my clipboard

So I found another solution for this:

Just use the Firefox plugin Clipboard2File (Source here) to get the current image from your clipboard and present it to the upload function in Wiki.js. You manually have to set dom.events.asyncClipboard.clipboardItem in about:config to true to make this work. After doing this the plugin works like a charm.

This solution would still need more clicks than just copying & pasting an image but you can skip the steps to save the file locally, upload it and delete the local file afterwards.

I really like this as a temporary solution because pasting images from the clipboard into Wiki.js might be supported natively one day.

I just submitted a PR that adds a collapsible section and allows pasting of a image from the clipboard to a base64 encoded html tag.