Move post information settings to /admin/content/node-type/*

Perhaps in Drupal 6 theme makers will be able to make this happen through the .info files? Can someone with more experience comment?

No, .info files won't help (http://drupal.org/node/101009)
Of course this can be done easily with a node-your_content_type.tpl.php file. But bchoc suggested adding a setting to the content type creation admin page.
The problem is, not every content type has a $submitted variable. Story sets it, Page doesn't. So if the setting is present but the content type can never display the name and dates, it will be very confusing.
And the Content type admin should remain as generic as possible IMHO, with settings for only the common fields and features.

So this should probably be considered "by design", what do you think?

Actually, $submitted is toggled per content type at /admin/build/themes/settings. You can turn $submitted on for pages, it's just off by default.

Node Display of post information is handled at admin/build/themes/settings

system.admin.inc line 397

// Toggle node display.
    $node_types = node_get_types('names');
    if ($node_types) {
      $form['node_info'] = array(
        '#type' => 'fieldset',
        '#title' => t('Display post information on'),
        '#description' =>  t('Enable or disable the <em>submitted by Username on date</em> text when displaying posts of the following type.'),
        '#prefix' => '<div class="theme-settings-right">',
        '#suffix' => '</div>',
      );
      foreach ($node_types as $type => $name) {
        $form['node_info']["toggle_node_info_$type"] = array('#type' => 'checkbox', '#title' => $name, '#default_value' => $settings["toggle_node_info_$type"]);
      }
    }
  }

It wouldn't take much to add that to the actual content type page. Is there any reason we should keep it only in the theme settings?

I've modified content_types.inc locally to demonstrate what it might look like.

The code still needs some work, as it doesn't yet update theme_settings in the variable table.

Damn I totally missed this one in themes settings.
I agree, it's so easy to add/remove the submitted variable in a template file that it makes sense to move this to the content-type settings.

Another point of view, anyone?

My god, I did not even know admin/build/themes/settings was there! I've been changing all this manually in my themes. That's an entire settings page, that I didn't see in 10 months of use.

Now I know about the settings page, I agree that it doesn't make logical sense to put it here. Everything else seems to be related to the theme in general, whereas this is about certain pages. But to place it in the section where we are building the page will put it in front of your workflow when you are likely to be making the decision.

Also, this is not really a theme related option. We are not just styling and moving items around, we are actually choosing what content is being output.

+1 for the move.

Was this feature there before Drupal 6?

The only argument I can make for keep the constrictions on content types with the theme is that you may have a website where you allow your users to select which theme they want. In that case you may want some themes to show that extra node information and have others that you don't. Wait, that's not even possible because you can only alter content type's properties in the Global settings of the themes. NEVERMIND

I agree that this property alteration describes the content type, not the theme. I also agree that we should remove this option from the theme's configuration and put it into the content type's configuration.

Was this feature there before Drupal 6?

yep, admin/themes/settings goes back at least as far as 4.7

LOL, ok

So all we need to do now is roll a patch that removes the feature from the theme's settings and puts in into each content type.

Should we triage this out to Drupal 7 since its a new "feature"?

each content type, plus it must be smart enough to work with CCK so that when new content types are created it would work with them.

Someone needs to spend some time in the code to see how feasible any of this is.

:shaking head:

all everyone is looking for is to move it. Not rewrite it. my apologies.

yes a patch would need to be worked on and submitted.

Isn't it exactly at this point that previous usability ideas have failed in the past? :)
If none of us is able to code and make a patch, how shall we proceed?

you hope a core developer agrees with this , and writes a patch. Even if a patch was created core developers may not agree with the move.

Or learn how to write code for drupal, learn how to make patches, and submit your own patch for review.

I have some time to revisit this and will have a patch for D7 available shortly.

I just saw the issue and using http://drupal.org/node/138629#comment-545496 as reference, I came up with the following safe to install but not fully working code to move the information settings option in 5.7

 $form['Templating'] = array(
    '#type' => 'fieldset',
    '#title' => t('Templating'),
  );
      $form['node_info'] = array(        
        '#title' => t('Display post information'),
        '#description' =>  t('Enable or disable the <em>submitted by Username on date</em> text when displaying posts of the following type.'),
        '#type' => 'checkbox',
		'#value' => 'default_value',
      );

The above can be made to work by placing it in modules/node/content_types.inc in 5.7 in between the other fieldsets

Coding isn't really what I do and I'm stuck at fixing up the line (at the bottom)
'#value' => 'default_value',
to collect the correct value. It currently picks up the default value and well I'm stuck at finding out how to have it collect the user entered value.
The check box and description isn't going into the Templating fieldset right now as well.

Everyone's welcome to edit the code into something workable (I only had 5.7 available on hand to test out the code)

Although this issue was opened first, there is more recent activity in http://drupal.org/node/143434 which confirms my findings in creating a patch.