Embed image thumbnails using similar method as with video embeds

Hi,

I have the _strong_ feeling that this is a theming issue.
Having the local caching of images is probably possible using some kind of library and adapting the theme so that it uses it.

I really don't think Drigg should do it.

Unless you or others can convince otherwise... But keep in mind that "because I want it" or "because it's easier for me" are not good arguments :-D Good arguments are those ones geared at showing us that something like this would *actually* belong to Drigg.

Cedric? Kevin? Coolblu3?

Merc.

Hi,

There's a major difference. Drigg doesn't actually suck anything as far as videos are concerned.
What actually happens, is that a different type of rendering is triggered according to the file type.

The very action of "sucking into Drigg" brings a huge level of complication:

* The image needs to be downloaded
* It needs to be scaled to something sane (this can take a _lot_ of memory)
* It needs to be stored somewhere
* Drigg needs to know where it's stored, and for which URL

This is all possible. However, none of it really belongs to Drigg itself. As you can see, all of these problems are "generic" -- they should be handled by some kind of external module.

It's possible to think about an extra blog field in the Drigg table, something like "contents_preview". But, as I wrote above, it's complicated and it opens up a whole lot of problems and complications.

It seems to make a lot more sense to use an external service for that -- something like websnapr, for example. And that happens at theme level: the person signs up to Websnapr, and then lets the theme to the work of pointing to the right spot to get a snapshot of the page. That way, you let a professional service do the hard work, and leave Drigg neat and lean.

Bye,

Merc.

Hi,

That would be _grand_.
If you gave me information, I will be supet-happy to do some extra work. for example, I think you might have to configure the flickr section of it passing login and password to Drigg.

Bye,

Merc.

Hi,

bflora: about being "a pain", that's totally fine. Honestly.
Thing is, without users being a pain, bugs would never be discovered. So, although a full-on user can be seen as... well, as a "pain" at times, the end result is always immense gratefulness :-D

To contact me, go to my profile pagee in Drupal and hit "contact". I will get an email right away -- and I will answer you by email.

As far as flickr, I've never ever used it and am not even sure what it does!

Merc.

I think this is an important feature that should be included in drigg. I think one major drawback between pligg sites and drigg is that pligg sites look a little more lively because of pictures. I don't know how its done in pligg but one particular pligg site there is just another field while submitting stories where you can enter the image url (I'm not sure if this is how it is done on all pligg sites). The image could be rendered from that url without having to host it.

Hi,

Blora, that CCK interaction is _insane_.
I am here keeping my fingers crossed, hoping that it doesn't happen in Drupal 6...

Bye,

Merc.

Hi,

I think it's a better strategy than wasting another 50 hours for something that might not be an issue anymore...

We'll see.

Merc.

I came across this page and the image is not hosted on the site and while submitting a scoop there is no field to specify image url.... could someone please explain how this is working.

http://indiasphere.net/entertainment/red_hot_preity_zinta_premeire_of_he...

Hi,

The site allows tags, which are simply rendered in the node...

Merc.

thanks

Hi,

bflora, I have a policy of not leaving issues hanging forever :-D
Any news on this? Are we set that this is indeed a theming issue?

Bye!

Merc.

Hi,

I am not sure I follow you here:

The code would then need to use that Flickr ID to make a Flickr API get_info call to look up the image's server #.
5. This would also need to be stored as a variable.

The problem here is that Drigg would need to add this extra value for *each* node submitted as Flickr.
So, I need to change drigg_embed so that it's actually able to store information -- extra information for each node.

This could be a meaningful addition to Drigg and drigg_embed. For example, it could *potentially* be used for images thumbnails.

This step is still foggy:

6. With these two pieces of info, a Flickr image's ID and its server number, an image URL can be created that generated a square, 75x75 px thumbnail for any Flickr image.

How would we generate the URL?

This will have to wait for the Drigg code freeze to be over. But, it won't be too long.

Bye,

Merc.

Hi,

It would be silly, and expensive in terms of bandwidth and time and CPU, to make the API call every single time.
You *ought* to make the API call once, store the URL, and stick with it.

Or am I missing something? (Which is always possible)

Merc.

Hi,

That's exactly right. The API call is the real killer -- and there is no reason why we should punish Flikr with tons of the same call when well, we ought to cache it really.
(Blus the bandwidth, the time...)

I think it's time to add caching support to drigg_embed.

But, we need to wait for the code freeze to be over... what a pain.

Merc.

+1 for "add caching support to drigg_embed". As I understand this would extend the exiry of image by 10 years, remove Etags and cache that image on person's local computer, right? Of course I'm talking about the image thumbnails for Youtube and other video thumbs.

@bflora , I looked at your site Windy Citizen. It looks like a you have managed to do something very cool: an externally hosted thumbnail image from the external news page where a larger version of that image is located. Very similar to what Digg.com does. How on earth did you manage that??? I'd be greateful for any pointers, because right now my site is all dull and boring -- no images...

Here's my 2 cents.

Image thumbnails should be a standard feature of Drigg. The very best implementation I have seen by a major social news site is Digg.com, which Drigg is basically replicating and named after. Digg.com grabs the submitted URL and grabs all images from the page. The user submitting the story then has a choice of which image to choose. The image is rescaled and saved to the Digg.com server. This way the image is only processed once, the site isn't sucking image bandwidth from other URLs, and it provides the simplest way possible for the user to add a relevant image to a story.

Merc, you had stated that this is a themeing issue or should be a separate module. I wholeheartedly disagree with you on this point because the images depend on the URL being submitted. The image thumbnail must be relevant to the submitted page and should be pulled from the submitted page. (If people want an image upload module then that should definitely be a separate module. But for anybody who wants to build a website with images relevant to submitted URLs it should be integrated with Drigg).

Ideally, on the Submit Scoop page, a set of radio checkboxes will be given with each image displayed on the submitted URL's page. If the URL is from a website that offers a thumbnail API for video or images (YouTube, Revver, Flickr, etc.) then the relevant API thumbnail should be added to the choosable images on the page. The user can also always choose No Image. When the scoop is submitted that image thumbnail will be rescaled to the administrator-specified size and saved on the Drigg site server.

This was a major feature request of Pligg but it was never built (at least not before I switched to Drigg).

I'm not making any demands or saying that my opinion is better than anybody else's, but since this is an open source project it is important that developers fully consider what the community is asking for. A developer may want to build a feature one way because that is what he would use it for, but if he were to spend more time building it another way then many more people would be able to use the feature. I don't have the time or resources to contribute to Drigg myself, but I hope that a fully functional thumbnail feature is implemented. I hope that whoever ends up creating it will do it based on what the community wants and what would actually be the best from an administration and usability standpoint, not just what is easy to code.

1. Everybody wants thumbnails on their Drigg site, even though
2. Most Drigg sites aren't image or video sites.
3. Users who are willing to join a community site and submit news don't want to spend much time submitting each story.
4. Users want to add good thumbnails to stories they submit, but they don't want to go back to the page they are submitting, save the best image, go back to the Drigg submit page, click the browse button and find the image they just saved. They want it to be quick and easy.

My opinion: Do the set of radio boxes with all images from the submitted URL. This will make happy users on all of our Drigg sites, not just Drigg sites running videos or images.

Thanks!

Hi,

I think allowing drigg_embed to store files is a good start.
The feature you are requesting is somehow connected. The problem is that it's _really_ hard to do what you're talking about: getting a bunch of images from the page, and let the user pick which one it should chose.

The best way to do it would be Javascript: a small script in the submission page would get the images from the target page, and let you pick which one you want to upload as "the" picture. Drigg_embed would then add it as the node's data.

Once the code freeze is over, I will be happy to interface myself with a Javascript guru and make this happen. But, Drigg_embed needs to be able to store stuff, that's for sure.

Thanks for the input!

Merc

Merc.

I think you're right, it would definitely be better to have the client process all of that. But can you have JavaScript pull in a page from a different domain without triggering cross site scripting issues?

Hi,

@swese44: the ajax could easily make a call to the server, which would proxy the call and return whatever it needs to to the Ajax... although it's a bit messy. And it's potentially a security problem.

Ugh. There is a reason why it took Digg ages to get this right. And why Pligg hasn't implemented.

It's hard manure.

Merc.

#24 @swese44 -- I totally aggree with everything you said, and IMO this is the diretion in which Drigg project should be moving. I'm getting so many frustrated messages from my users (almost every day), who are totally unhappy with image situation. And I'm sure this is the reason why they are giving up, leaving and the whole momentum of voting/promoting/burying process is now firtually at a halt. After months of hard work (since February) my site became more of a weekly/monthly site, rather than a dynamic daily site that every user would want to submit links to: news are usually outdated and whater interesting articles there are, they don't even have an image to catch the eye of the readers.

BTW, the process that I refered to in #23 (praising Bflora) turns out to be a usual Imagefield solution with first vote disabled -- hardly a solution for a drigg site.

One way or another, any Drigg site is a news-site of some sort and therefore it must have images of some sort. Especially sites that are just starting out and don't have an established community yet. Otherwise, it would just bore people to abandoning the site from an early start.

Hi,

I am not so sure about blaming the image issue for the site not gaining momentum... but that's probably just me.
Will try to look for a solution, but, as I said, it's anything bur easy.

Merc.

I'm also supporting the idea of thumbnail integration from the scooped website :)

Although this is a very useful feature I am disagreeing with some of the implmentation ideas suggested.

The drupal way is to build upon existing modules and not reinventing the wheel. Since we are thinking (someone should confirm) that CCK works with drigg 6.x (and if not we should put efforts to make it work), all the good stuff that comes with imagefield and imagecache can be reused. There is also emfield module. CCK is becoming defact standard and will be part of D7 core.

Hi,

I agree with bflora. What we are doing is really quite specialised.

Plus, has anybody here seen the issue queue of emfield?

Merc.

subscribed