Page title block settings removes pages titles from views pages and group pages

can you give a reason why you would follow those steps? It doesn't seem to me like anyone would do that so that might be why it could have been overlooked

You are basically going to load something that runs a query against title after disabling title display and wondering why it errors?

If you want to disable the titles you should be doing it through the manage display I do believe

Blocks are global, if you enable the content type restriction, then the block will only be shown for content of the selected content types.

As the archive, contact form etc pages are not "content" and will not match the content type, the title wont be shown.

What it sounds like you actually want is to disable the title in the content type, which means visiting admin/structure/types and then manage your content type, and the display of that content type and drag the title to disabled.

Or write your own .twig that no longer displays the title for you content type.

What you are experiencing is not a bug, but a feature that has effects you were not expecting.

@singularo is correct, this is not a bug.

If you need/want something more than what core provides, you will either have to find an existing contrib module (possibly https://www.drupal.org/project/block_visibility_groups) or you will have to custom code something to fit your needs (possibly creating a new contrib module if enough people like it).

This is called site building.

Not everything works "out-of-the-box" to suite your specific needs.

You where not able to reproduce this because you where not interested in this issue (see related issue).

I could reproduce your particular issue. What I could not do was reproduce it due to that project.

That's the reason I set that issue's status to that: because it had nothing to do with that particular project's code (e.g. it wasn't specific to that project, thus not reproducible with its code).

I since changed it to "Closed (works as designed)" after also reading this issue.

This is an issue that concerns hundreds of people and so this cannot be closed by one developer, who is not interested in this issue (as we could see in the related issue).

You're only making this grandiose claim to gain sympathy to your frustration with no actual tangible proof (e.g. hundreds of users or code to back up this claim).

NOW change the settings of the "Page title" block in blocklayout /admin/structure/block and enable the page title only for articles.

That is simply how the node_type block visibility @Condition is designed.

The node module is what provides the NodeType @Condition.

The block module uses this @Condition from the node module and renames the label to Content types in BlockForm::buildVisibilityInterface.

That means that if you select the article content type in the Content type visibility section of the page title block, then only full node pages (e.g. /node/1234 or their path alias) that match the selected node type(s) will show this block.

Other pages (e.g. system paths, views pages, etc.) that do not match this condition will not show this block.

This is how blocks have always behaved. The only thing that has changed in 8.x is that the page title is actually now a block and no longer a theme variable in a template (probably why you opened the issue in the base theme to begin with).

You should probably be using path conditionals instead of content types anyway.

This is also why other contrib modules and hooks for determining block visibility exist.

This is not a "bug".

YOU (markcarver) can not decide this.

I didn't initially close this issue, @singularo did. I merely agreed with that decision because it's clear that there isn't a real issue here.

The only real issue is your understanding and perhaps confusion with how block visibility works.

---

As a side note, I think it's worth mentioning that I did get your personal email and private messages on slack about this particular issue. I'm sorry that I didn't get a chance to review the "issue" in a timely manner (I have a job and life), but such is the way with open source.

For the record, I don't appreciate the personal attack for simply coming to the same conclusion as another developers (e.g. it's not just me here).

Yes, I re-closed this issue because this is simply how this block visibility is currently designed.

Even if you don't agree with that, there's already issues out there (e.g. #2284687: Redesign UI for better management of block visibility) that center around redesigning the UI to make more sense. However, those are tasks/feature requests and would still make this a duplicate of them since they're both after the same goal.

It's also, likely, why https://www.drupal.org/project/block_visibility_groups was created (as a contrib prototype) to flush out the UI/details before likely merging it into core as an experimental module and ultimately a stable core module.

Regardless, your "issue" certainly does not justify spamming multiple issue queues or individual people to just garner free support.

Please be respectful.

I realise this is a closed issue but just wanted to note that this totally caught me out too. Without digging through internals its not immediately obvious through the UI the effect of hiding the page title block on certain content types has on the block visibility in other situations. The simple workaround in my case was to use path conditions as markcarver recommends.

I, too, want to add that the problem here is not at all clear. To anyone new here, the problem is that you likely sometime visited:

Home > Administration > Structure > Block layout

and wanted to configure the settings for the block "Page title" in the tab near the bottom under "Visibility" called "Content Type" to hide the title in a specific content type. It looks straightforward and you click say "Article" and "Negate the condition" (which itself is an odd phrase).

This turns off the title for content type "Article" but also turns off all titles in views. And so when you create a view you spend hours digging through your twig files and wracking your brain to figure out wtf is going on.

So, to fix it, uncheck the boxes above (in the Content Type tab of Visibility" and INSTEAD go to the tab "Pages / restrict to certain pages" and enter the path for the content type (I'm guessing you're using Paths!) and enter something like /articles/* and check the radio button "Hide for the listed pages".

Hopefully, that will fix this issue for you.

Disregard the vitriol above, because the people saying "this is how block visibility is *supposed* to work" are simply not looking at the issue from the point of view of someone less knowledgeable about the inner workings of the code.

I think there is a first ambiguity to resolve here.

Default core UI is this:

In my current project, I have an additional option (at the moment I can not tell what module/option has added it):

(Could someone clarify from where above additional option comes from?)

Anyway, in both cases, we have an usability issue.

UI here suggests users something that is "apparently" clear, but then hides some (important) consequences that the user has not been warned about.

Let's try to do a short UX analysis on the second screnshot:

What the core UI suggests here? Assume an hypothetical user journey (a common user that cannot know the whole history of Drupal blocks implementation):

So, following the proposed reading order, we have:

1. First label "Visibility" -> user: "mmm ok, I can manage the visibility of this (page title) block." Potential improvement: May be a better explicative label could have speeded up the cognitive process, e.g "Manage visibility for this block" or "Block visibility" (repetita iuvant...)
2. First ambiguity -> user: "ok, I see a sequence of tabbed options. But what's the difference form first Content type option and second Content types option? Both options shows me the same list of content types, the only difference is the "negate the condition" offered by the first option... Does these apparently identical options do the same thing? What happens if I use both checking different values? The final effect will be a combination of these 2 options? In any case lets proceed..."
3. Active label "Content type" of first default opened vertical tab -> user: "mmm, tab label says Content type, so, in combination with the previous visibility label I deduce that I can set the visibility of this block per content type in this area"
4. Third encountered label "Content type" in the tab area -> user: "mmm, another label Content type, OK! I got it!" Potential improvement: avoid this redundancy and use this label to explain the action a user can do, e.g "This block will be visible in:" with and additional explanation text like "Select content types where this block will be visible. If none selected, it will be visible everywhere"
5. Last encountered option: "Negate the condition" -> user: "mmm, what does it mean? I think it will negate what I've checked above, so If I select "Article" and "Negate the condition" the effect will be that the block title will be visible everywhere except in the Article content type: ok! This is what I want!!! lets do this: save this settings!"
6. Final result: User frustration due to the not expected result: the node title block is not visible everywhere except in the Article content type as "promised" by the UI, but it is also not visible in ALL non node pages in the site.

Above scenario can be applied to the default core block visibility UI also (first screenshot). I think that a general explanation text could help user to understand what their actions do here, explaining him that all options setted in the "content type" tab does not affect only content types (as suggested by current UI) but have a general global impact on all other kind of non node pages within the site.

Ok, let's try closing this as a duplicate instead...

Everyone is complaining about how the existing UI is designed and there is literally already an issue for how to go about redesigning it.

Okay I know this is closed once again. But how in the world to you get you blocks back after you edited the settings?

I have tried installing and re-installing the theme but nothing seems to bring back the block title. Not only that but I can't get the page titles to show up on any theme once it has been edited.

This seems like a MAJOR bug.

I second what @kclarkson says. This is definitely a bug. Setting visibility settings for content types shouldn't affect Views titles (or any titles except on that content type).

I was completely baffled as to why my Views page titles weren't showing up anywhere, until I found this issue. Apparently, someone at some point set the page title block visibility for content types, but the result was that Views (and maybe others, I'm not sure) page titles disappeared and won't reappear no matter what I do.

On the page title block visibility settings, although no content type is selected, it is showing the whole list of content types instead of "not restricted". Selecting them all and saving does nothing. Selecting them all plus "negate the condition" (whatever that means) does nothing.

This is definitely a bug which majorly affects site builders, and I'm baffled by the dismissive response of the maintainers.

Absolutely, the most confusing 'feature' in Drupal 8. Wasted a lot of time trying to figure out where my view titles went. I would say this is a bug... and not how blocks worked in Drupal 7. In addition, you can't set a custom title (a 'better' word would be 'label' as that is what it's called in the template) for a title block.

...and not how blocks worked in Drupal 7

Actually, this is exactly how blocks have always worked. I think you're confusing the fact that the page title in 7.x was a theme variable and that it became a block in 8.x.

In addition, you can't set a custom title (a 'better' word would be 'label' as that is what it's called in the template) for a title block.

By default, no... because it doesn't make sense to show it for a page title. That's why the template removed it and only shows the contents: the page title. However, you could easily add it back to the template in your theme, again, don't know why you would...

I know this is closed but this is definitely a problem if not a bug, and this issue runs deeper than just in page titles.

Weather or not it's "working as designed" it still remains true that, while you can specify on what nodes you want or don't want a block to appear, you can't specify that you DO want them on all views pages. This is a serious oversight if negating nodes means also negating views.

There should be an option to "Add to Views Pages" in addition to nodes, more than just through paths, especially considering that setting negate on nodes overrules the path settings.

As it is right now there's no specific way to control appearance on views pages at all.

This may not be a bug, but it's a nasty Drupal WTF. A common use case that you'd think would be simple, with a UI that seems to offer it.

I used this as a workaround:

/**
 * Hide the page title for some node types while still showing it
 * on all other node types, and non-node pages.
 *
 * Implements hook_block_access().
 */
function MY_MODULE_block_access(Block $block, $operation, AccountInterface $account) {
  $disallowedTypes = [
    'MY_NODE_TYPE',
  ];

  if ($operation === 'view' && $block->getPluginId() == 'page_title_block') {
    $node = \Drupal::routeMatch()->getParameter('node');
    if ($node instanceof NodeInterface) {
      if (in_array($node->bundle(), $disallowedTypes)) {
        return AccessResult::forbidden();
      }
    }
  }
  return AccessResult::neutral();
}

This is definitely a bug.
I hope it will be solved soon
thx jonathanshaw fot the workaround module

Yes @realgiucas, after testing Page Manager, Display Suite and Switching themes, this looks to be a core bug. The Page Tile Block does dont show up anywhere. Could be a conflict with Drupal Commerce but that's just a guess I'm throwing out there. FYI: Using Drupal 8.8/Thunder with everything up-to-date.

Ok, from all my research it appears that this issue is caused by the Chaos Tool module, so you could disable that. Unfortunately modules such as Pathauto have a dependency on Ctools so that's not an option.
I ended up writing a custom block that displays the title when a Views page is shown, and added it in the Block Layout. The good thing about this is that nothing is changed; and if Ctools is ever fixed you can just remove this block from the display.
Add the code below to a new or existing custom module:

namespace Drupal\[your_module_name]\Plugin\Block;

use Drupal\Core\Access\AccessResult;
use Drupal\Core\Block\BlockBase;
use Drupal\Core\Form\FormStateInterface;
use Drupal\Core\Session\AccountInterface;

/**
 * Provides a Title Block for Views Pages.
 *
 * @Block(
 *   id = "views_title_block",
 *   admin_label = @Translation("Views title block"),
 * )
 */
class ViewsTitleBlock extends BlockBase {

    /**
     * {@inheritdoc}
     */
    public function build() {

        $route = \Drupal::routeMatch()->getRouteObject();
        $view_id = $route->getDefault('view_id');
        $title = $route->getDefault('_title');
        if ($view_id && $title) {
            return [
                '#type' => 'page_title',
                '#title' => $title,
            ];
        }

    }

    /**
     * {@inheritdoc}
     */
    protected function blockAccess(AccountInterface $account) {
        return AccessResult::allowedIfHasPermission($account, 'access content');
    }

    /**
     * {@inheritdoc}
     */
    public function blockForm($form, FormStateInterface $form_state) {
        $config = $this->getConfiguration();

        return $form;
    }

    /**
     * {@inheritdoc}
     */
    public function blockSubmit($form, FormStateInterface $form_state) {
        $this->configuration['views_title_block_settings'] = $form_state->getValue('views_title_block_settings');
    }

}

Thanks, @jonathanshaw for the workaround.
@Dru Pal,

Could be a conflict with Drupal Commerce but that's just a guess I'm throwing out there. FYI: Using Drupal 8.8/Thunder with everything up-to-date.

Nope, no Commerce but issue is still encountered, also running the latest D8.8 core and modules.

Seeing the insane back and forth that went on at the start of this issue report (for an issue which I just tripped over, by the way), I find it hilarious that no one ever thought to click the "Negate condition" checkbox on the Content-type restriction for the block. Clicking that box is supposed to reverse the condition check so that content-types that AREN'T checked are the ones that get the titles.

Less hilarious is that even doing that, the problem still persists (views titles get dropped), thus making the coding logic itself actually flawed and, in my view, an actual coding bug, not just a UI/User bug, which it obviously has been for years now.

I personally think Drupal could do with far fewer WTFs-per-minute, and I believe it's a lack of attention to that which ultimately drives folks to other CMSs even when Drupal's capabilities and architecture are superior.

Wow, I would've never thought the block title of a view page would be controlled by the system title block. How does that make any sense at all? Thank you for creating this issue! I would've never figured it out.

For those of us building complicated layouts that are different per content type, we need to do most of our layout work at the node.html.twig level, and the title often needs to be rendered within that layout. The title block is usually not useful as we cannot have a block region within a node template. For this reason I have the title block only showing for certain content types which apparently causes view page titles to not appear although they are seemingly completely unrelated.

As previous commenters have said: WTF Drupal?

Ok, I have a different work around. Put this into your theme or custom module. What this accomplishes:

1. Whether or not $title is rendered in views-view.html.twig is determined by whether you render it in views-view.html.twig or not. (Ground breaking, I know).
2. The system title block does not affect whether view page titles are displayed.

It's a shame we need this but oh well. It does lead me to a bigger question: Why does views UI allow us to do so much but it doesn't allow us to enable/disable the rendering of a title on a page display? All of the other variables being passed to the views-view.html.twig template are controlled by the views UI except for the page title? I'm sorry, but that makes no sense. As jptillman said, this is the sort of thing that drives people away from Drupal.

/**
 * Implements hook_preprocess_TEMPLATE().
 *
 * Preprocess views-view.html.twig.
 */
function mytheme_preprocess_views_view(&$vars) {
  $view = $vars['view'];
  $view_id = $vars['id'];
  $view_display_id = $vars['display_id'];

  // Due to Drupal core WTF, the system title block magically
  // controls whether view page titles appear. Due to the fact
  // that the system title block does not have settings for view pages
  // yet it secretly affects them, we must set the $title variable ourselves
  // to guarantee it will be available in the template. If we do not want
  // the title to display, do not render $title in the template.
  // See: https://www.drupal.org/project/drupal/issues/2887071
  if (empty($vars['title'])) {
    if (isset($view->storage)) {
      // If title is set specifically for this display, use it. Otherwise use default.
      if ($view->storage->getDisplay($view_display_id)['display_plugin'] == 'page' && isset($view->storage->getDisplay($view_display_id)['display_options']['title'])) {
        $vars['title'] = $view->storage->getDisplay($view_display_id)['display_options']['title'];
      }
      elseif ($view->storage->getDisplay($view_display_id)['display_plugin'] == 'page' && isset($view->storage->getDisplay('default')['display_options']['title'])) {
        $vars['title'] = $view->storage->getDisplay('default')['display_options']['title'];
      }
    }
  }
}

Thank you maskedjellybean!

You're welcome!

FYI, I realized that the "Override title" option when adding a contextual filter was not working (with or without my code). I'm not sure if it is related to the core title block or not. I tried reenabling the block and found it still doesn't work so I'm not sure. I'm potentially conflating two separate issues here (the $title var being controlled by the core title block and the "Override title" option in a contextual filter not working), but if you want to solve both this works for me (it is essentially my previous post plus code to "fix" the override title):

/**
 * Implements hook_preprocess_TEMPLATE().
 *
 * Preprocess views-view.html.twig.
 */
function mytheme_preprocess_views_view(&$vars) {
  $view = $vars['view'];
  $view_id = $vars['id'];
  $view_display_id = $vars['display_id'];

  // Due to Drupal core WTF, the system title block magically
  // controls whether view page titles appear. Because the system
  // title block does not have settings for view pages yet it secretly
  // affects them, we must set the $title variable ourselves
  // to guarantee it will be available in the template. If we do not want
  // the title to display, do not render $title in the template.
  // See: https://www.drupal.org/project/drupal/issues/2887071
  if (empty($vars['title']) && $view->storage->getDisplay($view_display_id)['display_plugin'] == 'page') {
    // Not sure if this is related, but the contextual filter "Override title" option
    // is not working. This fixes it and allows us to use the contextual filter value
    // as a substitution in the view page title. @TODO: This should maybe be applied to
    // both pages and blocks (all display types) if this is not working for blocks as well.
    $title_replaced = false;
    if (!empty($view->build_info['title']) && !empty($view->build_info['substitutions'])) {
      if (isset($view->storage->getDisplay($view_display_id)['display_options']['arguments'])) {
        $replace_title = false;
        foreach ($view->storage->getDisplay($view_display_id)['display_options']['arguments'] as $argument) {
          if ($argument['title_enable']) {
            $replace_title = true;
            break;
          }
        }
        if ($replace_title) {
          $replaced_title = $view->build_info['title'];
          foreach ($view->build_info['substitutions'] as $key => $substitution) {
            if ($substitution !== null) {
              $original_title = $replaced_title;
              $replaced_title = str_replace($key, $substitution, $replaced_title);
              if ($original_title !== $replaced_title) {
                $title_replaced = true;
              }
            }
          }
          if ($title_replaced) {
            $title = $replaced_title;
          }
        }
      }
    }
    // If title is set specifically for this display, use it. Otherwise use default.
    if (!$title_replaced && !empty($view->storage->getDisplay($view_display_id)['display_options']['title'])) {
      $title = $view->storage->getDisplay($view_display_id)['display_options']['title'];
    }
    elseif (!$title_replaced && !empty($view->storage->getDisplay('default')['display_options']['title'])) {
      $title = $view->storage->getDisplay('default')['display_options']['title'];
    }

    if (!empty($title)) {
      $vars['title'] = $title;
      \Drupal::routeMatch()->getRouteObject()->setDefault('_title', $title);
    }
  }
}

Adding my voice to those who were totally caught by surprise that tweaking this block in terms of which CONTENT TYPE' to show it on resulted in the Titles from VIEWS (which are not Content Types) to disappear. Seems illogical.

As a newbie and non-coder, I would like to add two cents worth to this issue if I may:
a) it is certainly not intuitive that removing titles from a content type affects views, and it takes a lot of work (and frustration) to discover what is going on. Some kind of warning in the UI would be helpful.
b) for most use cases that I have had the simple workaround is to put a "Global Custom Text" field into the view page header and style it to make it look nice.
c) This workaround does not work for pages with tabs (in bootstrap at least) as the page tabs stay above the custom text.
d) a nice solution for this case would be to have a themed region of the page called "Titles" that sits between the main navigation region and the page content region. Then one could simply make a custom block and sit it in the title region on the relevant pages.

Or is that not possible?

The solution in #28 doesn't work for me if I have an argument that overrides the title. This simpler code works for all situations for me, a combination of #24 and #28 and just letting the Views object deduce the title that applies. No custom modules, pretty simple code. This goes in the theme file, mytheme.theme.

/**
 * Implements hook_preprocess_TEMPLATE().
 *
 * Preprocess views-view.html.twig.
 */
function mytheme_preprocess_views_view(&$vars) {
  $view = $vars['view'];
  $view_id = $vars['id'];
  $view_display_id = $vars['display_id'];

  // Due to Drupal core WTF, the system title block magically
  // controls whether view page titles appear. Due to the fact
  // that the system title block does not have settings for view pages
  // yet it secretly affects them, we must set the $title variable ourselves
  // to guarantee it will be available in the template. If we do not want
  // the title to display, do not render $title in the template.
  // See: https://www.drupal.org/project/drupal/issues/2887071
  if (empty($vars['title'])) {
    $vars['title'] = [
      '#type' => 'page_title',
      '#title' => $view->getTitle(),
    ];
  }
}

Another possible workaround for this issue if you want to hide the Page Title block on a certain content type (without hiding it on views and other pages that do not belong to a content type) is to avoid using the block visibility settings for the Page Title block altogether, since it doesn't support this use case, and instead hide the Page Title block in a preprocess function for the page, such as by doing the following in your theme file:

use Drupal\node\Entity\Node;

function YOURTHEME_preprocess_page(&$variables) {
  if (isset($variables['node']) && $variables['node'] instanceof Node) {
     // Create variable out of the current node type
    $node_type = $variables['node']->getType();
    // Remove page title block.
    if (($node_type == 'article') || ($node_type == 'magazine_volume')) {
      unset($variables['page']['content']['YOURTHEME_page_title']);
    }
  }
}

See this article which provides some explanation: https://www.unleashed-technologies.com/removing-default-drupal-page-titl...

This should be reopened so that the community has opportunity to submit a patch with actual functional content type restriction that doesn't break views and page titles.

The plain and simple is, if you try to hide visibility on one content type, a whole bunch of other titles go away. Pages, Views, etc. How is this is anything but a bug? Page Title block visibility has broken functionality, as multiple people have patiently stated here...

#35 worked for me. Thanks @skudderk!

#35 worked for me. Thank you!

I had to resort to editing the `block.block.YOURTHEME_page_title.yml` and removing visibility settings related to showing the block per content type. At one point in the past someone set the page title to not show for a content type, but even if the UI says its "Not Restricted" the view/webform titles only came back after deleting these settings, and importing config.

#13 worked for me in my particular use case. Many many thanks to qsDave.

Can anyone tell me how to simply reset the title block visibility settings to the default "out of the box"?

I too stepped big into this trap, and as a result, NONE of the configuration settings for title visibility will allow a page title to be displayed. I've tried views, pages, forcing display on certain pages, etc., etc., etc., to no avail. Page titles are not visible anywhere.

I can easily hide a title with a simple line of css, so rather than mess with visibility settings, I just want to restore this to its original, unaltered state.

I don't want to write code to overwrite code which has perhaps overwritten the default code.

I'd be happy going into the database tables using SQL if there's a flag or setting somewhere which controls this?

Or, preferably, how to I restore ***specific*** files from the original install, either in core or my bootstrap theme?

Thanks

I am reopening this as the refactor blocks UI issue that is tagged is huge.

The negate condition checkmark should work as assumed by 85% of Drupal site builders. I check this box and hide the title for this content type.

Thanks to everyone who weighed in but I think there are enough people on this thread that agree this is a Drupal WTF.

Basically it seems only one condition works at a time. Maybe a good solution would be to allow users to check All conditions must pass or Only one condition must pass similar to commerce promotions:

To extend/improve core functionality, please use:
https://www.drupal.org/project/page_title_visibility
https://www.drupal.org/project/exclude_node_title

@karen s - THANK YOU!!

You are such a gem. Sometimes the easiest solution is thinking about it a problem coming from the other end. You code basically tells views yo, display the title. Now the core functionality works as intended.

Do you think this code could be added to views module without breaking everything?

The only gotcha was on is when I am customizing a term page, because it is controlled by views, there were duplicate titles. For these terms I just duplicated the taxonomy term views and then changed the contextual filter title from the argument to . And there we go.

I agree there is some gotcha here that is not clear even to someone with experience. Maybe that's addressed in the UI ticket, but there is a lot to read through.

My steps:
1. create a View page with url "catalog/%x"
2. modify Page title block: Pages > Hide for the listed pages
3. page title block is not shown as expected.
4. modify Page title block to remove the restriction (textarea empty, "Hide for ..." is checked)
5. page title block does not show; that is unexpected
6. modify Page title block to check "Show for the listed pages" (textarea is empty)
7. NOW the page title block shows

Maybe this helps someone.

Bottom line: the UI tells you there is no restriction on the Page title block. But having the radio set to "Hide" seems to have an effect that is not there when you check "Show" and the textarea is empty.

I agree that this problem should be solved in general in core. Even if this behaviour is how blocks always worked, it is very confusing and disappointing for site building.
I realized that the title block disappears from the user profile page (/user/UID) too, if I hide the title block for specific content types.

+1 here, I agree this is a problem. When hiding the block page title from a single content type, it ends up being hidden from non-content-type pages like /user* routes (login, register), views, custom controllers, etc...

This is confusing and unexpected. I think the expected behavior for any condition, especially conditions that are not met site-wide, might be something like "apply the condition only if you are actually able to evaluate it", this is, if you can't get the content type the access result should be neutral as you don't have the needed info in order to make a choice. Otherwise, we are making assumptions that might break the page.

+1
5 years later and this is still a vexing issue :\

+1 here. Still a painful exercise. I spent a good day + trying to figure this out. It turned out that I had restricted the title block to a few content types and that caused the view title to not show up on all our views. It would be great is there was another checkbox that would include views.

Elevating the status as this buggy behavior has been a pain point for many people for a long time.

FWIW I ran into this problem trying to configure the page title to only show on certain content types and certain vocabulary pages, it had the result of not showing it anywhere.

This might be related: #2535896

Just to add another voice here to say that the block visibility rules UI makes it really easy to build conflicting conditions without the UI explaining this fact. It's a complete mess and I've seen both experienced developers and newbies get lost on why their visibility rules aren't working as expected.

The best solution right now is to use Block Visibility Rules, though that adds its own complications.

This is not only for "Page title block" and only for Views pages pages and group pages, but also other "custom (not node) pages"

We need a better name.

ex.
Block visibility (access) broken using 'Entity Bundle' condition.

could it conflict between core and ctools?

Is it broken in vanilla Drupal?

p.s. https://www.drupal.org/project/drupal/issues/2860811#comment-14742526 marked as duplicate.

After some research it seems:

- This happens in vanilla Drupal
- CTools - also broken, which actually will override the core implementation - maybe should be removed from ctools.

And i think there could be solutions for patches/MRs on related tickets:
https://www.drupal.org/project/drupal/issues/2823432
&
https://www.drupal.org/project/drupal/issues/2535896

so any help there, could help here ....

In my .module file in the view preprocess, I did

$view = $variables['view'];
$variables['title'] = $view->getTitle();

And was able to use {{ title }} in my template.

Just ran across this while migrating to Layout Builder. Probably not a viable workaround for most, but thought I'd add to the knowledge. I was already using Context module for some Layout Builder block access conditions, so my workaround was to place the Page Title block AGAIN and set the new block's condition to Context's "View inclusion" condition plugin, and then select the views I want it to apply to.

Similarly, you could likely create a Context for each entity type that the original page title is excluded by the Content type condition plugin.

Sometimes you gotta get very creative when site building in Drupal.

My above comment is overly complicated. You can simply place the title block twice and specify which pages (paths) the second one should appear on.

I just ran into this odd behaviour, and agree that it's Major, and would be awesome to get fixed, since many users can spend a long time, trying to understand why the titles suddenly vanished in their Views :)

In the meantime, thanks for suggesting a pragmatic workaround until this gets fixed @darkodev. For example, you can add two page title blocks, like this:

• "Page title Content types" using Visibility: Content type
• "Page title Views" using Visibility: Pages

It works well, and I have added it as workaround in the Issue Summary.

just fyi this happens also for products (commerce). If you restrict the title to show only on specific content types, it will hide on product.
Thanks to hte workaround I was able to create new title block to show only on product/* pages