Label is always printed, when taxonomy is empty

Have you hidden the label in the content type? I did that and it doesn't show. If you have done that, then the issue would be better off in the panels issue queue as it would mean that panels is not respecting the label choices of the content type.

Let me know if you have any questions, but I'll be closing for now.

Thanks,
Dan

I'm seeing this problem, too. And not just with panels, but anywhere I use the "delimited" formatter for a taxonomy term reference field.

@danlinn: The label is displaying even when there's no data in the field. We don't want to set the label to "hidden", because we DO want the label to display when there is data in the field.

I've attached a patch against 7.x-1.x that fixes the problem.

Ok, I get it now. Thanks for the patch. I'll get it rolled in to a new release as soon as I can.

Same here with Display Suite.

It can be even simpler, the patch above checks in the end of the function if there is content to return, but this can be done in the beginning of the function.

Change:

<?php
function taxonomy_formatter_field_formatter_view($entity_type, $entity, $field, $instance, $langcode, $items, $display) {
  $settings = $display['settings'];
?>

to:

<?php
function taxonomy_formatter_field_formatter_view($entity_type, $entity, $field, $instance, $langcode, $items, $display) {
  if (empty($items)) return '';
  $settings = $display['settings'];
?>

Agree with #6. Here's updated patch.

#7 works. thanks for this small & quick patch

The patch from 7 gave me a warning, when applying so here is a slightly corrected version. All credits to cristinawithout.
Btw: I renamed the issue, since it isn't caused only when displaying with panels, as mentioned above.

forgot to attach the new patch.

(I didn't used panels but I also had the issue)

time to commit, no?

Yep, just a tad busy. I'll hopefully get a new release out soon.

FYI: does not seem to be necessary anymore when you aply #1362976: Optimizing formatter hooks.

...and I was wrong. Still necessary.

We're doing enormous bikeshedding here (patch in #3 was correct already), but since it's not being applied: here's one that adheres to Drupal coding standards :)

Credit to original poster, or everyone, or noone, or w/e.

#15 works as a charm, many thanks.

Confirming #15 works for me. How about a commit @dannlinn?

#15 works perfectly. Should be added in the module.

#15 had a "hunk offset" against 7.x-1.4, so re-rolled.

Patch in #19 does the trick for me as well. +1 on RTBC.

The 3 year old patch in #19 still applies cleanly to 7.x-1.x-dev and fixes this issue, but I but I'm not sure if anyone is maintaining the 7.x branch to commit and push to a new release.