New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Editor Paste / Drag-drop Image Handler #4359
base: feature
Are you sure you want to change the base?
Conversation
…hardcoded js to js file
Questions:
@mybb/reviewers |
Agreed, @Eldenroot - it's excellent work, and it would be great if we could get this in to 1.8.27 at the last minute.
Yes, for sure. I was away for a few days (oh, and you left out my surname in the mention - poor old Laird Popkin from Atlanta, Georgia must be feeling quite confused!) but have now tested this PR and have been in contact with @effone about it. There are a few minor niggles to sort out, but generally it seems to work as advertised, which will be a relief to so many of our users who have been caught out by this missing feature. My list of minor niggles is:
I'm also not sure whether serving the image files directly out of the @effone also made a good case to me privately for renaming |
Would it be better to handle uploaded files as regular attachments? That would make it an interface improvement without introducing new kinds of uploads and locations watch out for. The editor field and attachment section could then be merged in the future. With that behavior, we can just add server/client-side hooks to allows plugins to intercept such uploads (and insert external |
As has been clarified before also, embeds are not attachments. They should not be treated as one and should not impact on allotted quota either. Regarding other platforms it has been discussed with @euantorano and agreed upon that I can approach towards third party upload APIs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Uploads path should be updated to use absolute path.
- Imgur and Imgbb API settings should be spliced.
- I think this plugin should somehow mask image links, rather than disclose the full path like in
[img]http://localhost/mybb/./uploads/postembeds/1_1620719162_blob.png[/img]
- For privacy purposes images should only be served if the user has permission to the post being seen. It isn't necessary to ship all these features in, but having a file to serve the images could make it easier for future improvements.
- There are no image manipulation settings, like maximum dimensions, size, or resize features.
- I think the feature should be disabled by default, or rather well reported in the release blog.
I approve this because it seems to work as is, but please consider my suggestions above.
global $mybb, $db, $lang, $plugins; | ||
|
||
$dir = trim($mybb->settings['postembedpath'], './'); | ||
$files = glob(MYBB_ROOT."{$dir}/*.{jpg,jpeg,png}", GLOB_BRACE); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't this be problematic for large amount of files? Will the task always fulfill properly regardless of the amount of images? I'm a little surprised by the lack of a database table to control uploaded images, which limits the addition of some ACP interface to manage these unless, for example, being somehow merged with the current attachments tools later on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The concern is correct at I have not done a performance benchmarking.
Am open to accept any suggestion to improve this. I also felt the necessity of a dedicated table for upload entries. Didn't follow that way as that can be considered as Big Change
leading to rejection of this PR.
That will be requiring a proxy (see comment below)
Hmm. OK. But why it is problematic as what it is now? Admins gonna use either of the services anyway
A considerable point from the privacy point of view.
A good point, and that file can proxy the images as well, supporting absolute paths. But this will exhaust this PR further, anyway.
As said, this is the basic PR. Further possibilities are there to enhance it. Can be done in this PR as well, if agreed upon.
So you propose an additional setting for the behavior introduced? Well, that can be done as well. I guess @dvz was also asking for something similar... |
I think you need to add some hooks where possible. Also, I did try to disable the forum setting
I think |
We have followed this reasoning before, mainly to avoid confusion and keep both data fields stored in case the admin wants to toggle the service being used. It is not a big deal, if somebody else thinks it isn't worth it.
I don't think @dvz did mean this in his comment above (which I also brought before), what I meant is that this feature being enabled by default could be problematic for admins when they update their boards, as some even disable the attachment system. Also, although you seem to be using the core upload functions, I'm unsure your code will work with CDN settings, as at least I noticed you use |
Just recalled, I think this should be shipped along the docs update required, if not for the feature description indeed for the new uploads path in the install and configuration section (permissions doc, etc). |
Temporarily prevent drag-n-drop of images into the editor until PR mybb#4359 is updated and included in 1.9.
Resolves #2440, resolves #4078
Overrules #4080