Wonderful module. Thank you.

Unfortunately, and as often happens, I get to do everything I need except that "one last thing" that breaks the deal, though in this case I know there has got to be a solution somewhere...

How do you exactly "link" the converted file to the node that created it?

We got CCK working with MM and converting files, but after it is done all we get is the original file attached to the node, no the converted one. Not matter where I look I cannot seem to find the answer to this. the mm_node module "appears" to be an option, but works only via Upload module which I am pretty sure it is not good to out our case...

We have Sound Content type with a single CCK field that uses the "file" type with the only widget option available which is the "file upload". IN our configuration we harvest that file via the CCK's upload widget, (user selects file, hits upload) , then when the user hits "save" MM kicks in, converts it, bypasses the storage process (set that way by us) and copies the audio file to new directory we set up for converted files in the "complete" process.

We must use CCK and we do not want to use the default upload/attachement, (mm_node) which in its current state is spitting out the always dreaded "invalid argument...For each[]" type error. At this point we can't tell if going the mm_node + upload route is even the way to go because we can;t tell if the module is working properly.

I hope that makes any sense. Anyone has any info on this?

I looked a that video floating around but this subject was not talked about (Directory conversions, FTP, MTP, etc. but no CCK example). I can see that we can pass the "data to another CCK" field. They way I understand this is that once converted

Thanks in advanced and I hope someone can throw us a bone over here. We are dying slowly but surely.

LL

Comments

arthurf’s picture

arthurf commented

So just to clarify, the issue with the CCK field save is that it's attaching the original file, not the converted one?

celston’s picture

celston commented

I might be missing the gist but I believe what you want to do is set up a second CCK filefield field and set your MM configuration to store the converted file there. Correct?

3rdLOF’s picture

3rdLOF commented

arthurf: yes sir. Correct. When the user hits "upload" the original file gets added to the CCK field itself because the conversion does not happen until the user hits "save" not when the user hits "upload" in the CCK file field widget...MM does not harvest the file until the node (content) is saved.

celston: Based on what I just said on my prior paragraph, that is the nut of the problem: Upon hitting save, then the conversion happens, so there is no "CCK field" to save data to (the form is gone, the db is executed). In addition to that, if you had to add a second filed, that field would have to be another CCK fiel field, with now means you got two "Choose File / Upload" widgets...To avoid errors by the average user now you have to build logic in those two fields to make sure the user does not accidentally use the wrong widget...etc, etc...

The way I thought ( and I think it was meant to worK) was that the user picks the file, hits "upload" THEN the conversion happens, resulting from the converted file being attached (shown) in the CCK field itself. That would appear to be the most UI-logical usage.

Thanks for your replies.

LL

mark trapp’s picture

mark trapp
he/him
Primary language English
commented

kannary,

I had a similar issue, and was able to get around it via the use of two CCK fields and the content_permissions module. The first CCK field is user-facing: it accepts an upload on the node-form, and will act as the harvest field. The second CCK field will save the converted data, but will not show up on the node form. Using the content_permissions module, I set the permissions on the second CCK field to be uneditable (thus removing it from the node form), but viewable (thus showing up on the completed node) by the appropriate roles.

This doesn't get around the problem of running MM on save (I wasn't able to overcome that, so instead, I run it via cron and notify on the node that the file is being processed/converted), but it should get around any UX issues for the end user.

3rdLOF’s picture

3rdLOF commented

Amorfati; I appreciate the info, though I am not quite sure... That would be excellent if the hidden CCK gets filled by the converted file, but if it is not...then what is exactly that "hidden" CCK field getting? All I would be doing with that would be simply filling up the hidden CCK with the same original file from the first one.

Man, dying over here with this...It seems so simple.

arthurf’s picture

arthurf commented

Well part of the issue is that use of CCK fields doesn't replace an existing value, it adds a new entry onto the field. So the trick would be to have an option in the CCK module to replace the existing file path rather than to append it. The problem here is that for non-local files (eg: S3) file/imagefield may expect to beable to do operations on these files.

If there is interest, I can write a replacement option for the CCK module, but it will be in the user beware category.

arthurf’s picture

arthurf commented

I wrote some test code that will allows you to configure a CCK storage action to replace an existing file. This will only work if you harvest from the same CCK field. Note that I also updated the FFmpeg module to add the file meta data into the $file array so the new file size, mime, and path info are all saved.

Please go ahead and test it- I haven't had a chance to myself, but I think the code should be ok

3rdLOF’s picture

3rdLOF commented

arthurf: Thanks for your effort. I am assuming this improvement/fix is part of the current dev version of May 9th. If not, then none of the staff below is to be taken into account.

I installed the MM dev version and saw the new settings, but unfortunately - and unless my settings are wrong - this did nothing at all. The same issue remains.

I tried this with one and two cck fields.

I removed all prior configurations and started from scratch,

--------

With one CCK file field (upload widget)

A)Harvest

Field: Sound File CCK
File Types: aif wav mp3 au

B) Process

Output Format: mp3
Audio Conversion: 32k / 44.1 k / Use Default

C) Storage

Save the file to CCK field: Sound File CCK (Same as where it was harvested from) (Note: I notice when I go to edit the config this drop down menu is always selected incorrectly. When I set it right and save, return to edit, it is back to the wrong selection)

D) Complete

Save to local directory; I set path properly.

With this configuration I go an create a sound. When I do, on the CCK field I select a sound file (AIF for example). I then hit "upload" and the widget does its thing and attached the original file into itself. No Conversion. Fill rest of form, submit and there is no change. Only the original AIF is shown in the node.

I also tried this by selecting this file and saving without hitting "upload" in the widget..I get a PHP fatal error:

Fatal error: Cannot access empty property in /var/www/html/core/sites/all/modules/media_mover/mm_cck/mm_cck.module on line 232

--------

With two CCK file fields (upload widget). I left the second one visible so I could see. I assume leaving the field visible or not makes no difference.

A)Harvest

Field: Sound File CCK (1st field)
File Types: aif wav mp3 au

B) Process

Output Format: mp3
Audio Conversion: 32k / 44.1 k / Use Default

C) Storage

Save the file to 2nd CCK field: Converted Sound File CCK .(second field)

D) Complete

Save to local directory; I set path properly.

With this configuration I go an create a sound. When I hit the "upload" in the first CCk field the original file gets attached to the first Sound Field (itself). Nothing happens to the second CCK field, no converted file is attached. Trying to save this gives me an site error message telling me I need to fill the second CCK file field, which is more than confirmation nothing is attached to it.

So unless I am missing something or there is some other "unrelated-yet-important" issue such as:

A) is there any connection between MM and when a content type field is created? That is, these fields were created before I installed MM. I noticed in Drupal sometimes some ppl get errors when trying out modules because similar situations that have to do with missing new parameters or DB entries.

B) Should I uninstall and install MM again/ Would that make any difference?

I wish I could help to help myself out of his one.

Thanks

LL

Anonymous’s picture

Anonymous (not verified) commented

I am having similar problems on the D6 version although I haven't tried out the latest dev release. My desired process is as follows:

1. Audio file gets uploaded using the CCK filefield widget by User.
2. Node gets saved by User.
3. File gets harvested by Media Mover.
4. File gets transferred to an Amazon S3 bucket by Media Mover.
5. File gets "re-attached" to the CCK filefield widget by Media Mover

All steps but #5 are working properly. My ideal solution would be to have the original file link replaced with the link to the file on S3.

Rob Safuto
Awakened Voice

arthurf’s picture

arthurf commented
Title: CCK + Media Mover = File to Node » CCK + Media Mover = File to Node with S3
Status: Active » Needs review

This ended up being vastly more complicated than it should have been. The issue is with how drupal (filefield) handles non local files (it doesn't). To get around this, I've had to use a phptemplate function to check the displayed file against media mover's file database to see if we can load a file up. This is ugly, but it works. I'm not sure how it will work with views, but this is a first cut.

Also, this has many revisions to the core API to make it easier to check and handle file status. Ultimately, I don't like these changes and what I've already done for 6-2x is much better from my perspective. At anyrate, please give this a try and let me know what you think.

a.