Given that custom help settings for contact module and user module were migrated to blocks in #240873: Move custom help settings to blocks, we should also migrate the content type help along the same lines as suggested by catch. Opening issue to track progress here.

CommentFileSizeAuthor
#3 remove-content-type-help.patch4.23 KBGábor Hojtsy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

I am not entirely sure that we can do this cleanly, unless we add on a new page visibility setting saying "we are on node of type ...", where type is selectable. That would be a new "content type specific visibility settings" section. The reason is that the code has these conditions currently:

/**
 * Implementation of hook_help().
 */
function node_help($path, $arg) {
  // [...]
  switch ($path) {
    // [...]
    case 'node/%/edit':
      $node = node_load($arg[1]);
      $type = node_get_types('type', $node->type);
      return (!empty($type->help) ? '<p>' . filter_xss_admin($type->help) . '</p>' : '');
  }

  if ($arg[0] == 'node' && $arg[1] == 'add' && $arg[2]) {
    $type = node_get_types('type', str_replace('-', '_', $arg[2]));
    return (!empty($type->help) ? '<p>' . filter_xss_admin($type->help) . '</p>' : '');
  }
}

So the content type specific help is displayed on node/%/edit pages where the node is of the given content type (this is where we'd need the per-content type visibility setting). The help is also displayed on the node/add/$typename page which can be easily done with the current page specific visibility however.

Not that it is not a highly requested feature: http://www.google.com/search?q=drupal+content+type+specific+visibility However having even more visibility settings might complicate understanding of how they interact. Is there and AND or OR relation between them? For this patch, we'd need AND obviously, which is how Drupal works by default (a block needs to conform to the user roles, the page visibility by path and by user custom settings alike).

Implementing node type based visibility sounds like a straightforward thing to do by extending the _block_load_blocks() functionality and using menu_get_object() for the already loaded node. Then users could set up help for the node/%/edit and node/add/$typename pages with the node type visibility set, so all applying at the same time users should get the help as they did in 6.x. Having per-content type specific visibility would make many more users happy beyond having per-content-type submission help guidelines.

Gábor Hojtsy’s picture

Assigned: Unassigned » Gábor Hojtsy
Status: Active » Needs work

Ok, took a stab at content-type block visibility. It turned out to be quite easy, but would not cover up under this issue, so adding on a new issue to my pile: #453254: Re-introduce per-content type visibility to block settings :) Once per content-type block visibility is in place (if it is), we can get back to this issue and solve this one with a reasonably simple upgrade path and some code removal.

To be on topic for this issue, here is a relevant patch with the code we are going to remove. Upgrade path not included, since it obviously depends on the per-content-type visibility.

Funny thing is that per-content-type visibility was a feature in Drupal 4.6 and removed in Drupal 4.7. Heh :)

Gábor Hojtsy’s picture

The missionmissing patch.

catch’s picture

subscribing.

sun’s picture

Status: Needs work » Needs review

How much of this passes?

Status: Needs review » Needs work

The last submitted patch failed testing.