Satus of D6?

Hi Pobster,

I've made some changes to it, but finally got around to creating an actual project for it so everyone else can download it.

I was actually waiting to see how the entire imagefield/CCK vs. image module thing plays out for Drupal 6. I was thinking of upgrading MAQUM to D6 and in the process, switching it from relying on image module to relying on imagefield/CCK. Assuming that CCK with an imagefield takes over from a simpler, plain image module, rather than have each IPTC field and EXIF field be created as taxonomy terms within their own vocabulary, maybe the future of MAQUM is mapping EXIF fields and IPTC fields (the metadata in the images) to CCK fields.

I'm not sure if this would be better or worse than using taxonomy, possibly just plain different.

This weekend I'm hoping to create a screencast for the module and link to it from the project page.

It seems like in addition to image being merged into imagefield/imagecache, there is also talk of ending imagefield in favor of filefield with an image helper (more). So for this reason, a Drupal 6 version of MAQUM looks best to be postponed.

subscribing... (I might be in favour of a image-version rather than the CCK-one (because i'm unfamiliar with it))

In the interim, if I wanted to get MAQUM working with imagefield/imagecache, instead of with image, how could I do it?

You might want to look at filefield and filefield image, instead of imagefield, though it really is up to you. See #275011: MAQUM in Drupal6 for some links regarding the future of image handling in Drupal 6 and why I'm hesitant to just pick one way of doing it.

As for how it would be done, I think the phrase you need to look out for is programmatically creating CCK nodes. Here's a bunch of likes you can use to get started:

Programmatically creating CCK nodes in PHP (interaction with the Path module) | sacha chua
Programmatically create a node with CCK fields? | groups.drupal.org
Programmatically Create, Insert, and Update CCK Nodes | civicactions

I don't think it should to too hard to switch gears, my concern is constantly switching gears, no one wants to do that.

It looks like long term (Dripal 6+), the better bet is MAQUM relying upon imagefield and putting the metadata into CCK fields (as opposed to creating a vocabulary for each metadata field, as is currently done). The exception being the IPTC field, keywords, that should be a taxonomy vocabulary that is set up for tagging.

+1 on the storing metadata in CCK fields (seen stuff about CCK/taxonomy integration already anyway)

+1 on the keywords exception, only makes sense

Regarding the link to the image file itself, Yech! what a mess this area of Drupal is at the moment, I really sympathize that this has been holding back porting to D6 - the Chinese curse about interesting times comes to mind!

Here's a (radically conservative suggestion?) although it might seem just idiotic, I'm not technically in a position to have any idea what's required to implement these ideas, just coming at it from a poor confused noob's POV:

Support them all and become the image-handling saviour of Drupal!

I believe it's possible to have Image nodes with CCK fields, as long as none of them are Imagefield CCK fields right? Must be or what you're proposing wouldn't make sense. . .

A CCK content type with one single-value Imagefield is of course functionally the same as a traditional Image node, just won't work with the legacy Image family of helper modules - I reckon Imagefield-based analogues will come if/when Image module starts to be deprecated. Your module is a classic example of why all significant images should "be" nodes, so I'd steer well away from supporting nodes with multiple-value or multiple imagefields.

Let the admin set a config option to create either "Image module nodes" or "new style MAQUM" Imagefield CCK nodes or even BOTH!!! Maybe make these defaults, overrideable at upload time.

Personally (but not just to make life difficult for you :), I'd also consider supporting Asset module, since that gives both inline macro-tag support and CCK/Views support with re-usability (don't have to re-upload duplicate files just to display an image in more than one node) and support for role-based security within Public uploading and the ability to organize the directory structure of the filesystem rather than just dumping everything into one big folder. (On this last bit, check out Upload Path's use of automated token-based directory organization - way cool!)

What positions your module as a potential saviour is that you don't do any input filtering/display handling, so you can be a neutral third party in the current "image wars". You can tell I like Asset's "best of all possible worlds" potential for image-handling, since it seems unlikely that any of the different development groups will be doing the work necessary to get these different methods integrated together.

Sure it's a lot more up-front work, but you've already got the Image compatibility layer done. And I can't see any of these three actually changing the storage/DB routines of their methods much within the D6 lifespan, just the user UI and filter/display parts, so you shouldn't have to keep modifying your module to keep up with changes - at least not until D7's brand new Files API starts to solidify - but (fortunately?) that's looking to be a pretty distant future from here.

Of course it would be ideal if this could be pluggable/API based. . .

Thanks for your patience wading through all this probably unrealistic gibberish!

Patches welcome.

I know, ideas are cheap, but I'm just a user not a coder.

I saw your post #6 as an invitation for ideas, forgive me for blathering on like that.

If you're only going to support one, +1 for Image nodes + CCK for the field data if that's possible.

I used ImageField in my family website http://www.weiersmuller.org. I would love to have a version of this module working with ImageField (I am on Drupal 5.10 by the way).

I also use IMatch (DAM software). It has scripting capability. I would be interested to see whether there is scope for integration through the Services module (XMLRPC) to upload images straight from IMatch.

Great module anyway.

Cheers,
Marc.

I'm just sending encouragement to you for the upgrade.

(Sorry for the second message)

I'm just sending encouragement to you for the upgrade to D6.

I've been working with the Location module in D6. They have thought through the data structures quite nicely, and Location degrades gracefully if you only have some of the address information. Location can add geotags to a node or to a user, so it doesn't assume you have to be a node.

Applying similar attention to data structure and use cases for MAQUM would be good. For example, I use imagepicker for inserting a image into the text of a page, a situation where the writer needs immediate upload and storage in a personal folder of images. This would not be a good use of MAQUM because you want to keep it simple and stupid. You only need tags, geo location and other EXIF information if you are using an image as a node, which is far more complicated than posting a little image. Graceful degradation would be good, so if the image didn't have tags or the Drupal install didn't have tagging enabled things would work.

Also, it would be way cool if MAQUM had the ability to bulk load nodes from a folder on the server, so that a photographer could upload a set of images, and then auto create the corresponding nodes, complete with Imagecache thumbnails. Applying the same situation to a random website, you may want a folder of badges, or a folder of images for a slideshow, and it would be so nice to load in a new file or overwrite the folder and have Drupal pick up the new images/nodes automagically.

subscribing

Bump.
I'm doing a lot of complementary work in my own projects (sandbox code here - writeup happening slowly)
I can't even begin to look at crossover with MAQUM until there s a D6 version on the table.

Original related brainstorm with sun over here

If MAQUM which appears to originally have been a single-use client project is not to be extended, perhaps we can re-convene to talk about file metadata elsewhere?

don't know if you would be interested, but at least for IPTC metadata I have implemented an API which doesn't rely on any external tool

subscribing

i guess this will never happen :)

@pobster: maybe you should consider applying as mantainer for an abandoned project.

I think this issue should be opened (or at least marked as wont fix).