Whilst building a blog in Drupal 8 I tried to change the title of the default frontpage view. The experience was quite confusing because it didn't work #1956912: Title area handler sets the title even when it should not (results in "Welcome to Drupal" never going away) and the UI is a little bit obscure...

The frontpage after installing the standard profile

frontpage.png

After clicking on the contextual edit view button

huh.png
The title seems to be none?!?!?!?

Well I can't see any other title setting so lets change it

setting title.png

Yep this looks good!

saved.png

... but the frontpage does not change!

What I should have changed...

reality.png

Files: 
CommentFileSizeAuthor
reality.png392.27 KBalexpott
saved.png338.12 KBalexpott
setting title.png290.39 KBalexpott
huh.png319.41 KBalexpott
frontpage.png235.21 KBalexpott

Comments

xjm’s picture

Title: Title setting in views UI can be confusing » Title setting in views UI does not indicate when the title might be overridden
Category: task » bug
Issue tags: -User interface +Usability

So, I almost filed this exact issue. While the biggest WTF here is from #1956912: Title area handler sets the title even when it should not (results in "Welcome to Drupal" never going away), I think we do need to indicate in the UI when the title is sometimes overridden (because of argument handling, no results behavior, or whatever).

This hasn't come up in the past because usually someone would have created the view and set the title--so what they were overriding in circumstance X would have been clear. However, we're going to be shipping a lot of default views in D8, so it will become very common for a site builder to want to configure a title for a view he or she has not built.
Related: #1957276: Let users set the block instance title for Views blocks in the Block UI

damiankloip’s picture

I would say these are loosely related things; the block issue is to set the title of something outside of views (probably easier to solve), and this is only internal to views.

I'm interested to hear how this can be solved tbh.... :) Where would you display is the title is overridden? and how do you know it's overridden? There would have to be some additional method or key in the definition to determine this I think. Suggestions to remove the handler I would say wouldn't be a good idea.

EDIT: Just noticed this was changed to a bug report. really? It's not really a bug is it? The current behaviour is exactly what's intended.

xjm’s picture

It's a usability bug. :)

yoroy’s picture

In general, the approach would be to try and group related settings together. A way to move the 'global: title override' setting over to the basic 'Title: Title I like' part of the UI.

dawehner’s picture

Just in general, we should try to avoid to start making bad code decision and end up in a hard to maintain system.

Wouldn't it already help to give that this a better title and not hide it anymore for the users (for example move the empty settings to the middle column)? I personally think that the empty text of a view could be used maybe even more then the header/footer, but that's just a feeling.

xjm’s picture

Just in general, we should try to avoid to start making bad code decision and end up in a hard to maintain system.

Uh, who is advocating bad code decisions? :) I don't see any comments that say "Let's fix this with a quick-and-dirty hack that will bite us in six months."

I agree that the empty settings are used at least as much as the header/footer, at least in my experience, so I would agree with moving that out of "Advanced." However, the global overrides and area handlers are sort of a difficult concept to explain to users, and that's not a nut we're going to crack in this issue.

What I would like to do is indicate next to Title: that it is overridden by X or Y. This becomes complicated if we want to indicate in the UI when other things may be overridden as well, but the title is important right now because we need to come up with a clean way to illustrate that the view title is a dynamic thing for #1957276: Let users set the block instance title for Views blocks in the Block UI.

damiankloip’s picture

I would interpret the "bad code decisions" as adding a special case in the UI for Title override handler.

Views generally doesn't and shouldn't have business with the workings of a handler, it just knows that a plugin exists. What we don't want to do is couple this handler to the UI code. So for this reason I would say moving this into the title section is a no-go.

Moving the empty section into the second column is a good idea though, I've never seen that as an advanced setting :)

xjm, I think there could be a possible link between your suggestion and what I have mentioned in #2, to mark the handler. This too could get messy though, not too sure without really thinking about it. People may want to add their own similar handlers or swap out the existing one.

tim.plunkett’s picture

Oooh! Could this finally be a use case for a display_extender? It could add information to the title section based on the presence of the other handler.

xjm’s picture

dawehner’s picture

As written in IRC it feels like we should first improve on all the different levels: column, tour integration, better title ... and then think about other workarounds. A display extender is something damn complicated which also potentially slows down each view. Considering this, maybe hardcoding is the better choice if there is really no other way.

xjm’s picture

xjm’s picture

@dawehner, can you think of anything in core other than the global title override and the argument title settings that change the view title?

It really would be good for both this issue and #1957276: Let users set the block instance title for Views blocks in the Block UI to have a clean way of indicating when the title is overridden, so we can display a message like this to users:

Title: A title I like
Overridden by the arguments and the no results behavior.

Also, ideally, we'd do it programmatically so that contrib plugins can also identify when they override the title, so that we can display that information both in the Views UI and in the block UI. That's why @tim.plunkett's suggestion in #8 piqued my interest. I agree with the concerns about it though.

dawehner’s picture

Title: A title I like
Overridden by the arguments and the no results behavior.

This will not make the code argument any better. This will still hardcode really special bits in there. Even if we ask all handlers/plugins, it's still something DAMN special. Well it seems to be that we have to go this route.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.