XF 2.1 Xenforo 2.1.9 cannot copy and paste to hotlink images from clipboard with image attachments turned off (worked in 1.5)

the

Active member
As described here (I have investigated the reply, that does not solve this issue)

Desribed here with much confusion in the replies about the behavior. The issue is NOT attachments. Some of us turn attachments off for space/copyright reasons:



1.5 Behavior:
Turn off image attachments.
Users can right click an image from the web and select 'copy image' and the right click and paste it into the text box. This created an instant hotlinked image preview in the rich text editor. This was very useful for skipping additional steps of copying and pasting image URLs, clicking a drop down menu, pasting the URL. Many extra steps.


2.1.9 Behavior:
Turn off image attachments.
Right click 'copy image' from the web, right click 'paste' into the text editor. Nothing happens.


Is there a fix for this?
Is there a work around to avoid the copying and pasting URL text into image menu of the text editor? This is antiquated behavior and adds steps.


Thank you.
 
Last edited:
Please stop derailing my threads.
I'm not derailing your threads.

I've replied to this and this one only, offering you potential solutions and workarounds to a situation you perceived as a bug, when it is by design.

The posts and solutions will be there for others in the future if they come across this thread. Just because you didn't get the answer you were after, doesn't mean the information in this thread is useless to others.
 
Hello,

This is, indeed, a big issue. A lot of our customers used to copy and paste the content info they found or even content they posted themselves in other forums of similar interests. Now we found out how that is no longer possible and that lowered our userbase activity by A LOT since they can't be bothered to upload all the images manually one by one instead of just pasting the whole thing and pressing "Post Reply".
This is a huge downgrade compared to other forums and should be classified as a bug, as I don't think anyone would want this functionality to be forced on them. If anything, it should allow users to decide wether if they want one option or the other.

Regards,
Zentral
 
that lowered our userbase activity by A LOT since they can't be bothered to upload all the images manually one by one
If you believe that's the case, something else is causing a drop in user activity. This isn't a bug, it's by design and been explained as such.

I get what you mean about say copying and pasting an entire news article (and it will drop in the pictures and hotlink them), but in reality it probably shouldn't be done anyway.

The idea of pasting images and having them hotlinked externally (effectively bandwidth theft), is dead these days. Most major forum software have exactly the same approach as Xenforo 2.1 does to images, and most users actually prefer that way (because it also means no dead placeholder images in the future when a hotlink expires, or hotlinking is blocked).

Let's use Photobucket and Tinypic.com as examples of this, and with the hotlinking issue discussed in this thread.

Photobucket deletes accounts if they are dormant for 2 years. Therefore anyone pasting/hotlinking in images from Photobucket and then becomming inactive, will result in dead placeholders in an older thread.

Tinypic.com was loved by many over the years and was "the" image hosting site of choice for that era. Eventually it died off and any forums with images hotlinked from there showed ugly placeholders for threads.

With storage so cheap these days it's far easier and more beneficial to host images locally and use the built in features to control as such.

If users can't take a few minutes to better publish a post, it's to the detriment of your entire forum.
 
If you believe that's the case, something else is causing a drop in user activity. This isn't a bug, it's by design and been explained as such.

I get what you mean about say copying and pasting an entire news article (and it will drop in the pictures and hotlink them), but in reality it probably shouldn't be done anyway.

The idea of pasting images and having them hotlinked externally (effectively bandwidth theft), is dead these days. Most major forum software have exactly the same approach as Xenforo 2.1 does to images, and most users actually prefer that way (because it also means no dead placeholder images in the future when a hotlink expires, or hotlinking is blocked).

Let's use Photobucket and Tinypic.com as examples of this, and with the hotlinking issue discussed in this thread.

Photobucket deletes accounts if they are dormant for 2 years. Therefore anyone pasting/hotlinking in images from Photobucket and then becomming inactive, will result in dead placeholders in an older thread.

Tinypic.com was loved by many over the years and was "the" image hosting site of choice for that era. Eventually it died off and any forums with images hotlinked from there showed ugly placeholders for threads.

With storage so cheap these days it's far easier and more beneficial to host images locally and use the built in features to control as such.

If users can't take a few minutes to better publish a post, it's to the detriment of your entire forum.

Hello,

We use our own image hosting powered by chevereto and we don’t mind reuploading the images to our own image hosting ourselves, but we can’t do that if our users don’t post their content anyway.

You say that our activity drop is not related to this without any solid evidence to back it up when we received dozens after dozens of complains about this issue and the activity drop was registered exactly the moment this feature stopped working.
You say it shouldn’t be done anyway and the idea is dead yet you can do a quick search and find bug reports, requests and questions everywhere about this exact same issue.

In all honesty and without trying to sound rude, I would like you not to reply if what you are going to do is try to convince me that my issue isn’t that much of an issue or why I should adapt to the change. I explained thoroughly why this is a problem for us and for a lot of our userbase and we are not alone in this. It’s been requested several times in this exact forum and there’s a lot of threads not happy with the implementation of this so called functionality. Having attachments disabled should never result in users unable to paste pictures into the editor, but rather force the bbcode insert instead.

Regards,
Zentral
 
We use our own image hosting powered by chevereto and we don’t mind reuploading the images to our own image hosting ourselves, but we can’t do that if our users don’t post their content anyway.
So why not have a custom solution that instead of uploading to your forum it uploads to your image host instead?

You can offload the storage of images from Xenforo installation to an external source (I've seen articles on it on here before).

You say that our activity drop is not related to this without any solid evidence to back it up when we received dozens after dozens of complains about this issue and the activity drop was registered exactly the moment this feature stopped working.

You say it shouldn’t be done anyway and the idea is dead yet you can do a quick search and find bug reports, requests and questions everywhere about this exact same issue.
I'm not saying "it shouldnt't be done anyway", I'm saying that the issue is "by design", in order to resolve two specific issues:
1. The long reported and frustrating issue that long term board owners found with regards to image hosts closing doors, and placeholders wrecking threads in the process.
2. To prevent bandwidth theft via direct hotlinking of images to another host.

Those were decisions made by Froala, not by Xenforo or it's developers, and given that Froala haven't listened on far bigger issues than this, they are unlikely to roll back a feature that was implemented most likely due to polar opposite complaints.

It simply does not make sense to hotlink images from elsewhere (without using the current functionality to do it).

Remember we aren't talking about a feature removal here, just a change by forcing a few extra mouse clicks.

In all honesty and without trying to sound rude, I would like you not to reply if what you are going to do is try to convince me that my issue isn’t that much of an issue or why I should adapt to the change. I explained thoroughly why this is a problem for us and for a lot of our userbase and we are not alone in this. It’s been requested several times in this exact forum and there’s a lot of threads not happy with the implementation of this so called functionality.

In all honesty, and without trying to sound rude, but you sound suspiciously like the OP with a ghost account.

Brogan is a forum moderator and already explained it's not something that can be done.

Having attachments disabled should never result in users unable to paste pictures into the editor, but rather force the bbcode insert instead.
Take it up with Froala as it's not a Xenforo issue, and if you look into other alternatives to Xenforo they behave in exactly the same way (at least up to the previous version of InvisionBB/VB Cloud).
 
Please stop harassing me. You've already trolled my thread and ruined it. Now you pull me into your next argument?

FACT: I didn't TROLL nor RUIN your thread.

You're just annoyed you didn't get the answer you were after, from one of the site moderators who has direct access to the Development Team.

As it stands, there is no way of directly allowing copied images to be embedded without using the pop up.

That is a decision by Froala, NOT Xenforo.

Froala are a $100 million dollar turnover company. It's akin to asking Microsoft to change something in Windows 10 because you don't like how it performs, it's never going to happen.
 
Take it up with Froala as it's not a Xenforo issue,

I can't help feeling there is some slight xenForo issue, if only the way that permission is phrased which seems not exactly what it says on the tin.

If you have permissions to upload an attachment, there are three ways to hotlink:

  • Via the image URL pasted into the popup
  • Copy and paste form the browser
  • Drag and drop from the browser. (This will also copy the link if the image is linking to something. Nice)

All of which are hotlinking (they end up embedding via URL) and don't seem to be related to uploading

However if you do not have attachment upload permissions, then only the first option is available.

So to me, this does not seem to be 100% a Froala thing, as the "middleman" here seems to be the xenforo permission that actually describes a different action (uploading as opposed to linking)

And although I get this

As it stands, there is no way of directly allowing copied images to be embedded without using the pop up.

It seems open to interpretation because it is allowed (via drag & drop) if you have the (other) permission.

Or maybe I'm misunderstanding this whole issue.
 
Last edited:
FACT: I didn't TROLL nor RUIN your thread.

You're just annoyed you didn't get the answer you were after, from one of the site moderators who has direct access to the Development Team.

Please stop spamming and attacking others. Even when I'm not posting in a thread you bring me up while arguing with others. When I ask you to stop you attack.


Please stop harassing me.
 
I'm not saying "it shouldnt't be done anyway", I'm saying that the issue is "by design", in order to resolve two specific issues:
1. The long reported and frustrating issue that long term board owners found with regards to image hosts closing doors, and placeholders wrecking threads in the process.
2. To prevent bandwidth theft via direct hotlinking of images to another host.

Those were decisions made by Froala, not by Xenforo or it's developers, and given that Froala haven't listened on far bigger issues than this, they are unlikely to roll back a feature that was implemented most likely due to polar opposite complaints.

This issues stand when attachment files are disabled as those points you mentioned don't change. We are not asking for the drag & drop/copy & paste funcionality to change in every situation, but rather for XenForo to have the ability to detect if you have attachments disabled and hotlink BBCode instead of just leaving a blank space where the images should be. This could be done on XenForo's side as it's their upload functionality the one that's called and XenForo can decide what's written in there.

In all honesty, and without trying to sound rude, but you sound suspiciously like the OP with a ghost account.

If you did your research, you would have found we are license owners that have various threads and comments in this very own forum. Telling me that I sound suspicious just because I call most of your derailing useless and find your comments misleading towards the legit claims of forum owners about an issue, is straight childish and makes me lose any interest in replying to you further, so please don't quote me anymore.

I can't help feeling there is some slight xenForo issue, if only the way that permission is phrased which seems not exactly what it says on the tin.

If you have permissions to upload an attachment, there are three ways to hotlink:

  • Via the image URL pasted into the popup
  • Copy and paste form the browser
  • Drag and drop from the browser. (This will also copy the link if the image is linking to something. Nice)

All of which are hotlinking (they end up embedding via URL) and don't seem to be related to uploading

However if you do not have attachment upload permissions, then only the first option is available.

So to me, this does not seem to be 100% a Froala thing, as the "middleman" here seems to be the xenforo permission that actually describes a different action (uploading as opposed to linking)

And although I get this



It seems open to interpretation because it is allowed (via drag & drop) if you have the (other) permission.

Or maybe I'm misunderstanding this whole issue.

Hello,

I think that the way you explained it basically sums up why some people is upset about this issue.

After you paste a picture in the editor, Froala calls for a function. In the case of XenForo this function would be the attach upload call function. XenForo, however, should be able to detect if "Attach files" is not turned on and, in that case, the query to upload should instead be replaced by the insertion of a BBcode with the hotlink of the image copied which should be on the copied image data. This should be doable on XenForo's side and would solve everyone's issues wether they want hotlinking or attaching the images pasted, since the attach files functionality being turned on or off would be what defines how the forum reacts.

Just like you said, it makes no sense at all to remove options for users just because they don't want the attach files option available for all users. There should be an alternative.

Regards,
Zentral.
 
Sorry you'll have to excuse my underlying frustration at times. I have to deal with people at work who don't understand being told things either.

What you're asking for can't be done. It's not possible. I don't know how many times it needs to be stated in this thread.

This could be done on XenForo's side as it's their upload functionality the one that's called and XenForo can decide what's written in there.

Take the example of another issue (which is far more pertinent and should be fixed - i.e the issue with file sizes blowing out when copy and pasting images), that is 100% Froala which handles when images are uploaded into the text editor.

Xenforo looks after how they are stored (once they hit the database), but not specifically the way an image is attached.

I think you'll find therefore that Xenforo is simply calling Froala functionality to handle such requests.

For example - these are both Froala functions:
  • Attach an image (via Attach Files) - it stays the exactly the same size, even though it is uploaded to Xenforo.
  • Paste an image into the text editor (which by default uploads to Xenforo), and the file size is COMPLETELY different, because Froala processes the file as an uncompressed PNG file.

Hence I'd suggest the functionality of "paste an article and hotlink inline images" and "paste an article but upload inline images" are also both handled by Froala.

Just like you said, it makes no sense at all to remove options for users just because they don't want the attach files option available for all users. There should be an alternative.
Have you considered that perhaps there might be legal obligations for that function to be removed in order to meet GDPR compliance or relevant copyright laws?

Don't get me wrong, I 100% can see and understand the issue you are complaining about, however previously people asked for the exact opposite (that images are uploaded locally when pasting articles) and the merits of doing so far surpass the issues created by not allowing that functionality. Hence why the function still exists (by way of INSERT > IMAGE > drop URL). It's a middle ground to still offer that function IF required.

In order to understand why such a request simply is not possible, you need to understand what you are asking the code to do.

The pasting of information is a call/catch procedure (Hey Froala I'm about to paste in some data, HERE IT IS), whereby the INSERT > IMAGE is direct functionality (here's a link).

One is pasting data via a memory dump (anything and often encoded), the other is only expecting a hyperlink in plain text (INSERT > IMAGE). One is binary, the other plain text.

The catch/call procedure doesn't know what data is being dumped from memory, it just knows that data is being dumped. I don't believe there is a way to cherrypick exactly what information is being acted on, as if you picked up on an HTTP hook to an external image, it'll stuff up pasting in hyperlinks (which will create a real mess of things).

Hence I don't believe it's possible to change the behaviour of a call/catch procedure (because it is preprogrammed on what to look for).

Just like a power point or a light switch it's either ON or OFF, I don't believe there isn't any variation possible.

SOURCE: Family member is a programmer of 30 years with experience in assembly languages, python and js.

ANYWAY I've had my say on it, and I'm out. Be sure to let me know when this ever gets included/reverted, because I can tell you it won't.
 
What you're asking for can't be done. It's not possible. I don't know how many times it needs to be stated in this thread.

Probably a lot of times because the answers have not yet made any sense.

  • You can copy and paste an image from another site (via your browser) into a post and it hotlinks (does not upload)
  • However this only works when you have the permission to upload an image - which is a totally different thing to hotlinking (that does not upload)
So can anyone explain this anomaly? Or is it just the xenforo phrase for the permission, which (in order to make sense in regard to what it actually does, should read:

Upload attachments to posts and also be able to hotlink by copy and paste from a browser.

 
So can anyone explain this anomaly?
That's sort of different from what the original post was about and admittedly that is sort of weird. Though I'll say all of this stuff does end up being controlled deep within Froala -- we generally don't have a great way to override these behaviors.

In terms of the original post -- where you right click copy and image -- what's in the clipboard is a binary representation (the image) and a text/html (the <img> tag referencing the URL) representation. The binary representation is prioritized (with Froala) but since attachments aren't possible, the upload gets blocked.

In a case where you're copying HTML there isn't a binary representation (text/plain and text/html) and I'm not sure what the internal code flow is yet that causes this behavior.
 
Thanks MIke, but I'm not understanding what is different between what I'm saying and the OP.

I thought we are both talking about the ability to right click copy an image in a browser and paste directly into text editor (which, as with drag and drop) is a quicker way to create a hotlinked image than copying the image URL and pasting into the popup.
 
The key part was this part of your post:
You can copy and paste an image from another site (via your browser) into a post and it hotlinks (does not upload)
Assume attachments are enabled for now since you can see the differences.

Based on this particular explanation, you're getting an [IMG] tag. Nothing is being uploaded, the image is hotlinked. This is the situation where there is no binary representation in the clipboard.

In the original post:
Users can right click an image from the web and select 'copy image' and the right click and paste it into the text box.
This one actually has the image data in the clipboard. If attachments are enabled, the file gets attached (and inserted via [ATTACH]).

Internally, the code paths are totally different. The latter sees a file. It's not a textual paste at all.
 
That's sort of different from what the original post was about and admittedly that is sort of weird. Though I'll say all of this stuff does end up being controlled deep within Froala -- we generally don't have a great way to override these behaviors.

In terms of the original post -- where you right click copy and image -- what's in the clipboard is a binary representation (the image) and a text/html (the <img> tag referencing the URL) representation. The binary representation is prioritized (with Froala) but since attachments aren't possible, the upload gets blocked.

In a case where you're copying HTML there isn't a binary representation (text/plain and text/html) and I'm not sure what the internal code flow is yet that causes this behavior.
Thanks for explaining things far better than I was able to Mike!

So to clarify what you are saying, and using this image of a shoe for example:

TEXT/HTML (copy image URL from another site and paste) = https://www.target.com.au/medias/static_content/product/images/full/07/18/A1390718.jpg

CLIPBOARD (right click, copy image, and paste image) (BINARY) =
/9j/4AAQSkZJRgABAQEASABIAAD/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdCIFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFjcHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAAABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAADTAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJDAAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAA (and so on).

So does that means Froala recompiles the image from Base64 Binary when an image is copied and pasted into the editor?
 
So does that means Froala recompiles the image from Base64 Binary when an image is copied and pasted into the editor?
Well the data comes from the browser itself, but it is being accessed via JS in Froala.

So regarding the distinction I talked about, I have been able to workaround hotlinked images being stripped out unexpectedly. This would generally apply to highlighting text (that includes an image).

But in the case when the clipboard actually contains an image, as far as I can tell, there isn't anyway that we can adjust the behavior. This isn't something I would expect to see changed in the foreseeable future.
 
Thanks Mike,

Cracking job you and the team have done on Xenforo by the way. The evolution from v1.x even to v2.1 is amazing!

You should all be immensly proud of the product you've created.

So regarding the distinction I talked about, I have been able to workaround hotlinked images being stripped out unexpectedly. This would generally apply to highlighting text (that includes an image).
That fix could actually work really well in situations that aren't all that uncommon.

For example a user wants to share an article so they copy and paste the entire thing (which normally includes all the photos and everything). From a copyright perspective that can muddy the water because the photographer and the media site potentially both own copyright and royalties on the image being used on other sites.
 
Well the data comes from the browser itself, but it is being accessed via JS in Froala.

So regarding the distinction I talked about, I have been able to workaround hotlinked images being stripped out unexpectedly. This would generally apply to highlighting text (that includes an image).

But in the case when the clipboard actually contains an image, as far as I can tell, there isn't anyway that we can adjust the behavior. This isn't something I would expect to see changed in the foreseeable future.

Hello,

Thanks Mike this is actually more than enough since the main concern is usually when users copy and paste blocks of text including images. For single images it would not be that much of an issue since, like @RallyFan said before in one of his posts, it would literally be just a click more. For big articles this, however, would not work as you would have to upload manually a big bunch of images and that’s actually tedious. Specially when we talk about big posts/articles. Did you manage to workaround this? Is it easy to do?

Regards,
Zentral.
 
Top Bottom