Code:

/**
 * Used to Implement hook_field_view_modes().
 */
function media_field_view_modes($obj_type) {
  $modes = array();
  if ($obj_type == 'media') {
    $modes = array(
      'media_link' => array('label' => t('Link')),
      'media_preview' => array('label' => t('Preview')),
      'media_small' => array('label' => t('Small')),
      'media_large' => array('label' => t('Large')),
      'media_original' => array('label' => t('Original')),
    );
  }
  return $modes;
}

As you can see in the code the view modes are predifined and not extendable. At th emoment I have most of the view modes in use to display some kind of image style (scaled). However I want to use a certain frontpage preset for a view for a carousel in the frontpage. At the moment the view does only show the formatters from this function. How is it possible to add the frontpage scale preset?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

R.Muilwijk’s picture

FileSize
17.92 KB
Peter Törnstrand’s picture

subscribe

rvilar’s picture

subscribing

losco’s picture

subscribing

Iztok’s picture

Was asking my self the same question... sub.

rnyberg’s picture

sub, this is quite important :)

Also for me, selecting Small does not yield in anything showing up.

slashrsm’s picture

subscribe

slashrsm’s picture

I did a bit of research... It seems that media module cannot return any other view mode than it's owns. If media module would load info about it's view modes, provided by other modules, it would probbably call entity_get_info() to get this data. The problem is, that this function starts to collect data about all availible view modes in the system. That sooner or later means call to media_field_formatter_info(), which than calls media_field_view_modes(). And system falls into an infinite loop.

You would probbably like media to return other view modes, if your module defines another view mode with hook_entity_info_alter():

function MYMODULE_entity_info_alter(&$entity_info) {
  $entity_info['media']['view modes']['media_sexy'] = array(
    'label' => t('Sexy'),
    'custom settings' => TRUE,
  );

Since media does not advertise your new view mode for you you can do it by yourself with hook_field_formatter_info_alter():

function MYMODULE_field_formatter_info_alter(&$info) {
  $info['media_sexy'] = array(
    'label' => t('Sexy'),
    'settings' => array(),
    'field types' => array('media'),
    'module' => 'media',
  );
}

Now you can use your view mode in "Manage display" section of your content types and also in views. I am not sure if this is the correct way to do it, but it works.... Please correct me, if I am thinking in a wrong direction.

ogi’s picture

subscribe

poochuan’s picture

how to use media_sexy mode view in fornt page or taxonomy or node page? thanks!

poochuan’s picture

how to use media_sexy mode view in fornt page or taxonomy or node page? thanks!

kmadel’s picture

Just wanted to point out the adding views modes via the Display Suite (http://drupal.org/project/ds) functionality works quite well. Display Suite allows you to add new view modes from Home » Administration » Configuration » Media » Media Types » Image media type settings.

JacobSingh’s picture

Title: Howcome media_field_view_modes() only returns predifined view modes? » Allow view modes to be dynamically defined.

There are ways to create view modes dynamically in media right now, but it isn't very simple to do.

The media_gallery module has some good examples of this. I think at the time, we just copied a lot of what node had in it, but it should change. This is NOT a high-priority issue for me personally, so I'm not going to be working on it. It is a high priority issue for the project generally though IMO and it would be great if someone wants to own making this happen.

Thanks everyone!
Jacob

slashrsm’s picture

Status: Active » Needs review
FileSize
4.18 KB

Here is the basic idea. It adds link to creation form to all "manage display" pages for media. Custom view modes are stored in a variable, that lives inside media's variables namespace.

There is no support for delete function yet, but should be trivial to add it. The biggest issue I have here is, that I need to completely flush cache before new view mode appears under "Custom display modes" checkbox list. How could that be fixed?

Status: Needs review » Needs work

The last submitted patch, media_view_modes_1026790_14.patch, failed testing.

slashrsm’s picture

Status: Needs work » Needs review

#14: media_view_modes_1026790_14.patch queued for re-testing.

effulgentsia’s picture

It adds link to creation form to all "manage display" pages for media.

I think a UI for an administrator to add view modes has value, but I don't think it belongs in the core Media project. According to #12, such functionality exists in Display Suite, which seems like a more appropriate home for this.

There are several things that can be improved within Media and Styles, however, to address some of the use-cases described earlier in this issue:

  • Styles is supposed to automatically create a File Style for each image style, and Styles 1.x did this, but this got accidentally removed from Styles 2.x. See #1058056: In File Styles 2.x, file styles don't exist for administrator defined image styles.
  • I haven't caught up on where we're at with the Styles UI, since Aaron's blog post a couple months ago, but that's intended to be the UI for creating administrator-defined styles other than ones that can be automatically created based on image styles.
  • I think Media should automatically create an entity view mode for every File Style.
  • And I think that Media should automatically create a media field formatter for every media entity view mode (addressing the WTF pointed out in #8).

As each of the above gets implemented, the need for administrator defined view modes other than ones created implicitly via the creation of an image style or other Styles module style, or via other code implementing just a single hook, will probably become much smaller, and only for the kinds of crazy (and awesome) things that Display Suite is designed to address.

As per #11, until these other issues get dealt with, you can look at Media Gallery for an example of implementations of hook_image_default_styles(), hook_styles_default_styles(), hook_styles_default_presets_alter(), hook_entity_info_alter(), and hook_field_formatter_info(). Agreed that having to implement 5 hooks to add a new way to display a media item is crazy, which is why I suggest the above bullet points, and hope to get a chance to help out on them soon.

neurojavi’s picture

I totally agree with effulgentsia in #17:

A.- I think Media should automatically create an entity view mode for every File Style.
B.- And I think that Media should automatically create a media field formatter for every media entity view mode (addressing the WTF pointed out in #8).

But I think that B is not needed as it is allready done by media module (see media_field_formatter_view()). The only thing we need is that media reads view modes from field_bundle_settings variable (the problem is that there are different view modes for each media type, but this can be dicussed). If media does this then we would be able to use custom view modes. With view modes in code (as it's now implemented) there is no way to use custom view nodes nor File Styles created with the UI.

If view modes were not harcoded the rest of the problem could be resolved with display suite:
- Create an Image Style (this should create an associated File Style)
- With Display Suite enabled: Go to media/image/Display and create a new view mode
- Set the image in this new view mode to use your new file style
- Go to you cotent type (say blog post)/Display and, in your media field, set the formater to your new view mode -> THIS IS NOT WORKING because view modes are hardcoded

The automatic creation of view modes for file styles (A) would be very useful (to avoid DS if you don't need it) but what is really necessary is that current view modes get listed as formatters.

Thanks.-

neurojavi’s picture

Hi again:
In my last comment i said that each view mode generates a formatter because of function media_field_formatter_view() but i was talking about media_field_formatter_info(). Sorry.

Now that issue #1086958: Switch from Media Entity to File Entity is fixed and commited (great job, effulgentsia!) I can see all view modes as formatters. The only problem I found is this:

function media_field_formatter_info() {
  $formatters = array();

  // Add a media field formatter for each file entity view mode.
  $entity_info = entity_get_info('file');
  foreach ($entity_info['view modes'] as $view_mode => $view_mode_info) {
    // @todo Modules other than Media can also add view modes to file entities.
    //   No reason not to allow them to be chosen when formatting a Media field,
    //   but because Field API keeps all formatters across all field types in a
    //   single array, we run the risk of name collission. The best way to solve
    //   this is to convert this into a single formatter with a setting for the
    //   view mode, similar to how the "Image" formatter has a setting for the
    //   "Image Style".
    if (strpos($view_mode, 'media_') === 0) {
      $formatters[$view_mode] = array(
        'label' => t($view_mode_info['label']),
        'field types' => array('media'),
      );
    }
  }

This code prevents view modes created via display suite (and others) to be used as formatters. The only way to use them is to name them as media_xxxx so they are not filtered by this code. In the meantime, while the single formatter with settings for selecting view mode is written, could we just add all file entity view modes as formatters and add a 'media_' prefix to the formatter name to avoid conflicts?

Something like this:

function media_field_formatter_info() {
  $formatters = array();

  // Add a media field formatter for each file entity view mode.
  $entity_info = entity_get_info('file');
  foreach ($entity_info['view modes'] as $view_mode => $view_mode_info) {
    // @todo Modules other than Media can also add view modes to file entities.
    //   No reason not to allow them to be chosen when formatting a Media field,
    //   but because Field API keeps all formatters across all field types in a
    //   single array, we run the risk of name collission. The best way to solve
    //   this is to convert this into a single formatter with a setting for the
    //   view mode, similar to how the "Image" formatter has a setting for the
    //   "Image Style".
    $formatters['media_' . $view_mode] = array(
      'label' => t('File entity view modes: ' . $view_mode_info['label']),
      'field types' => array('media'),
    );
  }
RobW’s picture

Subscribing. Thanks for everyone's work on this.

cossovich’s picture

Nice one @slashrsm, I think that this might be the best approach for using custom image styles when embedding images using the media module and a wysiwyg editor. I was trying to get a solution by using the styles moment but at the moment it's a really messy situation. Anyway the code snippet from #8 sure helped me, thanks!

effulgentsia’s picture

Category: support » feature
Status: Needs review » Fixed

Now fixed with http://drupalcode.org/project/media.git/commitdiff/392e17b?hp=ee7ff80e48.... I tested this with http://drupal.org/project/ds, and using that module, I can add a view mode to the file entity, and then use that view mode as a setting in the media field formatter. Note, the fix is in 7.x-1.x only. Some Media modules, like Media Gallery, do not yet work with post-beta4 Media dev snapshots. We're working on getting Media Gallery ready, but it'll be a bit longer. See Media project page for more details and warnings.

neurojavi’s picture

Status: Fixed » Needs review

The upgrade function doesn't work for me. I have custom view modes created with DS and have been using them without problem (see #19) because they began with "media_". This kind of formatters doesn't get updated to the new media formatter and settings format.

I've updated them manually because I've them in code, son I'm fine now.

I think this line in media_update_7019():

if (in_array($display['type'], array('media_link', 'media_preview', 'media_small', 'media_large', 'media_original'))) {

would be better like this:

if (strpos($display['type'], 'media_') === 0) {

Perhaps I'm the only one with custom view modes but who knows...

effulgentsia’s picture

I considered that, but I was concerned about modules that add formatters also prefixed with 'media' (for example, Media Gallery, I think, does). Since there was only a couple weeks where dev snapshots of Media module automatically added formatters for additional view modes, I don't think there's many people who'll run into this problem, and if they do, it can be manually fixed pretty quickly, as you did. Furthermore, in general, I think it's okay for dev snapshot to dev snaphot updates that all occur within a single release cycle (e.g., between beta4 and beta5) to not be completely perfect: it's much more important for beta3 -> beta4, and beta4 -> beta5, etc. to be right. But let's leave this issue open to see if there's a need out there to improve this update function.

neurojavi’s picture

You're right. I only wanted to inform you and other people who can run into the same issue but I think it's very unlikely to be more than one or two more out there in the same situation.
Feel free to close this issue when you want.
Many thanks for your work!

RobW’s picture

OK, I'm going to bring this up, and if others feel the same way I'd like to change this issue's status back to "needs work".

If:

  1. Media module is for uploading and displaying different types of media,
  2. and the newest version of Media operates independent of Styles module,
  3. and view modes are now the primary way of applying different formatters to files (e.g., image styles),

then it seems to me that some sort of view mode creation should be available in Media itself. I could re-purpose Media's generic view modes, but that would only give me six possible formatters, and would break the semantics of small-medium-large-etc. A user driven media heavy site could easily have five times as many image style requirements.

I don't think installing a giant, panels-like module such as Display Suite shouldn't be a requirement to fulfill some of Media's core functionality promises. Right now I am happy to use a hook_alter or a patch, but I'm not sure that installing Display Suite to generate custom formatter options is a good long term solution.

[Edit] After re-reading #17, I think I have a better understanding of the way media/formatters/view modes/styles are meant to work together -- I was turned around as I currently can't use Styles formatters (#1186624: Undefined property stdClass::$uri and stdClass::$filemime in file_styles_styles_filter()). Lots of interacting modules in very active development to keep track of! and I can definitely see the UI difficulties involved in tying them together.

I think you can disregard the post above.

webankit’s picture

+1

marcvangend’s picture

If I understand correctly, this issue is fixed, right?

If so - what are my options if I want to define a new view mode for file entities (yes, I'm using post-beta4 code) of type 'image'? Do I need to use DS (seems overkill for just a view mode) or is there a hook I can implement in a custom module?

RobW’s picture

DS does seem like overkill. I used a hook in a custom module:

//Add more view modes for Media formatting. 
function yourmodulename_entity_info_alter(&$entity_info) {

  //Not sure if it's still an issue, but a previous commenter noted that Media module only recognizes view modes with the prefix media_. Also, as you can see by the entity type 'file', this is for after the switch-to-file-entity patch.
  $entity_info['file']['view modes']['media_your_view_mode_machine_name'] = array(
    'label' => t('Your view mode name'),
    'custom settings' => TRUE,
  );
 
}

Actually pretty simple.

RobW’s picture

Status: Needs review » Fixed

And I agree, with the maintainer explanation in #17, I think we can mark this as fixed.

marcvangend’s picture

Thanks RobW. Just what I needed.

marcvangend’s picture

I'm seeing a PHP notice now, but I'm not sure it's related so I opened a new issue: #1203658: Undefined index: type in media_field_formatter_settings_form()

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

minneapolisdan’s picture

Thanks for the clarification. It sounds to me like I should stop using the default View Modes that come with Media, and instead make my own with Display Suite. At least, that is one way to go. And not use the Styles module at all. (?)

capellic’s picture

I am evaluating Media for the first time and what brings me to this case is the fact that I am using the media button in CKEditor via WYSIWYG and I am baffled as to why I was being asked to choose amongst the following "Current format is" values:

- Link
- Preview
- Small
- Large
- Original

OK, so having some defaults in there is likely handy-- and I've been able to add my own through Display Suite-- but not being able to remove any of the above without some hook_form_alter action seems a bit odd.

And as someone above pointed out, why do we need Display Suite to get this done? Display Suite is a complicated module in it's own right and if one of the major motivations behind the Media project is to improve usability, it shouldn't involve undue pain to configure default image formats.

And why can't I just defined some IMG attributes-- height, width, alt and then go? I get the whole idea of having file formats, but the need for that sort of organization is restrictive in a free-form WYSIWYG context.

The fact that "Preview" is in this list is odd-- what is the content editor of the website going to make of this?

And where do I control Small and Large? I don't see those in the Image Styles. I see this:

- thumbnail
- medium
- large
- square_thumbnail

Ah, well, a little experiment notes the following mappings.. so why the difference in their titles?

- large = Large
- square_thumbnail = Preview

I don't know where the other styles (thumbnail, medium) are defined.

For your consideration.

capellic’s picture

OK.. figured something out. This can be done with Display Suite and does not require any module development.

1. Once Display Suite is enabled, it "sees" the existing file display types on the Manage Display > Default configuration page for File Types. Check all the view modes that you want Display Suite to manage and click Save. (See screenshot below.) admin/structure/ds/view_modes

2. You will then see all those view modes show up as sub-tabs. You can also see this in the first screenshot below. /admin/structure/ds/view_modes

3. Then you go to each of the View Modes and you can drag the "File" item into the "Hidden" area. I did this for all of the out-of-the-box view modes because I want very specific ones and nothing else.

4. I then added my own view mode (Display Suite functionality). See the 3rd screenshot below.

5. Back on the File Types page, be sure that your View Mode is checked. See 4th screenshot below.

capellic’s picture

Continuing from above.. hit save too early.

6. Then go to the Manage File Display tab, then the sub-tab for your View Mode and then click on Image and then define the Image Style (Image Cache). First screenshot below.

7. Then, when adding an image, you will only see your custom View Mode! Ta-da!

Tarik KALLIDA’s picture

thank you "capellic" it's work!!!!

r8r8r’s picture

thanks a lot capellic, this workaround works just as it should!

RobW’s picture