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

[MrHaroldA]

To me personally, the help text seems out of place. No other form has such a text in it's header.

I do like the functionality and overall look, although the Manage display interface works differently by dragging fields into "Hidden", aka "View modes using the default display". Should the Fields interface be changed into the Display mode style after this is finished?

admin/structure/types/manage/page/display/search_result could do with the bundle type in it's title too, and maybe my earlier suggestion should have been the emphasized %bundle_name instead ;)

[MrHaroldA]

Also, when manually entering the view mode machine name, the form/table doesn't fit into the fieldset.

[olafgrabienski]

try again now?

@jenlampton Yes, site is running again. Will have a look later or tomorrow ...

[docwilmot]

@jenlampton I think you may have missed my comments https://github.com/backdrop/backdrop-issues/issues/315#issuecomment-268148702.

To me personally, the help text seems out of place. No other form has such a text in it's header.

Agreed. Why not just description text below the table as usual? And its still too Node specific ("For example: Full content and Search index are usually the same...").

Another try: "View modes allow you to modify how User account items are displayed in different situations. For example, creating a list View mode may allow you to hide field labels in lists of User accounts, but show these labels when User accounts are viewed elsewhere."

If we have a separate table just for Default (like we do for Layout defaults), then we can append the "The Default will be used for view modes that have not been explicitly customized" to that table.

Also, when manually entering the view mode machine name, the form/table doesn't fit into the fieldset.

We shouldnt be hiding that textfield in the fieldset, there's no obvious reason for that. Or ideally, we should be using a dialog to launch the "View mode Add/Edit form" instead.

Incidentally, one major weakness of this approach is that view modes created for one bundle will only apply to that bundle.

Apart from all that, customizing Comments and User accts still doesnt work. There is a Watchdog error too.

[klonos]

If we have a separate table just for Default (like we do for Layout defaults), then we can append the "The Default will be used for view modes that have not been explicitly customized" to that table.

You beat me to suggesting this @docwilmot 👍. Something like this:

[klonos]

...basically the same UI as in the layout list. Having the "Add view mode" be an add link makes it possible to have it present in the admin bar menu.

[jenlampton]

...basically the same UI as in the layout list. Having the "Add view mode" be an add link makes it possible to have it present in the admin bar menu.

I like that too! (I also recommended the action links approach maybe 20 comments ago. ;)

I don't like the second header row in the middle of the table. That's not a UI pattern we have anywhere else.

[klonos]

I don't like the second header row in the middle of the table. That's not a UI pattern we have anywhere else.

Yeah we do. As I mentioned, "basically the same UI as in the layout list":

[docwilmot]

@klonos https://github.com/backdrop/backdrop-issues/issues/315#issuecomment-268466748 is perfect

[jenlampton]

To me personally, the help text seems out of place. No other form has such a text in it's header.

Well, it used to be all over the place, before we removed the help hooks. We've added it back into the places where it's necessary, and adds value, like on the update modules page:

I think this (views modes list) is one of the places where it's necessary, we just need to figure out how to make it add value :)

Why not just description text below the table as usual?

Can you give me an example with description text below the table @docwilmot? Where do we do that in core? (I'm not against it, but I'm not familiar with this pattern).

And its still too Node specific

I'm not against adding specific help text for each core entity, but only if it provides value. The more text we add the less people will read it, so maybe it would be better to remove the whole second paragraph?

In the design call today we did a quick review of suggestions here, and compared this UI to both views and layouts listings. @quicksketch recommended that if we move the "add view mode" link as an action link, we could also add the "Customize" action as part of that process - removing the need for a collapsed fieldset, or listing anything that's not currently customized.

Also, when manually entering the view mode machine name, the form/table doesn't fit into the fieldset.

Moving the add form onto a separate page should solve this.

We shouldnt be hiding that textfield in the fieldset, there's no obvious reason for that.

Actually, every machine name everywhere in Backdrop is always hidden (and the value is created automatically based on another field). There's no obvious reason to show it! =P

Incidentally, one major weakness of this approach is that view modes created for one bundle will only apply to that bundle.

Actually a view mode created for a Post exists for all node types, but is only "customized" for Post (by default). It can be used for any other node type, and customized for each as needed.

Apart from all that, customizing Comments and User accts still doesnt work.

I did fix user accounts in the last PR, but I'll double check that again in the next few...

There are a lot of good ideas in this issue already, so I'm going to take a stab at a new PR that incorporates these first, and then see about this new recommendation afterwards (in a separate PR).

[jenlampton]

Okie dokie, I'm going to need some eyes on these. In the first PR I tried moving Default to the bottom of the table and adding a second header-styled row. I like the style, but I don't like the usability. Default is the most important item in this list, the one people should be editing most of the time, and now it's at the very bottom, in the place of least prominence. :/

In the new PR I removed the collapsed fieldset and lower table entirely, as well as the menu callbacks and action links for "customize".

Instead that action can be done as part of "Add view mode". Now that form allows you to select which view mode to customize. You can choose either one of the existing ones (which is what people will be doing most of the time) or, if you choose the last option "Add new view mode..." you can still enter in a name for new view mode. Either way, the result is the same: the view mode gets added to the list on the Manage displays page. What I like about this approach is that it puts the new feature in about the right place in terms of it's importance. It will be done rarely, so it's less prominent in the UI.

[klonos]

I too prefer the default view mode on top for the same reasons that @jenlampton explained. Not sure about moving the non-customized view modes to another page, but it does make sense I guess. Perhaps it'd be better if it was a dialog instead of a separate page. All in all, I think that this is the best of all the UIs we've tried. 👍 @jenlampton for realizing our ideas.

[olafgrabienski]

@jenlampton The first PR mentioned in https://github.com/backdrop/backdrop-issues/issues/315#issuecomment-268939505 looks a little bit different for me, there is no action link "Add view mode". (I agree anyway that "Default" at the bottom looks good but is too far away.)

[olafgrabienski]

I'm not convinced of the new PR without the lower table. When existing view modes are hidden, some users may never know that they could customize them to their needs. If we choose that approach, we should at least rename the action link to something like "Add or customize view mode".

I'd prefer however to return to the approach of @docwilmot and @klonos with two different tables similar to Layouts: https://github.com/backdrop/backdrop-issues/issues/315#issuecomment-268466748. The only objection to this approach was against the second header row, but we knew then that it is a common pattern.

[MrHaroldA]

In yesterday's video meeting, it was also mentioned that if you add like 86 view modes to your blog content type, it's really strange to also see those (disabled) in other content types.

The latest PR fixes that strange behavior.

[docwilmot]

I don't like hiding the existing View modes either; this would only serve to reinforce the impression that they are disabled or dont exist, which is an error most people make already. It would also be strange to create a new View mode, as uncustomized and have it not show anywhere in the UI. Or to know that somewhere, somehow youre supposed to have 86 view modes but cant see them anywhere.

How about this (missing the action link):

[jenlampton]

I'd prefer however to return to the approach of @docwilmot and @klonos with two different tables similar to Layouts: #315 (comment).

There's never been an approach with two tables. Both layouts and the earlier PR used one table with multiple header rows.

The only objection to this approach was against the second header row, but we knew then that it is a common pattern.

The REAL objection to that problem is that it shows the Full content view mode to users who do not need to use it (but will use it mistakenly if they can see it). This is a UX regression from before this PR - we will be creating an interface that naturally drives users to do the wrong thing.

The duplicate headers is not really an issue, just an oddity. :)

In yesterday's video meeting, it was also mentioned that if you add like 86 view modes to your blog content type, it's really strange to also see those (disabled) in other content types.

👍 I forgot about this, thanks @MrHaroldA

I don't like hiding the existing View modes either; this would only serve to reinforce the impression that they are disabled or dont exist, which is an error most people make already.

This certainly isn't great - but it is a problem we already have today. We at least would not be introducing a UX regression, just maintaining an existing problem (and something people already know to work around). I'd rather stick to UX problems people know than introduce new UX problems people need to learn :)

It would also be strange to create a new View mode, as uncustomized and have it not show anywhere in the UI.

This is not the case. When you create a new view mode, after you you hit "save" the new view mode immediately appears (ready to Manage display) on the following page.

If we choose that approach, we should at least rename the action link to something like "Add or customize view mode".

Let me make this change and see if you like it better :)

[docwilmot]

The REAL objection to that problem is that it shows the Full content view mode to users who do not need to use it (but will use it mistakenly if they can see it).

I am at a loss as to why this is such a major concern to you @jenlampton. In the current and D7 UI it is in a fieldset because it made the UI cleaner, not because the poor users would destroy the world by clicking it. There are dozens of scary things in any CMS which are not hidden. Give an explanation, add a warning, whatever, but hiding it in a select list is not best, to say it lightly.

we will be creating an interface that naturally drives users to do the wrong thing.

How exactly does a table with a greyed out Full content mode "drive" users to "do the wrong thing"?

[jenlampton]

If we choose that approach, we should at least rename the action link to something like "Add or customize view mode".

I pushed a new PR with this change. I'm not sure how I feel about it, but I do agree we need to do something to let people know there are more view modes available. Hiding them with no indication that they exist is a problem.

I didn't really like changing the action link, since all our other action links in core are simply "Add new X". So I also tried adding a last row that could provide some more information about missing view modes in the place people would be looking for them.

I'm not sure I love either of these solutions, but wanted to post them here for you to see too.

One thing to keep in mind: both customizing and adding new view modes is an edgecase. On most sites default + teaser are sufficient. It could be a fine solution to leave off any mention of customizing view modes since so few people will ever be doing it.

[jenlampton]

I am at a loss as to why this is such a major concern to you @jenlampton.

It's a major concern to me because I care a lot about user experience :) <3

In the current and D& UI it is in a fieldset because it made the UI cleaner, not because the poor users would destroy the world by clicking it.

It doesn't really matter why developers decided to put something somewhere on a page - what matters is how real people interact with it when it's done. I'm not worried about destroying the world. I am worried about slowly eating away at the happiness of individuals, most importantly, those with the least experience.

Advanced site architects are the ones who will be using additional view modes. They will know when it is appropriate to use one (rarely), and they will know how to find them when they are needed. The beginners will not.

How exactly does a table with a greyed out Full content mode "drive" users to "do the wrong thing"?

I have explained it several times above, but I will try to do so again. Here is the use case: I am a beginner, and I want to change the way a field is displayed on a post, when it is viewed on it's own page.

I navigate to the "Manage displays" page. What I should do is change the Default. But since I see the view mode "Full content" in the list, with a "Customize" drop-button ready for me to click it, I will naturally click the "Customize" button, and begin to work on setting up another (unnecessary) view mode.

Initially, this may not seem like a too big of a mistake. But for content types that have a lot of fields, I'm creating a lot of (unnecessary) work for myself.

Additionally, as a beginner, I will not understand why my other view modes - things like RSS feed, etc - do not look like my 'Full content' view mode, the one I spent so much time creating. And this one mistake will lead to me also overriding and customizing those view modes as well - creating yet more (unnecessary) work for myself.

[quicksketch]

Between the latest two designs: I like them both adequately. I think they're both better than having a separate page listing all view modes (a la Entity View Mode or the D8 approach). I think choosing between them really comes down to how important it is that users be aware of view modes beyond "Default" and "Teaser".

For my own sites, I usually am only concerned with Default (for the full page view) and Teaser. For something like a slideshow made with a View, I tend to individually list fields instead of using a view mode. The only view mode I regularly override (usually at a later point) is the search index view mode, when I want to affect the order of search results. But I think that is an advanced concept for most sites and something I don't usually handle in the initial build-out. In those situations where I have used a custom display mode, I usually end up manually styling that output in my theme's templates and CSS; making the addition of a view mode a relatively large undertaking for a site builder.

So, all that is to say, I prefer to put the addition and customization of view modes under the action link at the top, per the screenshot by @jenlampton. I don't even find the additional row at the bottom of the table to be necessary, as in my own situations overriding/creating a view mode is so uncommon, the additional row is calling unnecessary attention to an advanced feature. And the row at the bottom doesn't match with any other UIs that include an action link (e.g. content listing, comment listing, URL aliases, etc).

[jenlampton]

I'd like to push this issue over the finish line this weekend. The last two comments here (mine and @quicksketch) are in agreement about showing only the view modes that matter on the Manage Displays page, but I heard that at the meeting the consensus was the opposite.

Without a comment here stating people's favorite I'm not sure which design to build, so I'm going to try one final approach that lists all the view modes like in @docwilmot's last screenshot (but without the customize drop-button) and see how everyone feels about that. At this point we should focus on getting something in that's close-enough, we can iterate after Jan 1st :)

[jenlampton]

Just pushed a new PR that adds the complete list of view modes onto the manage displays page. https://github.com/backdrop/backdrop/pull/1689 Showing all the view modes should make @klonos and @docwilmot happy, but by leaving off the Customize link lessens my UX concern, and solves the need for an appropriate word for Customize.

I'm going to start on getting these tests passing, but please weigh-in on this latest approach.

[jenlampton]

tests now passing, and PR rebased into two commits.

[quicksketch]

Yeah, in the last weekly meeting generally @mikemccaffrey, @klonos, and I think @cellear all agreed that they preferred the approach of showing all view modes regardless of whether they are customized or not.

I personally find the page a bit overwhelming with all these view modes on which I rarely change anything, but as usual we all have different experiences. I'm fine with either approach really.

The latest iteration helps in a few new ways:

• The Default display is now a single row instead of an unnecessary header + single row. I also like the new description text instead of using parenthesis.
• I like this description text positioning and display, it might be useful to make view modes support descriptions in addition to just a Label and Machine name (some time in the future).
• The table headers are SO MUCH better. Simply "Customized" and "Not customized" so many fewer words and just as effective IMO.

I'm not entirely sure about hiding the "Customize" button away under the "Add or customize view mode". If we're going to show users the fact they exist already, it seems obstructionist to hide the button for customizing them. If we were to add the button back, I would prefer the simple word "Enable" for the button text; even if it's slightly inaccurate, it's predictable and more consistent with other UI terminology.

I also think we can/should drop the colon character from the header rows.

[olafgrabienski]

I'd like to weigh in as well, but the Manage displays page in the last mentioned PR - see https://github.com/backdrop/backdrop-issues/issues/315#issuecomment-269882390 - looks strange. The styles to structure the table visually, for instance the bold font for the header rows, are missing, see screenshot:

PS: screenshot is from the sandbox site mentioned in https://github.com/backdrop/backdrop/pull/1689, sandbox URL: http://1689.backdrop.backdrop.qa.backdropcms.org

[jenlampton]

Thanks for noticing the missing bold @olafgrabienski, I'll look into that.

I would prefer the simple word "Enable" for the button text; even if it's slightly inaccurate, it's predictable and more consistent with other UI terminology.

I think I'm coming around to this too. If we used the word Enable instead of Customize that might also solve my concern with people using the Full content view mode accidentally. The button would enable the managing so it's not technically incorrect - just a slightly different meaning than we typically use for that word.

If that's the case, how do you feel about Reset to default vs Revert to default @quicksketch? We made a decision there for the same reasons. Maybe we should be consistent and use the same terminology everywhere?

I also think we can/should drop the colon character from the header rows.

can do. New PR on the way!

[jenlampton]

@olafgrabienski I checked on the bold and it's definitely in the css. I closed and reopened the PR to get a fresh sandbox.

I pushed a new PR that uses the word 'Enable' in the action link for the not-customized view modes. I think I like this better. It's not obstructionist by hiding the action, but is also less inviting than the word 'Customize' which doesn't communicate to the user that it hadn't been "customized" already.

I also added the bundle label in the Customized / Not customised headings, I thought that would help make it clear that different view modes could be customized (or not) for different content types.

I changed the action link back to simply Add view mode which I also like better - it's more inline with the other action links in core.

edit: I also removed the select list from the Add view mode form, and added the final tests to ensure that default settings are properly assigned to new (and newly enabled) view modes.

[jenlampton]

@quicksketch I think this is ready for a code review - the feature is close enough that we can iterate on UI changes after Jan 1st - but I want to make sure you are on board with where the code was added (field UI module) and what it looks like.

[quicksketch]

Posted a hella code review to the PR: https://github.com/backdrop/backdrop/pull/1689#pullrequestreview-14819087

Overall, in concept everything looks great, though there are tons of typos and code style recommendations.

The big things that need addressing code-wise:

• Sometimes a view mode has the property custom settings and sometimes custom_settings. This inconsistent use of underscores is terribly confusing. Is this something we've inherited, or can we fix this?
• We don't support renaming most items that have machine names (vocabularies, menus, image styles, etc) because handling the rename is always messy and frequently error-prone. We should remove renaming ability for custom view modes. It looks like renaming is disabled in the UI, but there is still a ton of code related to handling renames.
• I'd like to get entity_preprocess() removed and just fix the places where we are rendering entities to include the view mode suggestion directly, rather than altering it in.

[klonos]

@jenlampton you rock! I feel that everything is so much better in this new iteration for all the reasons that @quicksketch mentioned.

May I suggest a change in the help text and please feel free to ignore as I'd hate to start bike-shading over this issue further...

View modes are variations of how a [piece of content|user profile|comment|taxonomy term|...] can be displayed. Each view mode can be configured to have different fields shown or hidden. Also, the same field can be configured to be displayed in a different format per view mode.

I feel that this help text is better than the current one for the following reasons:

• The term "view mode" is at the start of the help text instead of the end of it (less risk that the user considers this text unrelated and won't read it).
• Small sentences make it easier to understand things.
• Each sentence after the 1st definition one actually describes what the "Manage display" button does. This way the user understands what view modes can be used for.
• I find "are often displayed differently" very vague and vague is not good for documentation/help. I feel that the suggested help text fixes that by explaining what "displayed differently" is (show/hide fields or display them in a different format).

[jenlampton]

Sometimes a view mode has the property custom settings and sometimes custom_settings. This inconsistent use of underscores is terribly confusing. Is this something we've inherited, or can we fix this?

I totally agree. Unfortunately both instances are already in core. We can change one, but I'm not sure what the ramifications of doing so would be. See underscores in field_view_mode_settings() vs spaces in entity_get_info(). Maybe we create a follow-up issue? (see https://github.com/backdrop/backdrop-issues/issues/2449)

We should remove renaming ability for custom view modes. It looks like renaming is disabled in the UI, but there is still a ton of code related to handling renames.

I tried to kill it in the most recent PRs. I'll double check and see if I missed any.

I'd like to get entity_preprocess() removed and just fix the places where we are rendering entities to include the view mode suggestion directly, rather than altering it in.

okay. I'll try that now.

[jenlampton]

Thank you @klonos @docwilmot @herbdool and @quicksketch for the reviews and feedback! I've addressed all the comments and pushed a PR: https://github.com/backdrop/backdrop/pull/1689

[olafgrabienski]

I like the new iteration very much, thank you for working so long on it!

Maybe I found another small bug: After having added a view mode for Posts, I get the following page:

• Title: Access denied
• Status message: The view mode Yet another can now be customized.
• Text: You are not authorized to access this page.

Afterwards, I was however able to customize the new view mode.

[jenlampton]

Thanks @olafgrabienski, can you please list the steps to reproduce the problem?

[olafgrabienski]

@jenlampton I can't reproduce the issue anymore. Anyway, these were the steps:

• Go to Home > Administration > Structure > Content types > Post.
• Choose the link Add view mode.
• Enter a View mode label.
• Hit the Save button.

[jenlampton]

Thanks! I may have fixed it with the last push of the PR. :)

[olafgrabienski]

@jenlampton I had a look at the DBlog where I found a message related to the "Access denied" error, see http://1689.backdrop.backdrop.qa.backdropcms.org/admin/reports/event/74.

At the same time there was a php notice. When you have a look at the DBlog, you'll see that some PHP notices appear also later. I guess these happened when I tried to reproduce the "Access denied" error.

[quicksketch]

There are some failing tests related to testing the old Field UI in FieldUIManageDisplayTestCase. I'll work on resolving these failures.

I also noticed that now we have restored the "Enable" link on the listing page, that these links are not CSRF protected by a token like other similar links. I can add a token and check to the access check as well.

[quicksketch]

Okay I added a commit to the PR at https://github.com/backdrop/backdrop/pull/1689. If all tests are passing, we're finally good to go on this one I think.

@olafgrabienski It appears the access denied problems may have been caused by the entity_view_mode_exists() function throwing a PHP notice because of an undefined variable. The tests were also failing on this point, but it should be fixed now.

[jenlampton]

Hm, it looked like tests were failing. I closed/opened the PR to run them again.

[jenlampton]

BACKFLIPS

[quicksketch]

This has been merged into 1.x for 1.6.0. THANK YOU everyone for the help on this issue. This was probably one of our most bikesheddy issues to date, but we arrived at a solution with which everyone seems satisfied.