Store inline images in node body as fielded data

Speaking of, is the http://drupal.org/project/media module going to be used for image handling? We were looking at the 2.x branch and I think they can field images, but it's a bit clunky. The other nice thing about using media is that it doesn't require the img tag to input images ( text format goodness ).

I haven't used media module much, but from what I researched it does a similar job to insert module with image fields, but to the next level, such that it inserts tokens rather than markup so that changes can be made to the presentation of the images dynamically. This is the sort of solution I've used before to make sure images end up as useable fields, rather than just an untraceable ghost of a file as might happen with modules like IMCE.

Scraping the node body for images to put in fields is something I've wanted to do before... but it seems like there'd be issues with it, licensing for example, both in terms of making local copies of remote images, and not having attribution etc. data in the field, or caption data etc.

Then there's tracking changes for example if a user updates a node that has an image scraped - all that messing about you'd have to do not just seeing if there's an image in the body that's not included in a field, but also checking it's not been scraped before which might come down to a diff of the file!

Um, I could see where that is really messy for existing images, but if a person is clicking the image button to insert, isn't it already calling the interface to create the token? Why couldn't fields be added there?

Also, once it's a field with a token, why would you need to rescrape each time?

If its using media module those sort of inserted images will be fielded anyway won't they? Think the tokens rely on fielded data, and the wysiwyg helpers for media module in editors like ckeditor just provide an additional interface for sticking images in fields and inserting the token?

Good point though, if images were scraped and the markup replaced with a media token, that means that they wouldn't be re-scraped on update, so I guess this could work. There's just the problem of missing data in the field, like attribution info etc. that might just be in the node body rather than in some place that can be detected programatically like in alt/title/data attributes. Plus a lot of the solutions for sticking remote images in fields rely on caching the images. In this silly age of site admins being responsible for whatever rubbish our users stick on a contributor-driven website that adds extra implications in terms of responsibility for the data we're importing/storing through caching.

It's no big deal for me because I'm using Commons for purely private groups, but if I was running a public site I'd probably want to avoid that, I'd probably want to allow external resources e.g. for stuff like these screengrab services, but I wouldn't want to cache them locally. Maybe just do it with internet sources that media module can handle properly like flickr/youtube etc. (i.e. media module can manipulate resources on these websites without having to grab the files)?

I guess I'm still confused, why would it need to scrape the image to begin with? When the user clicks the little mountain image thingie in their Wysiwyg, it pops a modal that allows them to browse and set height /width type stuff. Why wouldn't the module have the fieldable data in the modal? It would be in the fields from the start...no scraping necessary. Unless I'm missing something ( I will admit, I haven't actually looked at the code ).

If the data is in fields and loaded to the file system, why couldn't it be cached? That was one of the reasons why I really liked the media module...because it would give me the ability to prevent giving your average bear tags, which is a security risk. And it will allow more granular control of what kind of garbage they can upload.

Internet sources is definitely another possibility.

To accomplish this, we probably need to detect images embedded inline in the node body that are not already included in fields, and add the images to fields.

I was referring to the above, which if I understand correctly is about capturing images in fields that for whatever reason, haven't already been put in them from the method by which they're inserted? May be wrong! I suppose so long as the editor is reasonably well configured there aren't going to be too many avenues for this to happen, pasted markup, custom markup, or perhaps if that mountain image button thing falls back to simple insertion of tokenized or plain markup for cases like remote images (if it does do that, it's probably actually easier to field the data through scraping than to reconfigure that button to instead have some ajax loopback to re-route the data into a proper field)?

If they have old img tags in there, then maybe they should remove them and manually re-add the image. If this functionality is 80% of the way there I think that's good enough so long as folks understand what's happening. Scraping the data just seems very complicated.

My thoughts exactly, doesn't really seem worth the effort.

Guessing that this has pretty much been implemented already. Please reopen if I am mistaken.