Support different markup and classes on different display modes

Does this exist yet?

Summarized the issue request.

See also comment #4 in #1700154: fences vs display suite

I made a module which makes it possible to override the global fences wrapper field setting per display: https://github.com/maoberlehnerdrupal/fences_display_specific_wrapper

Thanks for the module, Moriartie. I'm impressed that there are only 81 lines of code in the .module file :-) I hope to try it out soon.

It's just a very simple module - and the module has a dependency to the field_formatter_settings module that makes it very easy to alter / add field formatters. Please report back if you like the module. :)

Different markup? Nope. Semantics is semantics. You shouldn't need different markup on different display modes.

As for different classes (i.e. different design) on different view modes, I use https://www.drupal.org/project/field_formatter_class

Different markup? Nope. Semantics is semantics. You shouldn't need different markup on different display modes.

But there is at least one very important exception to that rule: Headlines
In addition to fences I also use the Title module - this modules makes it possible to treat the Title field like a real field so I can use fences markup on it and I can place the Title field in my view modes just like every other field (similar to how it is in display suite layouts)

So on my nodes, the title field gets the h1 fences markup on default and I output it as such in my default view mode. But then I have a view which outputs some nodes with the view mode "teaser" - semantically it makes no sense to output them with the title as h1 - so I use my module to set the title markup to h2 on the view mode "teaser"

I'm aware of that this is a little bit of a "non standard" setup, because how I use the title field to replace the default page title and so on - but I guess there are also cases with headlines in more default like setups without the title field. Jus in my case I need this function on almost every node type i create. Others may need it only in edge cases when they make a sub headline that schould be h2 in the full view mode and h3 when displayed as teaser.

More use cases for different settings per viewmode: https://www.drupal.org/node/1700154#comment-8845735.

And one more: The view mode settings allow you to limit a multi-value field to just one item. For instance, on the teaser you can display only the first image of a multi-value image field. A ul or ol element makes sense as default, but when there's only one image I'd rather have a different wrapper (or none).

If you say "my module will not support your edge case", I can live with that. But IMHO "semantics is semantics" is over-simplifying things.

If you say "my module will not support your edge case", I can live with that. But IMHO "semantics is semantics" is over-simplifying things.

Fair point.

From that linked issue:

Would it be technically possible to extend Fences (either in the project, or as contrib) and the field-level configuration as default, but allow users to override it per view mode in specific cases?

Sure is. Fences does its "magic" by setting a very-low priority theme hook suggestion. So if you want to use a different template for a particular view mode, you can just set your own theme hook suggestion in a preprocess function. In fact, you can even use one of Fences' templates:

function myproject_preprocess_field(&$variables) {
  // Fences theme hook suggestions for fields follow this pattern: field__fences_[element]

  // Check for a particular view mode and then use a different template.
  $variables['theme_hook_suggestions'][] = 'field__fences_h3';
}

I'll re-consider this, but I think it would over-complicate the interface for this edge-case.

I have done a lot of work with higher ed sites. It would have been a god send to have these settings in the field formatter on a per display mode bases. The title field use-case alone would have made accessibility issues just go away for me. As it was we had to do, almost exactly what you are suggesting we do.

For Drupal 8+ (2.x) this is possible. For Drupal 7 we won't add this anymore, sorry.
Last comment 7Y ago ;)