rules integration

That would be very neat indeed!

If that works well it could replace the current interface on the field settings pages. The reasons for the way the module is currently designed is that I wanted it to be possible to disable the module and not lose any data – in other words, I didn't want to use any custom DB tables and such. Your approach would fulfil this goal too.

There is just one problem: how would you provide a developer/user friendly way of having snapshot images link to the right video files? In other words, how would the different CCK fields be linked to each other on the presentation side? One way would be to generate formatters like "{imagefield} image linked to {filefield} file" or "{filefield} video player with {imagefield} snapshot".

In the meantime, any kind of Rules support would be great!

+1

That would be awesome :)

@bangpound, are you talking about replacing FFmpeg Converter's field/nodeapi logic with Rules configuration (as proposed by venkatd)? Or are you thinking more of Rules as an added possibility for converting files?

+1

+1

Tagging and subscribing.

Just a quick update:

Rules support is in the works. The idea is to remove this module's settings on the filefield configuration form, and instead use Rules configurations to associate filefields with conversion presets, much like venkatd's description above.

Good idea, thanks

I've opened up a 6.x-2.x branch where the Rules support will live, along with exportable presets etc.

I've worked on this since a few months back together with henrrrik and a couple of computer science students who have done some dramatic changes to the module. I've taken their code and done some additional modifications.

Attached is a gigant patch which the following changes:

• New Rules action: ffmpeg_converter_action_queue_filefield
• New storage scheme: we now use one file field for each format/conversion preset. It should also be possible to have multiple instances of these fields. Everything is standard file fields. No more, no less.
• Removed integration with node form and node type form etc.
• Removed all node/field theming code.
• Removed the snapshot image generation. The idea is that snapshot generation should be like any other conversion job, and you should be able to add presets and rules for this yourself.
• Removed some other legacy code.

What's left to do:

• Deal with existing files in output fields. One idea is to check modification dates on the converted files and only overwrite them if they are older than the original. Also, if the existing file has a different name altogether it probably means we shouldn't overwrite them.
• Test different use cases and look for things that we haven't thought of.
• Invoke hooks for other modules to alter the conversion process?
• Rewrite help texts and the README file.
• Provide a way to migrate existing content to the new storage structure.

The patch is not completely tested in its current form.

Here's a new version of the patch by markusbroman, Kleve, henrrrik and myself.

• Fixed a problem with nodes being re-added to the queue after the conversion of a file.
• Added a check for existing files in the destination field. For now, we don't overwrite any files. Users are expected to delete files in the destination field themselves. This is to avoid unintended data loss. A possible improvement would be an option to override this.

New issue:

• Only show the "existing destination file" warning if the source file is newly added, i.e. if it hasn't been processed before. One way of dealing with this is to compare the creation dates of the source and destination files.

I'm considering committing this patch and creating separate issues for the remaining stuff.

Committed. Thanks markusbroman and Kleve for doing the dirty work, and henrrrik for supporting them!

I'll add new issues for the remaining stuff.