Add the "Entity view mode" module to core

[jenlampton]

This simple module provides a lightweight UI for adding additional view modes, and provides expected template suggestion hooks. https://www.drupal.org/project/entity_view_mode

---

PR by @docwilmot: https://github.com/backdrop/backdrop/pull/1645 initial port Latest PR by @jenlampton https://github.com/backdrop/backdrop/pull/1689

[ghost]

Yes please! :+1:

[quicksketch]

Like other "Add X module to core" issues, I'd like to clarify that we're not planning on just adding a port of the module directly into core. The functionality from this module should be integrated directly into either the core entity.module or field.module.

[olafgrabienski]

In my opinion, custom view modes (or display modes) are especially helpful when you work with references. (Quick example: two content types, let's say Team member and Event. On the Event page you want to reference Team members who registered for the Event, but not the full information but only name and photo)

As Reference(s) is/are going to be integrated in core in 1.6, the need to build custom display modes via the UI will increase, so let's add the ability to do so in release 1.6 as well. @quicksketch @jenlampton What do you think about it?

See also @quicksketch's statement on https://github.com/backdrop/backdrop-issues/issues/2084#issuecomment-244277095:

One feature from DS that could (and should) be implemented as soon as possible is the ability to create custom display modes.

[klonos]

This is part of #378, as in D8 they have already implemented this feature...

From #2250 (closed as duplicate of this issue):

In D6 there was Build Modes and then its successor Entity View Modes for D7 that allow you to create custom view modes through the UI. It seems that in D8 they have implemented something like that in core (or a lite version of the respective feature of Display Suite)...

They have added a new "Display modes" menu under /admin/structure that has two submenus: "Form modes" and "View modes":

"Form modes" I guess allows to manage the fields in the "Manage form display" tab (which we don't have in Backdrop - separate issue), while "View modes" allows you to manage the existing and add new view modes.

[mikemccaffrey]

It has always struck me as weird that you can't arbitrarily create new view modes in the ui, since there is so little to them.

The only tricky part is figuring out how to handle it I think the ui. Adding an interface under structure seems like a good idea. And when you create one, you can just enter the name and then check which entity types it should be available for.

[olafgrabienski]

Adding an interface under structure seems like a good idea. And when you create one, you can just enter the name and then check which entity types it should be available for.

Additionally, we could add a link "Add new custom display" on the Manage Display page of a content type, that would be under the "Custom display settings".

Side note: "Custom display (setting)" seems to be the Backdrop name for view mode, so Structure > Custom displays?

[klonos]

Adding an interface under structure seems like a good idea.

Yep, and that's what D8 users will expect.

And when you create one, you can just enter the name and then check which entity types it should be available for.

Fully agree with you there @mikemccaffrey. D8's approach is really odd: first you select from a list of links the entity type the view mode should be applied to:

...and then (no matter what entity type you have chosen in the previous page) you are requested to enter a name for it:

In this last page that requires the user to enter a view mode name, although the page title and path changes, it is (from a form point of view) basically the same for all entity types. So this 2-page wizard could as well be a single page (or dialog in our case) that allows entering a view mode name and then selecting either one entity (drop-down select or radio set) or multiple entities (checkbox set) that the view should be applied to. Not sure if the D8 approach that forces the selection of a single entity type is a technical limitation (view modes are allowed to be attached to a single entity type) or a UI implementation shortcoming (requiring selecting a single entity type in step 1 of the wizard).

In D8, they also have a page where all view modes are listed and can be edited/deleted:

...but as @olafgrabienski said, we should also have it so that people can add a view mode via a dialog without ever having to leave the "Manage display" page of the content type they are currently editing ("connect the dots" as @jenlampton says). That is more or less what I have also previously suggested over at https://github.com/backdrop/backdrop-issues/issues/2205#issuecomment-250659398:

Side note: "Custom display (setting)" seems to be the Backdrop name for view mode, so Structure > Custom displays?

That is just the label of the fieldset that is used to hold the set of existing view modes. If you expand that fieldset, you'll see that it says "Use custom display settings for the following view modes". This is not a Backdrop thing, we inherited the same UI from D7:

...plus I think that changing the terminology is not a good thing. In D7 it was view modes and D8 has kept the same thing. They also added the "sibling" form modes that is a prelude I guess to handle the display of forms, since in D8 there's already a separate "Manage form display" tab for each content type:

[olafgrabienski]

@klonos - Re "Custom displays" vs. "View modes": You're absolutely right!

[docwilmot]

First push; need tests still.

[olafgrabienski]

Just had a look at the test site. At the moment, it's not possible to visit admin/structure/types/manage/CONTENT-TYPE/display. The link isn't in the admin bar, and if you enter such a path manually, you don't see the Manage Display page of the content type but the Configure Content Type page.

[jenlampton]

That's not a valid path. Replace the uppercase with a type name.

[olafgrabienski]

Sorry for being unclear, it was a generic placeholder. Here the two valid paths in a default installation:

• admin/structure/types/manage/page/display
• admin/structure/types/manage/post/display

[docwilmot]

Sorry to delay reply, but actually @olafgrabienski is right. There's a silly error in the code which I fixed yesterday but haven't pushed. Will do so later.

[docwilmot]

Should be fixed, including new tests.

[docwilmot]

Should also say, its not polished yet, some code comment lines need moving, and I'm not happy with the local actions code. This is up for review actually.

[klonos]

I just gave this a spin and it works fine so far. UX improvements:

1. The "add view mode" link is disconnected from the view mode tabs. You can see this better if you enable a view mode (from the "Custom display settings" fieldset) after the two messages are shown. I think it would make better sense to move the link to the right of the last view mode:

   

   Eventually, I would like us to adopt this improved design of secondary tabs plus the "+ Add xyz" link in the Views UI as well as elsewhere where it makes sense (for consistency).

2. The "add view mode link" is not available when editing view modes other than the default (same goes for the "Custom display settings" fieldset, but I think that we should ditch that anyways, see point 6 below):

   

3. We should add a menu item for adding new view modes in the admin bar: Structure -> Content types -> %content_type% -> Manage display -> Add view mode

4. Not sure that having the "Add view mode" link go to the "View modes" overview page (which otherwise is very useful), where the user needs to click yet another "Add new view mode" link to accomplish the task is a good UX. If the user clicked the "Add view mode" link from a user account page, they will need to scroll all the way down to the bottom of the page. Not good UX.

   Take the most common use case of adding a view mode for content types. Leaving aside the fact that the first thing the user will see in the "View modes" overview page is the list of view modes for comments (instead of the content types they'd expect), once they do add a view mode for a content type, they return to the "View modes" overview page instead of the "Manage display" page of the content type they were editing.

   What I would expect instead is a modal to pop up, allow me to create a new view mode, and once I hit save, the page would refresh with the new view mode added to the "Manage display" page of the content type I was editing.

5. In the "View modes" overview page, the word new in "Add new view mode" is surplus I think.

6. Having existing but disabled (not customized) view modes hidden in the "Custom display settings" fieldset requires many clicks in order for the user to enable them (expand fieldset, check box, hit save), plus this action causes a page refresh. Not to mention that having that fieldset at the bottom of the page makes it hard for the user to discover that there in fact exist other view modes. All that is bad UX. I think that we should have all view modes available as tabs at the top and have them behave more like the views displays (asterisk in the name denotes overridden/customized). In other words, something like this perhaps:

   

[jenlampton]

We need to be careful not to create new UX inconsistencies when adding new features. For example, changing how action links work on this one page would be a problem.

@klonos can you please create a separate issue for location of action links site wide? Let's keep that idea separate from this new feature addition.

The same is true for changing the tabs for disabled view modes actually. It's unrelated, and can be done at any time :)

Also, were these supposed to be called "Display modes" in the UI? To decrease confusion with Views? (see https://github.com/backdrop/backdrop-issues/issues/2376)

[olafgrabienski]

Had a look at the test site, thanks for working on this, @docwilmot! Two questions so far:

(1) You put the view modes under Configuration > System. Why not just under Structure as suggested in https://github.com/backdrop/backdrop-issues/issues/315#issuecomment-253141862? I'm not sure which one is better.

(2) When adding (or editing) a view mode, there is the option "Use custom display settings":

I didn't understand the help text "Unchecking this will delete all the display settings for this view mode." Looks also strange to me. When adding a view mode, it makes no sense to delete it's settings at the same time.

[docwilmot]

The "add view mode link" is not available when editing view modes other than the default

Bug then, will fix.

We should add a menu item for adding new view modes in the admin bar: Structure -> Content types -> %content_type% -> Manage display -> Add view mode

It was under Config > System in EVM module. Structure makes sense, will move there.

Not sure that having the "Add view mode" link go to the "View modes" overview page is a good UX. What I would expect instead is a modal to pop up

On the field display pages a modal to add custom view modes would be great, but the UI now presupposes CRUD operations are separate, hence the "Add view mode" local task taking you to that central listing. If we're bypassing that listing with a dialog, then it seems "edit" and maybe "delete" would also require a link and dialog too. Which may complicate things more than we want in this issue.

However, I think its very reasonable if we have custom view modes that users should be able to link to the listing page from the display pages. I see your example in the image of Edit View Mode | Manage View Modes; I can do that, but would like a word from @jenlampton about that. Is is the best way?

In the "View modes" overview page, the word new in "Add new view mode" is surplus I think.

True, will go.

Having existing but disabled (not customized) view modes hidden in the "Custom display settings" fieldset requires many clicks in order for the user to enable them (expand fieldset, check box, hit save), plus this action causes a page refresh.

I agree with this actually. @jenlampton wants it fixed in another issue though.

We need to be careful not to create new UX inconsistencies

Agreed

Also, were these supposed to be called "Display modes" in the UI?

Didnt know that. Shall I change then?

You put the view modes under Configuration > System. Why not just under Structure as suggested in #315 (comment)? I'm not sure which one is better.

Agreed, see above, will move.

I didn't understand the help text "Unchecking this will delete all the display settings for this view mode." Looks also strange to me. When adding a view mode, it makes no sense to delete it's settings at the same time.

Agreed, this should only show for editing view modes, not for new. I actually wonder why we do this custom settings thing anyway. Seems view modes should keep their settings and be available all the time. See @klonos proposal to make the display just like the Views UI.

[klonos]

Also, were these supposed to be called "Display modes" in the UI? To decrease confusion with Views?

Yes, I did mention in one of my earlier comments this issue where the fieldset that holds these things says "Custom display settings" while the label of the checkbox set when the fieldset is expanded refers to them as "view modes". FWIW, in the Views UI we call these plain "Displays":

...so I'm thinking that it would probably be more consistent to call all things that display a specific thing in different fashion "displays". Filed a separate issue for that: #2342

We need to be careful not to create new UX inconsistencies when adding new features, for example, changing how action links work on this one page would be a problem.

That is very true. Are you referring to changing the position of the "+ Add xyz" link to the right instead of the left, or the suggestion to have them open pop-up dialogs?

I see what you mean with both, but in this specific use case, each time the user would add a new display to their content type, there would be a new item added to the horizontal list of secondary tabs. It made sense to me to have the add link where the item would be added. This would also be consistent with how adding displays in the Views UI works.

As for having these links open dialog pop-ups, I think that this should be a UI pattern because we are already using that (with great success IMO) in the Views UI and the Layouts UI for configuring various things. It saves the user from page refreshes and they stay in context while configuring/editing various aspects of the main thing they were editing. I think that this is very good UX.

@klonos can you please create a separate issue for location of action links site wide? Let's keep that idea separate from this new feature addition.

I believe that we can discus this in #2342 (where I also suggest general consistency in the UI). If we see that we need a totally separate issue just for the links, I'll then file one.

Same thing for changing the tabs for disabled view modes actually. It's unrelated, and can be done at any time :)

True. Although the new UI that we are adding here for allowing users to add entity displays seems to have a lot of similarities with how displays are added to views, there is one big difference: views have display types (page, block, attachment) and once you add a display, it is always shown and cannot be "disabled". With entities, we have a single type of display (we do not even expose this to the user, so the display and the single display type is the same), but each display can be assigned to multiple entities of the same type. Hmm.

My only concern here is that if we do decide on terminology in this issue here, then once we introduce the feature, it'd be hard to change it if we needed to (in order to implement the suggestions that will be in separate issues). So, yes, separate issues, but we should be taking them under consideration along the way as we are implementing this feature here.

[jenlampton]

There's nothing in common between these "View modes/Display modes" and views "Displays" except the word "Display" (and the word "View"), so we probably should keep the names different so people don't think they are related in any way. In the code, these are called view_mode but I think a view mode is more likely to be confused with a view, than a Display mode is likely to be confused with a Views Display. But, now I'm having second thoughts about changing it at all... (see https://github.com/backdrop/backdrop-issues/issues/2376)

Let's also keep in mind that the Views UI is unique in core, so it may not be a good thing to compare to for UX improvements. We do have established UI patterns all over core, and breaking them here because it's not similar to Views is not the right direction to move. We should be fixing views to be more like everything else in core, or taking what we like from views and doing that all over the rest of core - not making more one-off pages.

To that end, there are no action links anywhere in core that open in modals, see "+ Add content", "+ Add content type", "+ Add layout", etc. I agree action links are weird, but it's a bigger problem than we can/should address here :) Let's try to keep the focus of this issue on this feature, and if we come across realizations of UX improvements for all of core, let's open new issues for those as necessary.

[jenlampton]

Also, were these supposed to be called "Display modes" in the UI?

Didnt know that. Shall I change then?

No, don't bother with that in this issue. I took a stab at only that one change and think we should discuss it separately from adding this feature. It's a bit of a doozy, see https://github.com/backdrop/backdrop-issues/issues/2376

[jenlampton]

We should make the list of view modes more consistent with other UIs in core.

• Remove the fieldsets
• Can we put all entity types into the same table with a column for entity
• Make the link to Add new display mode an action link at the top of the page instead

Here's what it looks like now:

Here's what I'm envisioning:

It might also be good to explain what custom settings are, and why/how a view mode gets locked.

[docwilmot]

Good idea re the single table. View mode column should be first though.

[jenlampton]

Yes, good catch! Pushed a new PR. It also includes a few other changes (listed on the PR)

[docwilmot]

Left a couple comments. The single link to 'Add view mode' needs work. Currently just links to the same admin/structure/view-modes page. Now that we've gotten rid of the per-entity links to add a view mode, we will need some way to allow the user to choose the entity type. Either a dropdown or a multistep form. Dialog?

[jenlampton]

I'm currently working on ajaxy stuff so we can select the entity type in the "add view mode" form and the bundle checkboxes will reload automatically. This may be beyond my skills, but I'm tryin' it anyway :) edit: holy cow, that was easier than I expected! <3 Backdrop

[olafgrabienski]

Looked at @jenlampton's PR and saw a typo on the Manage Display page:

See core/modules/field_ui/field_ui.admin.inc, line 1116: '#title' => t('Customize view mdodes'),

[jenlampton]

whoopsie. I'm not sure about that fieldset label anyway, I've put it back the way it was.

[MrHaroldA]

@jenlampton, did you push your latest commits? PR 1659 looks 5 days old ...

[jenlampton]

I did, the branch is 315-view-modes-single-table and it's up to date. I rebased, maybe that explains the date problem?

[MrHaroldA]

I looked at the test site at http://1659.backdrop.backdrop.qa.backdropcms.org/ which seemed to miss some of the fixes mentioned above, like the Ajaxy stuff in 'Add view mode'. Now, I didn't quite read all comments above, but I felt this is not ready to be merged in core due to some severe rough edges ...

[MrHaroldA]

I could review this, if we are sure the codebase is up-to-date.

[jenlampton]

rebased, and pushed a new PR. Ready for review. I think this bit needs some UX work:

I added the link to add a new view mode down where the view modes were listed since that's where people are most likely to want/need it, but it looks funny down there. Especially with the fieldset label being "Custom display settings"

[jenlampton]

I'm going to take a stab at making that listing look more like this one...

[klonos]

1. When adding a new view mode, the default entity type is "Node" and the available options ("page", "post") are checked by default. Selecting any other option from the "Entity type" drop-down menu does not have the respective options pre-selected. This includes returning to the "Node" entity type, where "page" and "post" are now not pre-selected.

2. "Enable this view mode for the following types" needs some attention. We use "Entity type" in the drop-down menu above, so what is the "following types" referring to? Types of what? I know we should not be exposing the word "bundle" in the UI, but using the word "types" twice is confusing and equally bad UX. We need to come up with something that explains these "things" in lame terms.

3. With regards to the "Use custom display settings" checkbox. It has been discussed before...

   I didn't understand the help text "Unchecking this will delete all the display settings for this view mode." Looks also strange to me. When adding a view mode, it makes no sense to delete it's settings at the same time.

   Agreed, this should only show for editing view modes, not for new. I actually wonder why we do this custom settings thing anyway. Seems view modes should keep their settings and be available all the time. ...

   As a beginner I do not understand a) why it is there in general and what it exactly does b) what is the point of having that thing there for cases where there is only one "type" available ("User" or "Taxonomy term"). Can we count $bundle_options and then do not render the checkboxes if there's only one?

4. Say that one creates a view mode for page and post. Will that view mode be available for any new content types created in the future? Should it? I think yes. Can we have that be the case and if people need to exclude a view from being available for a bundle then have them do that via the view mode edit action. This will make adding view modes less complicated while still accommodating advanced use cases.

5. I like the "Please wait..." text while we are fetching things in the background, but can we have it at the same time explain to the user what they are waiting for? Something like "Retrieving content types. Please wait..." (or omit the "Please wait" in that case).

[klonos]

6. It would also be nice to have certain columns of the view modes list be sortable and/or have a filter so that one can limit the list to view modes for specific entities or by their storage state for example.

[klonos]

7. I really liked the fact that the entity type is pre-selected if you start adding a view mode from the "Manage display" page of content types 👍

8. Would it make sense to add a "Add view mode" menu item also under

   • Structure -> Content types -> %content_type% -> Manage display
   • Configuration -> User accounts -> Manage fields -> Manage display

[MrHaroldA]

I would very much like to manage view modes directly in the 'Custom display options' form, just like the 'Manage fields' form: select an existing, or create a new one.

You can set permissions of a content type on the create/edit page too, and this proved a major UX improvement!

[jenlampton]

1) can fix. 2) I have an idea for this, see below. 3) I have removed the "Use custom display settings" checkbox, I also don't know what that means and that setting exists in other places with the context to make it make sense. 4) Yes, we can default new ones to ON and require they be turned off per bundle. 5) that will be hard as that text is the same everywhere in core. @klonos Can you open a follow up issue to customize the please wait text as needed? That could be a UX win! 6) sortable we can do, filterable not so much. But ideas on that below - maybe it won't be necessary. 7/8) there is one, it's with the list of view modes, in the fieldset.

I would very much like to manage view modes directly in the 'Custom display options' form, just like the 'Manage fields' form: select an existing, or create a new one.

Yes!! This is actually what I'm working on right now. I was showing @quicksketch what I was working on last night and he said that the view-modes list, while useful, was really strange floating out there under structure with no context. I was confused about how to get rid of the words entity and bundle, things users will have seen nowhere else in core, people may not know what they are, and he recommended that we just move the whole form into the places people use view-modes, the "manage display" page, just like @MrHaroldA suggests! I'm about half way through setting that up, but I think it will solve the problems @klonos is facing in items 2 6 as well :)

[klonos]

I would very much like to manage view modes directly in the 'Custom display options' form, just like the 'Manage fields' form: select an existing, or create a new one.

Yes!! This is actually what I'm working on right now. ... I'm about half way through setting that up ...

Good on ya 👍 I can't wait to try that out 😄

[klonos]

@klonos Can you open a follow up issue to customize the please wait text as needed? That could be a UX win!

Done 😉

[jenlampton]

Okay, here's a start. The PR leaves the existing view modes page but if we can get this working how we like it then that can go away completely.

[jenlampton]

@quicksketch also recommended that we replace the "Add view mode" link at the bottom with a field where we can define the name. I think that's what @MrHaroldA wanted also, so leaving at NW until I add that.

[docwilmot]

Sorry but I am not feeling comfortable with this approach.

For one this PR goes above the original intent, which was simply to provide for custom view modes, into redesigning the display options page, which we implicitly decided not to do earlier somewhere in this conversation.

But mostly, this approach is more confusing. We now have a row of mystery buttons/tabs at the top (view modes, for those in the know), followed by two rows of fields, with no obvious relation between the two, followed by another mystery fieldset with cryptic terms like machine name and storage state, and now we propose a textfield below that too.

I think my original PR with a big ole "Add View Mode" action link which took you away from the fieldAPI/display mess, at least made it obvious that you are in a UI just to manage view modes, for what thats worth. This one seems to merge a confusing concept into a confusing UI. I think until we can independently figure out a better display page we should stick to this issue, to simply add a UI for managing view modes, and open a new issue to fix the display pages.

[docwilmot]

Here's a radical idea though:

Under the "Manage displays" tab we keep only the view modes table. In the operations column for each view mode we have a link ("Edit field display"??) which then links to the usual FieldAPI list of fields to hide/relabel.

[jenlampton]

For one this PR goes above the original intent, which was simply to provide for custom view modes, into redesigning the display options page, which we implicitly decided not to do earlier somewhere in this conversation.

We decided not to redesign the tabs / action links. Since that was not related to the addition of view modes. Putting new view mode data where there is already existing view mode data is not really a stretch - it's more inline with the original intent of Field UI (which, admittedly, needs love).

We now have a row of mystery buttons/tabs at the top (view modes, for those in the know), followed by two rows of fields, with no obvious relation between the two, followed by another mystery fieldset with cryptic terms like machine name and storage state, and now we propose a textfield below that too.

This is not a change. This is how Drupal/Backdrop is today. All we've done is change a check-list into a table with checkboxes on the left, like many the other UIs in core. (The fieldset will be collapsed by default to help beginners from being overwhelmed on this page).

I don't feel strongly about having storage state and machine name in this table though, and would be happy to remove them. They are only there because they were in the entity_view_modes module, so I assumed someone found them of use. Let me know what you guys want here! :)

I think until we can independently figure out a better display page we should stick to this issue, to simply add a UI for managing view modes, and open a new issue to fix the display pages.

We do need to figure out a better display page, that's for certain, but this issue is to add custom view modes to core, which is what we are doing. The question is where to put them. :)

I think my original PR with a big ole "Add View Mode" action link which took you away from the fieldAPI/display mess, at least made it obvious that you are in a UI just to manage view modes

A few thoughts:

1) the current contrib approach breaks the way Action links are supposed to work (linking from one part of the site to a completely separate part) and creates a UX inconsistency in core. 2) We have a rule not to use the word "Entity" or "Bundle" in the UI in core, because those terms don't make sense to non-developers. The UI in the contrib module requires the use of both those words since the settings have been moved away from the entities/bundles that need them. Moving the UI back into-context removes the need for either confusing term. 3) The concept of view modes will be hard to grasp without context. Leaving them where core had them - where they are in this latest PR - they have the necessary context, and will make more sense to beginners. (Three of us came to this same conclusion separately, so I think it's a good one.) 4) by managing the custom view modes the same way core manages the pre-defined ones, we can eliminate the need for the 'custom settings' property of each custom view mode since by saving this same form those values are saved in the same exact place core saves them for the other view modes. DX win here, consistency.

Here's where we are now:

[jenlampton]

Here's a radical idea though:

Under the "Manage displays" tab we keep only the view modes table. In the operations column for each view mode we have a link ("Edit field display"??) which then links to the usual FieldAPI list of fields to hide/relabel.

I LOVE this idea!!!! I'm going to give it a shot and see where we land :)

[klonos]

3) The concept of view modes will be hard to grasp without context. Leaving them where core had them - where they are in this latest PR, they have the necessary context, and will make more sense to beginners. Three of us came to this same conclusion separately, so I think it's a good one.

Yeah, @docwilmot I'm not 100% happy with the UI either, but what @jenlampton says sums how I feel about it too.

[klonos]

Here's a radical idea though:

I think I like that idea too. @jenlampton, if it's not much to ask, can you please keep two separate PRs with the two different approaches in order to be able to try both in their respective sandbox to help decide which one feels like better UX?