Wouldn't it be cool if you could reorder the taxonomy display using CCK's manage fields UI? Well, now you can!

This makes the ordering of items much more intuitive since it's configured with the rest of the CCK fields.

I tried to create a pseudo field to move the settings into the display fields page but failed in the allotted time. It would be great if someone could step in and do this.

Comments

psynaptic’s picture

StatusFileSize
new2.66 KB

Here is the patch.

joachim’s picture

Status: Needs review » Needs work

Very cool indeed :)

+++ term_display.module	5 Feb 2010 17:25:15 -0000
@@ -85,13 +85,6 @@ function term_display_form_taxonomy_form
-
-  $form['term_display']['term_display_weight'] = array(
-    '#type' => 'weight',
-    '#title' => t('Display weight'),
-    '#default_value' => $term_display_data['weight'],
-    '#description' => t('Set a weight for term display to control where terms appear in the content body. Set a low weight to move terms to the top of the content or a high one to move them to the bottom. Applies only when display style is set to "list" or "custom". This option is for advanced usage only; usually it\'s best to leave this at 0.'),
-  );
 }

Shouldn't this stuff only get killed if content.module is present?

I'm on crack. Are you, too?

psynaptic’s picture

StatusFileSize
new3.21 KB

Yes, of course. Good catch :)

New patch attached.

nedjo’s picture

Thanks for the patch!

Rather than retaining the current weight handling, I'd prefer to remove it and use CCK's instead. So we would strip out not only the current form element for setting the weight but also all code that references those weight data.

An issue is that the current weighting approach provides a distinct weight per vocabulary (applicable to all content types), while the patch looks to provide a distinct weight per content type (applicable to all vocabularies). If we're switching to CCK, what we should have is both: a distinct weight per vocabulary per content type. So the hook implementation would look like:


/**
 * Implementation of hook_content_extra_fields().
 */
function term_display_content_extra_fields($type_name) {
  foreach (taxonomy_get_vocabularies($type_name) as $vocabulary) {
    $term_display_data = term_display_data($vocabulary->vid);
    // Only control the weight if this vocabulary is managed by term_display.
    if ($term_display_data['style'] != TERM_DISPLAY_DEFAULT) {
      $extras['term_display_' . $vocabulary->vid] = array(
        'label' => t('Term display for %name', array('%name' => $vocabulary->name)),
        'description' => t('Taxonomy terms for the %name vocabulary.', array('%name' => $vocabulary->name)),
        'weight' => 0,
      );
    }
  }
  return $extras;
}

For that we need an update handler to move over the existing settings. Something like:


  foreach (array_keys(node_get_types('names')) as $type_name) {
    foreach (taxonomy_get_vocabularies($type_name) as $vocabulary) {
      $term_display_data = term_display_data($vocabulary->vid);
      // Only control the weight if this vocabulary is managed by term_display.
      if ($term_display_data['style'] != TERM_DISPLAY_DEFAULT) {
        // Set weight value if it is custom.
        if ($term_display_data['weight'] != 0) {
          $weights = variable_get('content_extra_weights_' . $type_name, array());
          $weights['term_display_' . $vocabulary->vid] = $term_display_data['weight'];
          variable_set('content_extra_weights_'. $type_name, $weights);
        }
      }
    }
  }

And in the update handler we need to delete the exiting weight field.

Could the duplicate call to content_extra_field_weight($node->type, 'term_display'); also go in the update handler?

psynaptic’s picture

This looks great.

Do you know of a clean way in which we could add the display options as formatter options? They seem in essence the same thing: "display options".

skizzo’s picture

subscribing.

Patch #3 solved also an annoying problem that I had with term display: although all my Display Styles were set to Custom with null weight, some Content Types were displayed with terms AFTER the Body while other Content Types were displayed with terms BEFORE the Body. After applying the patch I have been able to relocate all Term Display fields as needed.

skizzo’s picture

I think there is a problem with patch #3: I applied it and it seems to work ok, I then created a new vocabulary and realized that I could not set the "Display style" (it would stick to "Default" even after saving the change). Temporarily reverting the patch I was able to set the Display style to "Custom", I then re-applied the patch.

skizzo’s picture

I noticed another quirk. I have a content type with two vocabularies, before applying the patch the terms (custom, comma separated) are displayed after the body with the correct vocabularies weight order

Vocabulary A : term
Vocabulary B : term

after applying the patch, I can conveniently relocate the term display before the body, but as a side effect the order is altered

Vocabulary B : term
Vocabulary A : term
joachim’s picture

Very weird. Nothing inside the fields (or pseudofields in our case) should be altered by this.

skizzo’s picture

Indeed... this problem may not be related to the patch: I deinstalled the patch and created 2 content types with two comma-separated vocabularies each: [A (weight -10), B (weight -9)] ; [C (weight -8), D (weight -7)] all with display weight reported to be 0. After creating two nodes, the vocabularies are listed in wrong order

in teasers [B,A] [D,C]
in full node [B,A] [C,D]

i.e.: for second content type the order is even different in teaser/full-node. I am therefore reporting this as a separate issue. Anyway, after applying the patch I see:

in teasers [A,B] [D,C]
in full node [A,B] [D,C]

Andrew Gorokhovets’s picture

subscribing.

eric.chenchao’s picture

subscribe