fences vs display suite

Quite interested in the answer to this as well.

Display suite can do the same , he only does it per view mode and not globally.
Just Enable Field Templates in the Display suites Extra module.

Is there a reason to not allow for different settings per view mode? how hard of a feature would that be to add?

Fences was intentionally designed to provide a tool for setting semantic markup that's global. Set once; Have everywhere. We debated this point thoroughly — and felt like, hey, if this field is a blockquote, then it's a blockquote everywhere. In what universe would it be a blockquote in one place (View, Viewmode, Block, or Node), and a section/div/p somewhere else? We didn't want, as site developers, to have to set and reset the same semantics over and over. Not only is it more work to have to choose markup for each field on every display, it leaves open huge rooms for error — either from not specifying the semantic markup for every display, or in doing so in an inconsistent manner. This is especially true when working on a big team where things like this easily fall through the cracks.

So this choice is intentional — Fences does not ask you to (or let you) choose the semantic markup for each display. It let's you define the semantics when you define the field itself, and then move on with life, knowing its set to display everyplace that it'll be displayed. That's one of the biggest differences between it and Display Suite or other modules. Less work. More consistency.

Yes, you can use DS to set which fields to show, while letting Fences handle the semantics in a global manner. It's a little crazy to have two modules with almost overlapping features... but, well, Drupal! Clearly there are several good, slightly-different ideas for solving these needs. Hopefully much of this will be ironed out for D8.

Admittedly any changes to fields I can think of are visual, not really structural and there's better ways to solve that. Thank you for the very well explained reply.

Thanks for the explanation, Jen. For the sake of the argument, I can think of use cases where you would choose different wrappers per view mode...

Use case 1: Node type 'article' has a 'subtitle' text field. On a node page, the node title is h1 and the subtitle is wrapped in h2. Now let's create a view of articles, using the teaser view mode. The view title is h1, each node title is rendered as h2, and the subtitle field becomes h3. (Yes, in HTML5 you could have multiple h1's on a page, but you shouldn't: http://blog.adrianroselli.com/2013/12/the-truth-about-truth-about-multip...)

Use case 2: Node type 'article' has a taxonomy term reference field which accepts multiple values. The terms are rendered by Fences as ul. Now, for a more compact teaser view mode, I use https://drupal.org/project/field_delimiter, https://drupal.org/project/textformatter or https://drupal.org/project/taxonomy_formatter to render the terms in a comma-separated string. Here, the ul makes no sense anymore.

How would you handle those situations?

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?

The cool thing is that Views will by default (with Fences turned on) have selected a checkbox that says something like "use field template". You can uncheck that box. Then Views will ignore the Fences template. And you can use the tool inside Views to set markup for that unique display of that field. And I do use this a lot. When the whole node is being printed, the mark-up is pretty static, IMO, no matter where that node shows up. But yes, when individual fields from a node are printed, the context is different, and so maybe the markup should be different — say a field is an h3 in the full node, but an h4 in a particular View. (Yes, I'm aware I'm kind of contradicting myself now... oh well.)

By default, Views will start with the Fences markup. But you can totally override it, just as easily and using the same tools as if you didn't have Fences installed. Fences does hijack Views, however, so if you do nothing special and don't override, you get the universally-set Fences markup... and not div div div div. Which I love. Especially when working on a team where many of the other developers don't want to think about HTML and never alter the default Views markup no matter how many times I ask.

I don't know about Use case 2. I'd have to think about that more.

You can extend or override Fences all you want. Read the documentation (on the page: https://drupal.org/project/fences). You can simply make your own fences tpl files, and select those from the pick-the-markup-you-want Fences setting drop down menu when you define the field.

Fences ships with a bunch of tpls files. Look inside the module to see which ones, and to see the markup for each of those. If you would like to change that markup, make a copy of any tpl file, put it in your custom theme, and edit away. Drupal will automatically use the copy in your theme instead of the copy in the Fences module files (once you clear the cache).

If you would like to make more things — and add to the list of possibilities — make more tpls files of your own, and place them in your theme. Use the fences naming convention, and Fences will automatically find them, and add them to the list available in the dropdown for field configuration.

field--fences-NAMEOFELEMENT.tpl.php
and
field--fences-NAMEOFELEMENT-multiple.tpl.php

We knew Fences wouldn't cover all use cases, so we built in a way to be able to customize Fences.

See also feature request in #1888224: Support different markup and classes on different display modes

I think in the scenarios described above, you might want to just override the teaser template or whatever other view mode template you're using and write out the markup yourself, ie:

<h3><?php print $node->field_something['und']['0']['value']; ?></h3>

which will give you the bare field value wrapped by h3 tags.

Re #9: That's a simple example, but once you start rendering multi-value fields as ul's, your templates get messy very quickly. Also, it kind of defeats the purpose of using a module like Fences. You might as well uninstall Fences and do this everywhere, for the sake of consistency.

#1888224#comment-10166534