$tabs and $title do not display on nodes from newly created content types

Problem/Motivation

We are working in a subtheme of Omega (7.x-3.1) called Usability, and seeing issues with titles and the primary tabs (Edit, Track, etc) displaying in nodes based on newly created content types, but not with existing content types such as Basic page, Article, etc. The primary use case is:

1. View a node with an existing content type such as Basic page. See primary tabs and titles OK
2. Create a new content type, defaulting everything. Call it 'BareBones' for convenience. Create appropriate edit, view permissions for the new type
3. Create and view a node of the new type. Note that both title and primary tabs (Edit, etc) are not displayed
4. Verify that $tabs and $title are available in terms of permissions at the page level, by printing them out from page.tpl.php. The issue is therefore content generation and rendering, not permission

Note that this problem is reproducible in multiple subthemes ... we've reproduced it using an unmodified more-widely-used Respond subtheme, for instance.

Proposed resolution

Could someone please explain (note our efforts to date in remaining tasks) how to enable display of $title and $tabs on newly created content types in Omega subthemes, and in general how to control presentation on these new content types, as we seem to be missing something with the ordinary mechanisms (see Remaining Tasks for some history of what we've tried)

Remaining tasks

First, let me describe the attempted 'right way' to fix the issue, and our problems. Then I'd like to describe an only partly-successful kludge. We would appreciate advice on either, although 'right ways' are of course better.


'Right Way' Observations

• Our initial observation is that the content area where the tabs and title should appear is governed by the templates/region--content.tpl.php template.
• templates/region--content.tpl.php is being applied to, and generating correct content for the older preexisting content types, but it is not applied to nodes from newly created content types. This is the root cause of the problem
• We have experimented with manually injecting a $vars['theme_hook_suggestions'][] = 'region__content__barebones' ; statement into templates.php to force the application of region content to the 'barebones' new content type. In this case we see that a newly created templates/region--content--barebones.tpl.php template is indeed applied to nodes of type barebones.
• However even though the content-type-specific region template is applied, $tabs and $title do not render
• A kpr($variables) statement in region--content--barebones shows a very different set of $variables compared to a similar kpr($variables) statement in the templates/region--content.tpl.php which is applied to the older content types but not to the new ones. Specifically $tabs and $title are missing(!) from the barebones context and cannot be printed




So on this 'right way' path we're stumped.

1. How could the generic templates/region-content.tpl.php not be applied to a new node of new content type, given that there is no possible override for the new type? After all, it's new!
2. When we do create a template override for the new type, and force its recognition by a theme-suggestion, why is its context missing the $tabs and $title elements?

We would like to find what template actually is rendering the new nodes (before forcing the template-suggestion) but cannot figure that out. If we knew what was generating the (default, nonoverridden) display of the new nodes we could insert $tabs, we hope.

Kludge and Kludge Questions
So, in an attempt to move things forward we've pursued a partially successful kludge approach. But it has problems and we would appreciate any insight. Again, we don't think this is a bug, but a misunderstanding on our parts.

The essence of the kludge is an attempt to:

• Inject the $tabs into the context of the node. Our observation is that $tabs is available in a page context, e.g. page.tpl.php, but not in a node.tpl.php context
• The page context can display $tabs, but not in the desired content region, e.g. just above the body.
• So our kludge strategy is to inject $tabs into the node variables, and display it from node, in the correct content area
• We accomplish the injection by modifying templates.php, injecting the $tabs into the variables of the node. The idea comes from http://drupal.org/node/505672, so:
  

  // Modifications to pass $tabs to node context per http://drupal.org/node/505672
  function usability_preprocess_node(&$vars) {
          $vars['mnu_local_tasks']=menu_local_tasks(0);
  }

  Once $tabs are injected, a similar piece of code in templates/node--barebones.tpl.php picks up and renders the injected $tabs, so:

    <!-- begin print tabs and title -->
    <h1 id="page-title" class="title">
    <?php print render($title); ?>
    </h1>
    <?php $printtabs = $variables['mnu_local_tasks']; ?>
    <div class="tabs clearfix">
    <h2 class="element-invisible">Primary tabs</h2>
    <ul class="tabs primary clearfix">
    <b><?php print drupal_render($printtabs); ?></b>
    </ul>
    </div>
    <!-- end print tabs and title -->
    

• The initial behaviour is all we could want. The barebones node appears with title and tabs rendered in the correct location. But ...
• Subsequent renderings of the node, either by refreshing the page, or by clicking the "edit" tab (which effectively does the same thing, but with an overlay) generates warnings!
• The source of the warnings on refresh is definitely the drupal_render (or render) call ... both have the same effect


The error messages for subsequent renderings are:
• Warning: Invalid argument supplied for foreach() in element_children() (line 6370 of /apps/acquia-drupal-7.19.18/includes/common.inc).
• Warning: Cannot use a scalar value as an array in drupal_render() (line 5837 of /apps/acquia-drupal-7.19.18/includes/common.inc).
• Warning: Cannot use a scalar value as an array in drupal_render() (line 5892 of /apps/acquia-drupal-7.19.18/includes/common.inc).

So drupal somehow thinks something in the render isn't really an array. Manually examining the array on first and subsequent renders, using kpr($printtabs) shows what appears to be a normally formed array in all cases. But drupal is thinking something is not a renderable array the second time around. Yes, we can turn off the warning displays, but that leaves a very uneasy feeling. Help!


We'd be very grateful for any insights into either the proper way to style these new content types with appropriate tabs, or why the kludge doesn't (quite) work