Make node type visible on editing form by default

Patch applies cleanly, does something useful, and the coding style looks good to me. It's also nice and small, which is even better. :-)

Changing the title of the post is a bad idea and breaks with the purpose of having tabs. Won't fix the current solution.

Does this still applies to cvs?

robertDouglass: Any consensus about this patch? Or Won't fix the current solution is final?

Moving to cvs.

Moving all usability issues to Drupal - component usability.

I agree this would be a useful addition. The title of the node however should remain consistent. The simple solution would be display the node type as markup displayed on the form itself.

This would be a nice improvement. I know I have resaved unchanged nodes to see what type it was. ("your Foo has been saved")
I'd like to see a screengrab of what the patch does, it seems we're still a bit confused about Dries's comment.

New version of the patch which adds the node type as a form element

Re rolled from root of drupal

Attached wrong version of patch above.

New version of the patch which corrects a few other issues in that node type is only displayed when a node is edited and not on create. Also moved to the top of the form so as it is obvious. And hopefully the bot likes.

There's a typo in the comment as well.

And 'Node type' might use a t() too I guess.

Add t() to node type
Correct typo in comment

New version of the patch after some comments from Morbus which are detailled below:

for the end-user UI, we call it a "Content type", not a "node type". We try to limit the usage of the word "node" to end users since it's scary and doesn't mean anything.

(see admin/content/types for an example - all "content types").

You may also want to look at the params of node_get_types - it allows you to return just the name, so that you can cut two lines of code from it and just put the call right inside the check_plain(). I think it'd be something like:

node_get_types('name', $node->type);

-------

If someone can help me shed some light on why the patch is failing I would be grateful - that was the reason why I reached out to Morbus originally but he couldn't see any obvious issue :(

After speaking to Boombatower this patch applies without any syntax errors when applied to the test slaves manually

Apending patch with a suffix to trick testbot and empty patch to keep issue at CNR.

If anyone has bright ideas on PHP syntax issue that would be great...I ran out of ideas and haven't gotten back to it #332967: Detect non-unix newlines

Otherwise I think this is a failed result from when slave #8 died due to Xen related issue.

I like this, re-rolled with unix line endings.

I'm wondering if it might be better placed in a title callback though.

Compare node/add/page to node/n/edit.

A title like "Edit page: [page title]" or [page title] (page) or something?

Yes that would certainly be an valid alterntive placement for the type and I agree keeps it more in line with what currently happens on a node add.

I think the key thing here is that we the display does not affect any node based data and is clear and obvious to the user when they view the node.

In the past, we've added the content type to both edit and add forms using drupal_set_message() -- something along the lines of: "You are editing a [content type] node."

Perhaps the existing message functionality can be leveraged by creating a custom message type. The message would then exist in its own div and could be customized by the theme:

$message = t('Content type: ') . check_plain(node_get_types('name', $node->type));
drupal_set_message($message, 'content-type');

Output:

<div class="message content-type">
Content type: Story
</div>

This would be useful if you would rather not add output to the form itself.

The form item seems like a reasonable idea to me, can we have it display on one line though?

-1: yet another thing that's useless to me and that i'll have to theme out to make my users happy.

Yeah currently the only to know which content type you're dealing with is by going to admin/content/node and finding it that way (or /tracker, or somewhere else which isn't node/n/edit).

I agree with robertDouglass and catch. In my experience, the majority of users who work with more than one content type would not be adversely affected by displaying this small piece of information. At best, usability is improved; at worst, it's extraneous information. But I can't think of an instance in which it would *harm* user experience. Please correct me if I'm wrong.

Besides, if a particular user or client is so picky that they'd want it removed, I assume they're already asking for *lots* of stuff to be changed.

Re #37,38,39:

What about making it an option in the content type's submission form settings at admin/build/node-type/EXAMPLE ?

No. Making things an option in the ui shifts the burden onto the user, it's basically a cop out! :)
We should be able to make a decision ourselves. And just one person's "-1" is not enough reasoning to not do this IMO.

I do think we are spending quite a lot of screen real estate on this info though. Would it be enough to have "Submit $contenttype" as the text on the Submit button maybe?

Then I would have to say that it belongs in the page title like catch suggested in #33.

Whatever we do I would say -1 to forcing more clutter onto the node edit pages by default. I propose "Edit %type: %title"

When I first saw the screenshot of where this puts the information it was upsetting. We add the information, but do it in a way that wastes valuable screen real estate. I imagine that's what dmitrig01 is complaining about.

So, I agree with catch in #69468-33: Make node type visible on editing form by default that this should be part of the page title. If you compare the <title> element for node/NID and node/NID/edit they are the same. This makes it hard to distinguish which is which in bookmarks or in the URL bar autocomplete. I believe we should strive to have unique <title> elements on every page of the site.

dmitrig01 - does that help?

Patch and three screenshots (note especially the title at the top of the browser).

The only downside to the patch that I see is that $node->type is the machine readable name of the content type.

Also sun is correct, this should be a title callback on the menu item...I'll try to roll a patch that does this in a moment.

Also sun is correct, this should be a title callback on the menu item...I'll try to roll a patch that does this in a moment.

This works. I think in IRC we're already agreeing on dropping the "this" and the colon. Let's use the italics for everyting that's not the title itself:
Edit nodetype Title of the page.

So yeah, the title callback doesn't work since this is a MENU_LOCAL_TASK, it only changes the name of the tab, and not the page, or header title. :(

Here's a version without the colon and the "Edit %type" part in italic. This is also using the full human readable name of the content type as well, this means we get:

"Edit Forum topic Title" vs. "Edit forum Title" and
" Edit Blog entry Title" vs. "Edit blog Title"

Here's the patch, also, patch a few tests that were breaking with this change.

Looks great to me. Initially the concatenation around the t() seemed weird to me rather than just using t() with placeholders, but then I remembered that l10n folks prefer having the html outside of the string so this makes perfect sense.

I'm tempted to mark this RTBC...but will defer to dmitrig01 to find out why he was opposed.

Yeah maybe its me just not knowing how placeholders work, but I didn't see a way to keep the "Edit" part of the string in italic without making the HTML external. Course this is probably bad from a theming perspective now, but I'm not sure. Actually for translation purposes it may be better to keep the @content-type inside t() so that it will be presented to translators as a different string. (Forgot that I already did that.)

I like this better.

Just asking... is there a reason we don't do:

t('Edit @type @title', array('@type' => $type_name, '@title' => $node->title))

This seems like it would give translators more context/control.

While it would give it more control/context to translators, in #51 yoroy suggested keeping everything except the title in italics. For example:

Edit Page Title

It looks like this in practice:

What webchick suggests in #58 would give:

Edit Page Title

As mikey_p demonstrated, this is to give visual separation between the label and the title of the node.

My original patch used italics and a : to give the visual separation - which was overkill (in addition to awkward wording). I do agree that putting the node title into the t() gives more flexibility to translators.

So...

Edit Page This is a page

Great work, folks! I went ahead and committed this. I think Dries's concern at #4 was about changing the page title, which we no longer do in this patch.