Title setting in views UI does not indicate when the title might be overridden

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

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.

It's a usability bug. :)

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.

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.

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.

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.

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.

Filed #1963368: Move "no results behavior" into the second column of the Views UI.

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.

Filed #1963448: Add a tour for the node frontpage view.

@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.

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.

I am still facing the same issues. In my case when data not available in content then title is getting hide, but I wanted to show title in all condition. For that I also added override title tag in no result behavior, but in global replacement pattern i am not able to see title's name only showing it's id or other many things. For better understanding check -> Hide title when no content available in view

This came up as a random triage issue for Bug Smash. I'm having trouble agreeing that this is a bug. Nevertheless, in my opinion, it doesn't seem like the "Title override" area handler is an appropriate use of area handlers.

The AreaHandlerBase is the base class for "Plugins governing areas of views, such as header, footer, and empty text." The title of the view is not one of these areas. Instead the Title handler misuses the preRender method to change the title of the view, which should be out of its jurisdiction.

Another point to support this argument is that you can add multiple "Title override" handlers to the same area (No results behavior). The last one wins out.

It seems there ought to be another way to specify the title when there are no results. Or perhaps there needs to be another way to define "behaviors" (such as overriding settings) rather than hijacking "areas".

Happy to hear arguments as to why this should remain the way it is.

The views UI has changed since this was created, in a way that helps address this issue. Instead of being tucked away in Advanced, the title override is clearly visible in the page:

So I also think it's not a bug, but for the reasons mstrelan outlined, the current functionality is not ideal. So perhaps a follow up task to modify that?

Although I have to say, in 10+ years of building Drupal sites, I never knew about this quirk of standard install and have never used the title override when there are no results! TIL :)