ONE field for Video, Images, Audio (Unified Media Field)

Absolutely! Unified media-field would be a great thing!
A unified media/embed CCK-field would be a significant usability improvement - the user could just enter the url/embed-code and happily list different media.
The current seperation of media-types with several distinct cck-fields is a way outdated concept and severely limits the benefit of this great module - and a unified interface is one of this module's goals, isn't it?!

i think this is a duplicate feature, but leaving open just in case it's not. postponing until after d6 version release at the earliest.

Please don't mark things as active when the maintainer of the module has marked it "postponed", unless of course you are willing to do the active development to make it happen.

Given all the work being done on file handling in Drupal 7 this is postponed until at least then...

Looking forward to checking out your patches!

This is definitely the way we're heading with this module, and we're going to start tying into filefield for the thumbnail functions, so we're working towards it, but it's still a long ways off.

Sean- I know you mean well with your offer, and I'm sure it's generous for what you can afford, but any developer who could do this would be insulted by your offer (since most charge that much for one hour of work and this will tens, if not hundreds, of hours of work).

if one were to go about doing this, it would probably be simply a module that provides its own field type, displayed as a text field, with all the emfield types and providers, and calls the correct elements from the respective modules as needed. i estimate 10s of hours, certainly not 100s.

a bonus might be to also provide a jquery switcher to integrate with filefield as well.

Subscribing --

Hello folks

Sponsored by Anexus IT I created a emfield generic

Attached could you check my patch created using the head in cvs repository or the complete emfield module in a zipped file.

Please check and give me any feedback or recommendations

Best regards

enzo

I think you could use the file field module for this.(http://drupal.org/project/filefield )Which adds a type called "file" in your CCK and in the configuration u can specify the extensions of file that the field should accept eg: jpg,wmv,mp3 etc
I think this could resolve your issue

wow, wow, wow! great job folks! i'm going to spend some time today reviewing this.

without having looked at the patch yet, i think it's still important to be able to allow admins to decide whether to allow video, images, audio as groups. not sure if doing that with the separate modules is the way to go, or whatever method you're using in the patch.

again, thanks for the hard work. i'll post any new thoughts after trying out the new functionality later today.

sorry i hadn't seen your message from last week asking for feedback. my dream ui would have something like a checkbox from the main admin screen that says something like 'Allow Video', that when checked, slides open a fieldset with allowable video providers, and slides it closed (or grays it out) when not checked. The same for audio and images.

if your patch doesn't do that, we can always add that in the future.

we could probably implement hook_elements and create a new form theme for that ui functionality.

one thought is that before removing the other modules, we'd also need to create an upgrade/migration path for folks. i have a feeling in either case we'll need to branch development into a version 2 of the module. i'm sure there are other improvements we can make along the way with such a drastic change.

also, i don't want to commit a d5 version until we've ported this patch to d6. it would get very messy for people upgrading otherwise.

Hello Aaron

In our approach, from emfield settings, the administrator decided what provider will be enable to use in each cck field,

For instance:
*If the administrator only enable 10 providers from 30 available

*When some user create a new emfield generic only will have 10 providers listed and again the creator or cck field only could select a subset like 4 providers from 10 available

*when someone will introduce and embed field only will be valid for four providers selected for this specific cck field.

Best regards

enzo

Oh, noes! Just saw that. HEAD is not for the d6 version, that's at DRUPAL-6--1. Sorry for the confusion. Hopefully the patch will still apply. And no, I'm not interested in backporting this; I'm hoping to close d5 from active development (unless someone else wants to backport it).

Thanks,
Aaron

The patch completely fails against the DRUPAL-6--1 branch. HEAD is the d5 branch. We'll have to diff the zip files to see what's different.

Hello Aaron

Could you provide the complete path in cvs, because I can't find to generate the correct path.

Best regards

enzo

The d6 dev branch is DRUPAL-6--1. The quickstart guide to CVS is at http://drupal.org/handbook/cvs/quickstart. You'll probably want to do something similar to

cd contributions/modules/emfield
cvs update -dP -r DRUPAL-6--1

If that doesn't help, it may be easier to grab the release package at http://drupal.org/node/265251, which is good up to November 20, the date of the last commit.

Hello guys

This is my new path

I create this patch downloading from cvs and with diff

diff -urpN emfield emfield_new > emfield.patch

Please check and let me know if it is working

Sponsored by Anexus IT

Best regards

enzo

Hello People

Today I update my cvs working copy to generate a new patch, just in case my last patch will be used with and oldest copy of dev, besides I replace the paths in patch in order to simplify the patching process.

Alex report a issue with configuration http://drupal.org/node/344581 Alex you could try again with any youtube video, or please provide me the code you use to test, maybe could an error in provider code

Please check the new patch.

Best regards

Sponsored by Anexus IT

enzo

Hey, great, -enzo- and Sean for the effort and the great idea!
Honestly, i ruled out emfield at first, but your work made it a good fit for my purpos - emfield_generic is really working well and is definitely the way emfield should be.
@aaron / Alex UA: Is this going to be commited in this way? Would be great if we could start using this now based on this patch and then just continue with it when the new official versions are ready...!

Wow, great, -enzo- and Sean! Thanks for the effort and the great idea!
Honestly, i ruled out emfield at first, but your work made it a good fit for my purpos - emfield_generic is really working well and is definitely the way emfield should be.
@aaron / Alex UA: Is this going to be commited in this way? Would be great if we could start using this now based on this patch and then just continue with it when the new official versions are ready...!

We're going to have to revisit this for version 2 of the module, which I'll be starting soon. The Media module is going to transform how files are stored and accessed, and third party providers will be accessed using PHP stream wrappers. Embedded Media Field will tap into that, and the idea of separating functionality between media types is going to be made obsolete. But I'm not sure of the particulars quite yet.

Hello aaron and danielnolde

Sound great. Just let me know if you need any clarification about my logic or maybe if you need help for few lines of code.

Best regards

enzo

thanks, -enzo-, for me, emfield_generic (using your latest emfield.zip) is working great and just as expected!
can't wait to see it CVS-committed to regular emfield.module!

yeah, i think media.module and emfield_generic have both sense and reason for existence.
emfield_generic is what emfield should really look like!
It's there, it works, so let's get it commited, .. or at least keep working to get it into emfield, right?!

Hello People

Well

This separation could be logic, because we could create three emfield_generic called field_audio, field_video and field_image and the editor of content will be careful about what kind of content past in each field, make sense?

aaron what do you think?

Best regards

enzo.

Actually, yes, Media Module will hijack a field and have it accept image, audio, video, pdf, whatever, and local & remote files to boot. Media sprint tomorrow; one of the tasks will be continuing integration w/ emfield, which will solve all of this once and for all.

The problem with the current generic field is that we still need to take care of the upgrade path. As version 2 of the module will be far superior to any current offering, I'm hesitant to put too much dev into something that will be obsolete in a month.

Hello aaron

One question, when you said Media you refer a new module or a new version of Embedded Medial Field?

Regards

enzo

Hey -enzo-!

Is there any info on what the furtue of emfield_generic will be? Will it be integrated/merged with emfield? Will it be a permanent fork? We use your emfield_generic a lot an wonder what way it will be taken in the near future, whether it will be maintained, updated, etc.
Would be great if emfield_generic would be included in emfield, it simplifies the end-user interface *tremendously*, and is for many use-cases way better than the heavy-weight media.module phantom.
Thanks for your great work and keep on rocking!

cheers,

daniel

Hello Daniel

Well Aaron the module maintainer said two post before, he will use part of the login in new releases, I guess Aaron is wait for Media Module release to choose a decision.

I loved you use this hack, I just implement the Sean's idea, but if more people think that could be a good a idea create a fork, could be consider.

Regards

enzo

Oh, please, let's not do a fork. The work to create a fork would be more than getting this patch suitable for release, and make things infinitely more difficult for users trying to decide how to go forward. Not to mention it would split existing efforts.

By far the largest problem with the patch as it stands is that it duplicates all the existing provider files, making literally twice as much work to maintain. To put it lightly, this is suboptimal.

Off hand, I can think of two ways to avoid doing this:

A) Scan the emfield contrib folder for provider files to include.
B) Require that at least one of emvideo/emimage/emaudio is turned on, and poll those modules for provider files to include.

Option B would be, IMHO, the better solution, as it would also automatically grab any provider files maintained outside emfield, such as at http://drupal.org/project/media_brightcove or http://drupal.org/project/media_8tracks. This also would allow us to continue the ongoing solution of moving provider files outside of the main project for better ongoing maintenance.

Option B would also make the new module more future-proof, as it would be better inline to receive the benefits of future Media development.

I'm postponing this (indefinitely): Media module is just about there for Drupal 7, and will be backported to D6 at some point. That will handle this and so, so much more!

Marking as "Wont fix" since Media Module is the way to make this happen.