I am using the Media module mainly to add images to my content. I need also to add captions to those images. The idea of having custom fields – like in Content Types – it's very good but these fields are not visualized according to the settings in the Image media type settings page.
So far, I have found that this is related to a function named media_get_file_without_label() (called in media.filter.inc). So far, I am trying to replace this function call – on line 173 of media.filter.inc – with this different one:
field_attach_view('media', $media_obj, $media['view_mode'], null);
So this is not showing just the File field without label but all the fields in this object.
I am still missing some parts (for instance I would like to have this themed as an entity and not as separated ones per field and I also would like to have this custom fields in the editing window when I upload files using WYSIWYG…).
I will be glad to provide what I'm doing as patches but I would like to confirm that I am doing something usable…
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 1106444-showing_custom_fields-6-D7.patch | 5.38 KB | tomgf |
| #5 | 1106444-showing_custom_fields-4-D7.patch | 5.38 KB | tomgf |
| #2 | 1106444-2-D7.patch | 3.13 KB | tomgf |
| #1 | 1106444-showing_custom_fields-D7.patch | 1.46 KB | tomgf |
Comments
Comment #1
tomgf commentedAlright, I have worked a bit more on this. This is what I have done, so far:
With these changes, I have the possibility of showing / hiding the custom fields from the uploaded files.
Comment #2
tomgf commentedWith this new patch, the custom fields are shown on the embedding media form. The changes are on the media_media_format_form_prepare_alter function.
The missing parts:
I would be thankful is somebody could point me in the right direction here: I can not find which function is responding to the submit of this form…
Comment #3
skesslersubscribe.
Comment #4
bryancasler commentedsubscribe
Comment #5
tomgf commentedI have done another step: the custom fields are updated when submitting the form. It implies an special method because this form is just dumping json into the body editing field (not doing any server request).
What I did was to intercept this and call an extra function that is posting the form values to a new function –
function media_update_ajax()– that takes care of updating the fields.It has probably many glitches (and perhaps bad coding) but so far is solving my problem of editing the custom fields when adding the images. I'd be glad to hear some comments.
My next step will be to reflect this changes – custom fields, etc. – inside the WYSIWYG body…
Extra note: this patch was generated using the
--no-prefixoption, so it can be applied by usingpatch -p0 < name.patchComment #6
tomgf commentedI will document some of the process I am following. Perhaps this is useful to others.
admin/config/media/types) two extra fields:admin/config/media/types/manage/image/display/media_small)theme_media_filefunction, the output is themable), using a preprocess function to prepare the#markupand use these two fields –field_img_altandfield_img_title– as the image ALT and Title attributes:Note: the
spantags are created by the Styles module… Surely there is a better way of taking them off, but for the time being I just preg_replace-them.Finally, I attach here a new version of the patch (just a tiny difference as I have missed an space).
Comment #7
cartagena commentedThanks, tomgf! I do need this and will test it next week--after my site goes live. Still to much to do to get ti out by the deadline. After that I'll be back! Thanks again.
Comment #8
tomgf commentedYou're welcome, @cartagena. Check what I have posted in relation to stripping media tags before creating trimmed versions of the content: #1113088: Strip media before trimming summary.
I have to use that too in order to visualize my content the way I wanted to.
Comment #9
cartagena commentedThis is great! Not only have I had the same need, but I am happy to see how you built it. I'm not a programmer but I'm working to learn php and js. I can study your code and understand what it's doing and why. And maybe someday write a module (a very simple one!) myself and help someone else out! Thanks again!
Comment #10
emackn commentedthis seems to be more of a workaround then a fix.
One would think that the additional fields added to a media asset should appear on a content type that the asset is used in.
Comment #11
balintbrewsSubscribe.
Comment #12
sreynen commentedRegular expressions to parse already-rendered HTML isn't a real solution. That happens elsewhere in media, and it's a horrible mistake. Let's not repeat that.
What I did instead was attach the full parsed JSON object to the $media object in media_get_file_without_label(). To do that, I changed the end of media_token_to_markup() to this:
And then changed media_get_file_without_label() to this:
Then in whatever styles theme function is actually producing the HTML, $variables['instance']->object->json contains everything passed in the JSON.
Ideally $media->override would be more general purpose so we could keep all this data in one place, but that would require changes to everywhere it's used.
Comment #13
FrequenceBanane commentedsubscribe
Comment #14
kingjohnnet commentedsubscribe
Comment #15
bryancasler commentedsubscribe
Comment #16
yareckon commentedhi media module core folks... could you weigh in on the wisdom of this approach for allowing additional fields to be rendered as above?
Comment #17
abelb commentedsubscribe
Comment #18
betz commentedsubscribe
Comment #19
victoriachan commentedsubscribe
Comment #20
renat commentedSubscribe
Comment #21
arthurf commentedThis is a super important issue. The solution needs to handle fields on files which is something that the 2.x is starting to address. This issue http://drupal.org/node/1213252 has the start of making the fields on files editable. I'm closing this issue to focus discussion over there.