Description desirable at head of new content page.

[Graham-72]

In the listing of content types available from 'Add content' in the admin menu, each type of content has a description. However, if a user makes use of the drop-down menu to go straight to the type of content needed, the 'Create xxxxx' form appears with no description. Perhaps usually this is of little or no importance but I have found there are circumstances in which I would like the description to appear at the head of the form. It would then be possible to use the description to advise the user of any particular requirements or restrictions.

[serundeputy]

This adds the node type description to the node/add/{node-type} form, but I don't know how to get it to be separate from the title.

patch: https://github.com/backdrop/backdrop/pull/1325.patch

Website: http://1325.backdrop.backdrop.qa.backdropcms.org
Username: admin
Password: tnfVd7yi

[Graham-72]

@serundeputy Thank you very much for this. I have applied the patch and it does just what I hoped. Because of the markup you have included I have been able to add a style to the stylesheet for seven (in my case) to reduce the size of the description text.
p.node-add-description { font-size: 0.85em; }
Here is an example of what it now looks like

[ghost]

I'd be a bit reluctant to put a paragraph inside a <h1> tag.
Just tried a good old form alter :

/**
 * Implements hook_form_BASE_FORM_ID_alter.
 */
function ckeditor_addon_form_node_form_alter(&$form, &$form_state, $form_id) {
  if (!$form['nid']['#value']) {
    $bundle = $form['type']['#value'];
    $description = _node_types_build()->types[$bundle]->description;
    $form['description'] = array(
      '#type' => 'markup',
      '#markup' => '<div class="description">' . $description . '</div>',
      '#weight' => -10,
    );
  }
}

Could probably be inserted at the end of node_add_page()

[klonos]

I have to admit that rendering this as a div with a description class and in fact doing so outside the page-title h1 has better results IMO:

...as a matter of fact, the way it is now, the description text is appended to the actual page title (the browser window/tab title that is):

That shouldn't be happening.

[klonos]

This is related to #796 and/or #1704 (which is actually a follow-up of #952) and could be covered by https://github.com/backdrop-contrib/blockify and/or https://github.com/backdrop-contrib/custom_header_block but I'd really rather have these as core features (expose this as a "Content type description block").

This way (having it as a block):

• People would be able to choose if they want to place this or not in their admin theme. With the current implementation here, we are hard-coding it and would need to provide an enable/disable checkbox. Either that or have people hide it through css.
• People would be able to choose where to place this through the Layout admin UI either as the last block of the page title region ([UX] Move the Page title settings to a dialog. #952) or as the first block of their main "Content" region.
• - By having it as a block, we allow people to choose how that description would be rendered. They can use the features that we already have in place in order to render it as a div or a p or what-have-you and also add custom classes to it.
• If along the way we decide that this is a UX+ (I personally think so), then we can add it by default out of the box in the core admin theme.

[quicksketch]

I'm with @gifad in thinking this should just be a part of the $form array. For now we can just use #markup, but I'm also in favor long-term of created a #type = 'help' element.

Using a separate type of element would give us nearly all the benefits @klonos mentioned above: controllable, alterable, and themeable through the theme. But it wouldn't require/allow the user to position the help block. I personally find that fine. With it being a block, it's possible or even likely for a user to accidentally remove the help. I think that should be left to the theme or a contrib module if needed.

This issue is a duplicate of #1534, but as this has more discussion happening I've closed that other issue.

[docwilmot]

We did this already.

[opi]

I can't see the content type description on the node/add/<type> form, and didn't know this old issue. I think this could be a nice (and cheap) UX improvment

[docwilmot]

This isn't set for the default node types on install; it wasn't set for Drupal on install either. But now a description can be set for any node type, by filling in the "Explanation or submission guidelines" field for content types. So this issue is fixed.
If you wish for a description to be set on install for Page and Post types, please open a new issue.