There were a few issue with the current widget that were road blocks on our project and things seemed to be in flux with current widget so we set put to build a new one aimed at using views as browsers and with a way to edit meta data of the media.

I have a working (if buggy) module on git hub.
https://github.com/phase2/media_views_widget
git://github.com/phase2/media_views_widget.git

It provides the media field with

  • a preview of the media,
  • a select button (which opens the views browser, and an upload new tab)
  • a meta data button (which opens a dialog to edit the meta data of the image
  • and a remove button which removes the current media from the field

there are some known bugs with the current code

  • issue with multiple item fields
  • ajax exposed filter on views does not work on first page

The field is built with each of the buttons set to an ajax call and refresh the field, there is also an empty div that is sent along. This div becomes the dialog on the insert and meta data button calls.

I am hoping this could be incorporated as a alternative widget to the main media widget

Files: 
CommentFileSizeAuthor
#107 media-editing_metadata-1213252-107.patch4.2 KByuriy.babenko
#103 media-editing_metadata-1213252-103.patch6.89 KByuriy.babenko
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch media-editing_metadata-1213252-103.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#85 ctools_dependency-1213252-85.patch319 bytestsvenson
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#80 1213252-media-edit-modal.patch11.35 KBDave Reid
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#78 screenshot.PNG108.29 KBjerryitt
#72 1213252-media-edit-modal.patch10.98 KBDave Reid
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1213252-media-edit-modal.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#59 1213252_media_edit_button.patch9.71 KBbennetteson
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#51 1213252_media_edit_button.patch9.61 KBbennetteson
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#38 media_edit_fields.zip2.72 KBpaulbeaney

Comments

subscribe

Cool i was planning the same thing. Its not working for me at all. I have multiple views on the page ... Is it possible to include a default view?

@webflo, I will add a default view today, but any view bases on files should work.

Ok I had a default view to the in the github repo. as the default view displays the preview view mode of the file the following module is also need for it to work

https://github.com/phase2/views_file_row
git://github.com/phase2/views_file_row.git

I get some php notices after clicking the upload button and the form disappears.

No file appears to have been selected.
Notice: Undefined index: file in media_views_widget_mvw_update_from_dialog_callback() (line 72 of /Users/fweber/Sites/media.dev/sites/all/modules/contrib/media_views_widget/media_views_widget.module).
Notice: Undefined index: fid in media_views_widget_mvw_update_from_dialog_callback() (line 74 of /Users/fweber/Sites/media.dev/sites/all/modules/contrib/media_views_widget/media_views_widget.module).
Notice: Undefined index: #dialog_inner in media_views_widget_mvw_update_from_dialog_callback() (line 75 of /Users/fweber/Sites/media.dev/sites/all/modules/contrib/media_views_widget/media_views_widget.module).

I use media-7.x-1.x dev (7481b9e)

subscribe

@webflo,

so I can not duplicate, do you know if a js error happening at all?

Looks like the fid field might not be getting populated

Patch the bug that did made multi item fields wonkie patch is committed to github

Sub. btw frank I sent this to Alex and James, hopefully they will look at it sometime soon.

subscribe

Subscribe

Note that https://github.com/phase2/media_views_widget only works for media fields and needs to be adapted to work with file and image fields since we are deprecating the media field type.

@Dave

I will make the changes do you know if there were any gotchas it to which i might run?

It would be good if the solution could be provided as a patch to review against the current 7.x-2.x of Media / 7.x-1.x of File entity rather than a github module. It makes the code much harder to review.

Version:7.x-1.x-dev» 7.x-2.x-dev

this disables the field media select button.

@aaron: The code linked to in #15 or the original code link?

in #15

additionally, with #15, the remove media button doesn't appear w/ existing content.

Hrm, we're using it on a site currently with 7.x-2.x and it's working fine. I'll re-check.

my bad, sorry about that. i forgot to change the 'custom.media.js' to the new filename...

#15 works great, thanks!

Thanks dave #15 solves the edit media problem but still requires adding it originally and then going back to include the fields for the entity.

Is the eventual plan to multistep the "add media" modal via ctools so that this additional field data can all be input in 1 fell swoop. IIRC need to multistep to react to the type of media added in media_upload and display the necessary fields.

If you leverage the ctools multistep form wizard you could even reuse the form states between the two parts.

Work perfectly for me !
You saved the day !

Title:New media field widget that supports views browserAllow media file's fields to be edited in a modal or after upload in the media widget

Re-purposing to limit to just the 'Edit media' functionality.

Awesome!thanks Dave!

Sub

subscribe--thanks for all the work on this!

Priority:Normal» Major

Marked #1062304: Fill in the available fields when creating media in the WYSIWYG a duplicate. Upping this issue to major.

Sub

sub

subscribe

subscribe

Here's a simpler proof of concept than #15: https://gist.github.com/1263299.

#15 uses CTools modals, and that may be a better way to go, especially if the rest of the Media browser is updated to that. However, https://gist.github.com/1263299 might be educational for someone wanting something quick and dirty to extend into a custom solution.

Once we settle how we really want to structure the Media browser code in 2.x, we'll want to get a robust solution to this issue into the Media module. In the meantime, feel free to use or improve the submitted examples, but keep in mind that Media 2.x is still in its unstable phase, which means future updates may cause such examples to break.

#35 works really well for me - thanks effulgentsia! I have added a bit of CSS to make the intermediate edit form look more similar to the other Media windows and it integrates well.

The only issue I have now is how to resize the iFrame of the media edit form automatically depending on how many fields are in the bundle, and any error or information messages etc. I have a feeling this ought to be trivial with a behaviour setting attached to the form, but I'm a relative novice on the javascript side of Drupal, so if anyone can provide any pointers that would be much appreciated.

Regards,

- Paul

@paulbeaney, can you share your CSS?

Cheers,

David

StatusFileSize
new2.72 KB

@davidseth I'll go one better - here's the complete module. I've added a couple of extra fields on the final form before inserting the image as I am looking for a functionality as close as possible to Imagefield Assist, but they can be left out (just delete the function media_edit_fields_media_format_form_prepare_alter())

Regards,

- Paul

@paulbeaney, this is great! Thanks. Nice work.

I am not getting anything from the media_edit_fields_media_format_form_prepare_alter() function though... I can see there are things related to captions and floating, but nothing shows up.

Cheers,

David

Hi David,

Have you flushed your caches? That's the only thing I can think of.

Regards,

- Paul

sub

sub

@paulbeaney nice contribution ! To make it works I had to change line 58:
$form_state['redirect'] = array('media/' . $fid . '/edit', array('query' => array('render' => 'media-popup')));

media instead of file as path.

Otherwise the popup is not resizing in my setup, without any js errors.

Thanks Paul !

sub

sylvain,

for version 1.x you have to change the path on line 58:

  $form_state['redirect'] = array('media/' . $fid . '/edit', array('query' => array('render' => 'media-popup')));

and the function on line 64 :

function media_edit_fields_form_media_edit_alter(&$form, &$form_state) {

subscribing

@harrrrrrr thank you, it works like a charm now !

Nice, this is great. #38 is working nicely! :-)

effulgentsia: Once we settle how we really want to structure the Media browser code in 2.x, we'll want to get a robust solution to this issue into the Media module.

Are there any specific issues that we can follow/help out with to move this along?

I'm using media 1.x with the media_edit_fields module from #38 and the adjustments from #45.
These are the results:

  1. in wysiwyg selecting an existing image; after submit a form appears with alt, title and alignment; after second submit only title appears in the resulting HTML code.
  2. in wysiwyg adding a new image; after submit a (non-fitting) form appears with no fields and "Please complete this form as fully as possible to ensure that the image is correctly categorised for future use."; after second submit a form appears with alt, title and alignment; after third submit only title appears in the resulting HTML code.
  3. in a separate image field selecting an existing image; after submit no form appears; no alt or title appear in the resulting HTML code
  4. in a separate image field adding a new image; after submit a (non-fitting) form appears with no fields and "Please complete this form as fully as possible to ensure that the image is correctly categorised for future use."; after second submit no new form appears; no alt or title appear in the resulting HTML code

Subscribe

Status:Active» Needs work
StatusFileSize
new9.61 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

Here my contribution :
Add a Edit media button but still a draft.

Only for Media 7.x-2.x

Subscribe

@bennetteson - Tried your patch, and the "Edit media" button works great. The "Select media" work as expected. I did have some strange problems with the "Remove media" button.

When clicking the "Remove media" it removes the file from the imagefield and DELETES the file from the file system.

I was just expecting it to remove the file from the imagefield.

Thanks for sharing,
-Glenn

@bennetteson - I removed your patch and noticed that I still had the problem with the "Remove Media" button deleting the file. Is this how the media module works by default? I need to check the issue queue.

Status:Needs review» Needs work

For the record... There is already an issue already about the "Remove media" link deleting the file.

see #1239056: Remove Media at content edit page cause the file to be completely deleted from server/database?

Status:Needs work» Needs review

I've applied the patch and found the mechanics work well. There are some issues with the modal in Rubik but I think that's a general issue rather than anything related to this patch. Here's a few screenshots: http://skit.ch/b9fb, http://skit.ch/b9fn.

Status:Needs review» Needs work

I would really like this change to help bring in some of the render improvements of separating out each 'button' like in https://gist.github.com/1124045#file_custom.module - especially since we need to add an access check on the edit button since we shouldn't show it for people that don't have access to edit files.

StatusFileSize
new9.71 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

@Dave Reid
Fixed

Status:Needs work» Needs review

Nope that's not really at all what I meant. I'll try to re-roll with the changes in the github gist.

Status:Needs work» Needs review

@dave_reid recommended this bit of code in #drupal-media for this purpose

https://gist.github.com/1124045

Josh

#59: 1213252_media_edit_button.patch queued for re-testing.

The custom module in #62 works great. Will this remain as a custom module or will it be integrated into the media module?

Status:Needs review» Needs work

Patch in #59 applies clean on current dev. Gladly it also works with the #1210432: File title is uneditable patch for File Entity so it is possible to rename the title (not the file name of the physical file) as well.

However, I found three things with it:

  1. The overlay window when clicking Edit is not looking very nice, its very big and form objects only take up a small amount in the top left.
  2. When applying the #1210432: File title is uneditable patch, the file name under the preview on the edit page is not updated after I have saved the edit. It is updated though, just click the Edit tab for the node and it will change when reloaded.
  3. There is no Cancel button, only Save and Delete

Great start though, many thanks.

Edit: added 3rd point above

Sounds really good.

edit: sorry, just read Stop subscribing, start following

Applied the patch in #59 and I get a blank page when I click "Edit media". Had to apply the patch by hand, so I checked it a second time. Can anyone confirm/reject this problem?

http://www.diigo.com/item/image/1ks4o/oqks?size=o

The good news is that the module from #58 works well enough for now.

Assigned:Unassigned» Dave Reid

Yeah I'm not at all happy with our custom code to edit the file in a modal so I'm definitely going with a CTools modal solution like in #58. Merging in today.

Also merging #1277086: no javascript "change" event triggered after media is selected into with this ticket since it's a good change for media.js to have to support this.

Dave, should I open up another issue que about supporting editing of a media file via the WYSIWYG plugin or does that belong here?

Status:Needs work» Needs review
StatusFileSize
new10.98 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1213252-media-edit-modal.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Complete patch ready for testing. You will need the latest dev/git from CTools and File entity.

Summary of the patch:

  • Gets rid of the hacky storing fid in a hidden text field and uses a proper hidden FAPI field.
  • Adds a CTools modal callback at media/%file/edit/%ctools_js which is basically a wrapper for file/%file/edit
  • Splits up the media widget into distinct preview/select/edit/delete render arrays so that we can just natively put an #access on $element['edit'].
  • Alters the file_entity_edit form when loaded in a modal to remove the file preview, remove the delete button, and change the cancel link so that it will trigger a modal close.
  • Changes the media.js to be even cleaner with its events, also triggering proper changes for the hidden fid field (#1277086: no javascript "change" event triggered after media is selected)

Followups:

Any screenshots of this feature?

Some screenshots:

Added 'prettify edit modal' as a follow-up task. I'd just like to get this in if we can live with the default styling of the CTools modal for now.

looks great and gonna give patch a go and report back. Does this mean the widget approach is completely dropped ? Would be handy for published or promote like checkboxes to be available in the widget itself (like on content/file/edit-multiple), so you can edit multiple images at once. Just thinking out loud here, there could e.g. be an option in your field settings where you can select what file_entity fields to integrate in the widget (where the modal would be the default).

Yes, trying to edit the fields in the widget itself has proven too problematic to implement so far, so this is the preferred option forward.

Patch works fine here (edited the name and a custom tag field I have associated).

As for 'multi edit', another option could be to have an extra 'edit multiple" button below the widget (next to add another item), which then calls 'admin/content/file/edit-multiple/%media_multi' ?

StatusFileSize
new108.29 KB

Im getting an error when i do the following.
Create new content, select add media and choose an image from the library. Then click edit and i get the below error. However if i save the node and then go back and edit it it works fine..

An AJAX HTTP error occurred.
HTTP Result Code: 404
Debugging information follows.
Path: /media/media/0/edit/ajax
StatusText: Not Found
ResponseText:
Page not found | media
@import url("http://localhost/media/modules/system/system.base.css?lyf8m0");
@import url("http://localhost/media/modules/system/system.menus.css?lyf8m0");
@import url("http://localhost/media/modules/system/system.messages.css?lyf8m0");
@import url("http://localhost/media/modules/system/system.theme.css?lyf8m0");
@import url("http://localhost/media/modules/system/system.admin.css?lyf8m0");
@import url("http://localhost/media/modules/comment/comment.css?lyf8m0");
@import url("http://localhost/media/modules/field/theme/field.css?lyf8m0");
@import url("http://localhost/media/modules/node/node.css?lyf8m0");
@import url("http://localhost/media/modules/search/search.css?lyf8m0");
@import url("http://localhost/media/modules/user/user.css?lyf8m0");
@import url("http://localhost/media/sites/all/modules/views/css/views.css?lyf8m0");
@import url("http://localhost/media/sites/all/modules/ctools/css/ctools.css?lyf8m0");
@import url("http://localhost/media/modules/shortcut/shortcut.css?lyf8m0");
@import url("http://localhost/media/modules/toolbar/toolbar.css?lyf8m0");
@import url("http://localhost/media/themes/seven/reset.css?lyf8m0");
@import url("http://localhost/media/themes/seven/style.css?lyf8m0");
Skip to main content
Home
Hello admin
Log out
Administrative toolbarDashboard (View and customize your dashboard.)
Content (Administer content and comments.)
Structure (Administer blocks, content types, menus, etc.)
Appearance (Select and configure your themes.)
People (Manage user accounts, roles, and permissions.)
Modules (Extend site functionality.)
Configuration (Administer settings.)
Reports (View reports, updates, and errors.)
Help (Reference for usage, configuration, and modules.)
Hide shortcuts
Edit shortcuts
Page not found
The requested page "/media/media/0/edit/ajax" could not be found.

@HnLn: That's still going to require some non-trivial changes to the widget, so if you'd really like to see it happen, let's file that as a separate feature request.

StatusFileSize
new11.35 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

Revised patch that should fix the 'select a new file and then edit' bug.

Status:Needs review» Reviewed & tested by the community

Applied and tested on latest git pull for Media and works as promised.

Would of course be nice to also have a preview of the file showing, but that's another issue.

Status:Reviewed & tested by the community» Needs review

patch #80 fixes the select a new file and then edit bug seen in http://drupal.org/node/1213252#comment-5519512

Status:Needs review» Fixed

Excellent, pushed #80 to 7.x-2.x (http://drupalcode.org/project/media.git/commit/46a86d6)! Thank you so much to everyone's help and contributions on this issue!

Reminder that this requires the latest Git pull or dev of both File entity and CTools and a good cache clear via update.php.

Thanks for the screens. Looks good. When we can add our own fields using "file types" we will have "Media Heaven" for Drupal.

Keep up the good work.

Status:Fixed» Needs review
StatusFileSize
new319 bytes
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

@Dave Reid: I believe we need to add a dependency on ctools since we now uses its modal, or is that taken care of automatically by Views?

Anyways, here is my complex patch for it.

Both File entity and Views depend on CTools so we don't need to declare a dependency although it might be good just to list it.

FYI jerryitt and I identified a bug where the regex in media.js was too greedy if you happened to have Drupal installed in a sub-directory called 'media'. A fix was committed with http://drupalcode.org/project/media.git/commit/77f116a

Seems like the <label class="media-filename"> value is not updated when the filename is changed. (or is it expected that it keeps the filesystem-based value ?)
[ the file_entity API uses file_save() and does not rename the files on the filesystem ]

@drzraf: File name is not at all tied to the actual file name in the file system, but just the record in the database. See the follow-ups in #72.

Dave - Not sure if this is what you were referring to earlier but when I "Edit" a file and change the name, it does not change the name of the file on the filesystem. I checked #72 and didn't find any reference to this.

Isn't this expected behavior? I can't imagine leaving this functionality up to another module (such as FileField Paths). Please advise :)

Great work everyone!

See #89. This is expected behavior.

@Dave: sorry I overlooked a reference there
@bensnyder: the widget update issue is #1418124: The field widget preview of a file should update after the 'Edit media' modal is saved/closed (see comment #72)
@bensnyder: the filesystem is not touched, it's a [IHMO discutable] choice of the file_entity people, see #1210432: File title is uneditable (especially comment 4).

Had to add in a little temporary CSS to make the modal manageable for the time being.

div.ctools-modal-content fieldset{clear:none;}
div.ctools-modal-content .form-item label{width:100%;}
div.ctools-modal-content .resizable-textarea{width:auto; margin:0;}

When I click the edit media button and the modal is loaded, styles from the administrative theme (seven in my case) get loaded and mess up the styling of the node edit page behind the modal frame.

My guess is that this happens because the modal is not an iframe (right?); and I would therefore expect it to not load any additional styles, or only media-specific ones if necessary...

Not sure whether that's an issue with this patch or ctools.

Outside the fact that reinventing the wheel with jQuery pseudo-popup is a major failure (my window manager does its job pretty well thus I don't need jQuery workarounds that window$ users need), I think that the overflow: hidden CSS properties must be removed from media.css.
It already encountered quite a few times the case where the cancel/submit buttons are hidden because they overflowed.
You can reproduce this when using the view library with non-square thumbnails, then you'll get the cancel/submit button pushed below to an inaccessible place.
That very annoying when your good old scrollbar is hidden too.

It may be also be solved by overriding the core .item-list .pager clear: both property, but hidding the overflow is almost always a bad choice, especially when the box may contains controls.

@drzraf: I don't see how that is related to the 'Edit media' CTools modal?

now I realize that I was talking about the "media browser" modal, sorry

Can someone please let me know where do i need to add the code in #15 in Media module.

@andhgeek: You don't want the patch in #15, its really old. The patch in #80 got committed Jan 27th as per #83 and a second got committed as per #87. Both are available in the current 2.x-dev version.

@Dave Reid: Probably a good ide to close this issue and open new follow up(s) if needed. Already two patches has been committed here and makes it dificult to keep track on what has happened and what is going on.

(re #94) @bforchhammer This is because the media module defined media/*/edit/* as an administrative path (see media_admin_paths()).

You can override by implementing hook_admin_paths_alter() in a custom module:

<?php
/**
* Implements hook_admin_paths_alter().
*/
function mymodule_admin_paths_alter(&$paths) {
 
// Don't treat as admin path otherwise admin theme loads when modal appears.
 
$paths['media/*/edit/*'] = FALSE;
}
?>

Thanks bsuttis, that solved problem #94 for me! :-)

Should this be changed in media_admin_paths()?

That's a good question, I realized later that when on node/*/edit a similar issue occurred (but reversed this time, site default CSS loaded on top of admin CSS).

I'd say the above fix works if you use one theme for admin/site default however it'll cause issues otherwise.

My solution to get around the node/*/edit issue and still use an admin theme for other /admin pages was to add $paths['node/*/edit'] = FALSE; to the hook as well so that editing a node will use the site's default theme.

StatusFileSize
new6.89 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch media-editing_metadata-1213252-103.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Hey Everyone,

As we all know, there was a bit of code in place within the Media module to have an "edit media" button, but it was commented out. I built upon this functionality to get that media editing up to speed.

Fixed numerous issues:
- modal which showed up upon clicking the edit link was incorrectly redirecting to another page
- the edit file form that was presented in the modal was incorrectly ending up on the site's homepage after submission
- there was no confirmation message after submitting a form (along the lines of "Node abc has been updated.")

Screenshots:
- http://i.imgur.com/dQ0Kr.png
- http://i.imgur.com/FK6Qw.png

Known limitations:
- The 'Cancel' button within the modal does not work - gave this a shot, but didn't get it working and can't spend much more time on this right now. It would be great if someone could figure this out. For the time being, hit ESC to close the modal.

The attached patch was built against 7.x-2.0-unstable3 (2012-Jan-12);

Status:Needs review» Needs work

The last submitted patch, media-editing_metadata-1213252-103.patch, failed testing.

Status:Needs work» Closed (fixed)

Ok I think we finally need to mark this issue as closed. Please file new issues for anything that is a follow-up to this.

StatusFileSize
new4.2 KB

Adding a patch (requires the patch in #103 to be applied first) which adds working 'close' button for the metadata modal. Not an ideal solution, but it works.

@yuriy.babenko: considering that this issue has been marked as fixed and closed, you should probably open up a new issue for your patch.

so, is this patch going to get commited to the 1.x branch? due to the lack of a full release on the 2.x branch im still using 1.x for production sites and really need this feature. The patch in #80 applied with a little bit of work on the current release but it would be nice to not have to maintain patches once projects are passed on to clients to maintain.

+1 for this feature in 1.x that would be awesome.

I new to Drupal and need this functionality badly. I'm using the stabel version 7.x-1.3 but I cant get this going. I have installed the module mentioned in post #38. I made the modifications mentioned in #45. This enabled the popup but I received an error.

Notice: Undefined index: file in media_edit_fields_form_media_edit_alter() (line 86 of sites/all/modules/media_edit_fields/media_edit_fields.module). =>
and
Called from sites/all/modules/media_edit_fields/media_edit_fields.module, line 86

The popup still contains the field but when I have filled in the value and hit submit I get these errors

Called from sites/all/modules/media_edit_fields/media_edit_fields.module, line 86
Notice: Trying to get property of non-object in media_edit_fields_form_media_edit_alter() (line 86 of sites/all/modules/media_edit_fields/media_edit_fields.module). =>
... (Array, 9 elements)
Krumo version 0.2.1a | http://krumo.sourceforge.net Called from sites/all/modules/media_edit_fields/media_edit_fields.module, line 86
Notice: Undefined index: file in media_edit_submit() (line 366 of sites/all/modules/media/includes/media.pages.inc). =>
... (Array, 9 elements)
Krumo version 0.2.1a | http://krumo.sourceforge.net Called from sites/all/modules/media/includes/media.pages.inc, line 366
Error
Error messageEntityMalformedException: Missing bundle property on entity of type file. in entity_extract_ids() (line 7633 of /includes/common.inc).
The website encountered an unexpected error. Please try again later.

The file is not saved.

Hopefully someone can help me.

Issue summary:View changes

Can this functionality work in Media gallery module as well?