Undefined index: taxonomy_term in taxonomy_field_formatter_view()

I am experiencing the same issue. However, I am running the development snapshot from 10/17/2010

In addition to the default fields I have created a number of custom fields, some are text while four are terms populated by vocabularies.

Seems like there might be enough info here to troubleshoot this now.

If it's any help, I have just encountered the same error message (see attached). I think it might have been caused by creating a new alias to a taxonomy term, perhaps overriding the automatic alias, but I could easily be wrong.

Not sure where the core problem lies, but it might be affected by having the Media module enabled too. Here are my observations with Beta1:

Initially, I have enabled an image field and filefield in core CCK for several content types, including a completely new one, and they seem to work well.
I cannot add Media fields from the Media module to any content type, regardless if I disable the core CCK custom fields or not, as that causes wsod errors (not THIS error discussed here). (any of the field widget types available in Media module)

While having the core CCK fields working, no active fields from Media module (but that module is enabled), I then enabled separate "custom display settings" for full, teaser, print, etc. on the "manage display" tab for my custom CCK content type. I adjusted its default values, and set the same plus other values for each separate settings page.

That is when this error started occurring.

I think it occurs on any "listing" page that at the time of rendering actually includes one or more items from the content type that has had those settings altered. That means the front page if such content is promoted there, and any taxonomy page that would include any of those pages of that content type.

Have not had time to dig further into this, but hope these observations may help further investigations.

We were hoping beta3 would make this go away; alas, it did not.
Any other information i can provide to help diagnose?

My errors look the same as posted above; however, for completeness, i've included the output in a file.

With a little work I think I found the problem in taxonomy.module file. I changed a line (1336) in taxonomy_field_formatter_view function.
original: $term = $item['taxonomy_term'];
new: $term = taxonomy_term_load($item['tid']);

It works for me now, I hope it helps!

#13 here are my steps:
- I installed drupal
- after that I went to 'Structure' -> 'Content types' -> 'Add content type'
- I named the new content type ('show') then I saved it
- I opened 'Manage fields' and I selected from an existing field (I chose 'Term reference: field_tags' and 'Autocomplete term widget' from the lists.) then I saved it.
- In the next screen I left everything in default value then I clicked 'Save settings'
- then I clicked 'Add new content' and I created a new Article. I gave two tags to it (kutya, cica) then I saved it.
- then I added a new Show content. I gave two tags to it (kutya, lila) then I saved it.
- after that I opened the 'Article' typed content I created then I clicked on 'kutya' tag, then I got the error.

I updated Drupal from CVS today.

I hope it helps you to reproduce the error.

Thks @inf - no time to investigate right now, but reopening.

Do we know if this has been addressed in RC1?

Am unable to reproduce this following the steps in #14 above with a copy of CVS HEAD (last commit #459116) with PHP v5.2.13 as bundled with MAMP. Anyone else?

@DamienMcKenna : inf posted a db dump in #10. I didn't find the time to deploy it and test locally so far, but if you can take a crack at it ... :-)

@DamienMcKenna: I updated drupal from CVS now. I installed drupal again but I used MySQL db now. I followed the steps I wrote (#14) and I got the same error again.
I attached my mysql db dump.

Facing same issues with latest install; is there a fix in the works or a potential timeline ?

I was having this issue until I went to /admin/structure/types/manage/your_custom_content_type/display/teaser and changed my Tags field from Hidden to Link.

Same here, Hiding the Tags field on teasers causes these errors. I have several more vocabularies, all are hidden for teasers, but only the Tags is needed to be changed to Link for this error to go away.

To add some more info to this, it also happened on a Views page for me, but tags are not used at all in the view on that page, nor are teasers.

Bumping to 7.0 since that's the version I am using.

from #28, #29 (? not clear), #30 : "Hiding the Tags field on teasers causes these errors"
from #31 : "The error only occurs if I display terms for a custom content type in the teaser."

Contradiction, plus I still cannot reproduce this myself locally, either hiding or displaying the 'tags' field, either in teasers or full node page.

I'm afraid we do need detailed steps to reproduce from a fresh install, or a db dump from a site having the error (a sanitized dump, with passwords and emails removed). @inf was kind enough to provide a db dump in #24, unfortunately, it was generated before #986992: Insane etid / {field_config_entity_type} abstraction, and the dump no longer applies against current 7.x (apologies for not coming back at this soon enough).

In short : "me too" comments and screenshots are not helping. Detailed steps or a db dump, please :-)

Exact error message that appears when viewing a specific taxonomy term. I have a "Devices" taxonomy and the error only appears when viewing one (of the total of three) taxonomy terms within the "Devices" taxonomy.

Devices:

- Advent Vega (Error Displayed)
- HTC Desire
- ZTE Blade

The only difference I can see is that the "Advent Vega" term has a node (of custom content type "FAQ" attached). The other two have other content types attached, so it could be something to do with the configuration of my "FAQ" content type.

Many thanks for the dump, @jinglemansweep. I could finally nail this.

The problem happens on listing pages, listing nodes of different types, when a shared field has different display settings in each type (i.e field_taxo displayed in node type A, hidden in node type B).

Logic error in field_default_prepare_view() : The function operates on multiple entities, and thus on multiple instances. But the first iteration of the foreach ($instances) loop overwrites the incoming $display parameter, and messes it for the remaining entities.
If this results in an instance being incorrectly seen as 'hidden', the 'prepare_view' hooks don't not run. Yet the formatter will run, because the instance is in fact not hidden, and field_default_view() is *not* broken ;-).
Taxonomy formatters expect the term object to have been loaded during the 'prepare view' step --> bang.

Thus, raising to major.

We'll need a test for this, but here's a patch fixing the bug for now.

Without renaming other test methods so they stay out of the way :-p.

I have applied the last patch and it solved my problem. Thanks a lot!

Just applied the patch in #38 and it has solved the problem. Thanks again!

Patch looks great, test obviously works. RTBC.

I've got the same issue and I see that there is a fix for it. One thing is: I don't have experience applying patches
Do these patches integrate without any issues? I was advised to disable and backup all the modules before applying any patch, which I think makes sense.
But do I need to disable all modules that come with drupal core?
+Do i save patch above to the drupal root folder or somewhere down the tree?
+Which one of those 3 I should apply? (36, 37, or 38?)

Any advise will be helpful.
Thanks for getting solution for this problem so quickly.

Sash.

@sashkernel
I'm a pretty basic user as well, but maybe this will help...

When something is committed to head, you can go get the latest development release and install that. Otherwise you can apply the patch by hand by looking at the patch report - removing the lines with minuses and added the lines with plusses.

Installing the latest D7 worked to correct this for me. I imagine there are many bugfixes in there that would make it worth the gamble of going with a dev release.

Automatically closed -- issue fixed for 2 weeks with no activity.

to #48: just a simple answer to a simple question would help too ;-)

I get this error every time I choose to: Add existing field.

No need to subscribe, nothing will happen here anymore. The fix has been committed to the 7.x-dev branch, and will be part of the next core release (7.1). Meanwhile you can download a tarball of the current state of 7.x-dev on http://drupal.org/project/drupal.

I realize that this is "fixed" in 7.1, but is it not considered best practice to actually check for the existence of an array key before you use it?

Should the offending code block in taxonomy_field_formatter_view() not be wrapped in a isset() check?

@yched: One of the problems, though is not being able to debug the problem without (temporarily) hacking core, so would it be so bad to add in a watchdog statement for invalid data just to record the invalid nid?

@Snicers : that is a different issue, which should be reported in the Media module issue queue (if it hasn't been already)

This was committed with automated tests several months ago, so if you're seeing the same error or a similar one, it will be a different root cause. Please open a new issue.

I found this in 7.9 when I had hidden the tags in default view but not in the teaser. I just edited the content type: manage display and hide tags in both views. Hope this helps.

The other issue was the right one, I've bumped priority on that one though.

Confirming that this fixes the error.

It's a shame to have to hack core but at least it works

Please follow up in this issue: #1075998: Notice: Undefined index: taxonomy_term after re-using term reference fields. We need steps to reproduce the problem in that issue. It may be caused by a contributed module.

thanks, that work for me too. TQ.

In my case applying #71 sollution caused another bug:
Fatal error: Unsupported operand types in /modules/node/node.module on line 1361
Any ideas?

#71 fixed this for me too. My trouble seems to have started when I somehow built duplicate taxonomy names called "catalog" because I couldn't figure out how to get ubercart to list products. The taxonomy implementation into Ubercart seems fairly new, so I'm thinking something there may have caused my particular issue.

@dynamicdan: Please open a new issue with explicit steps to reproduce the error you're getting. So far everything points to this being caused by bad code in contributed modules.

I have this problem with ubercart products (www.riberbike.es)

but only when terms has more than one product :) on 1rst and 2nd block (list) taxonomy
ej: "Peugeot" have troubles (many products for this make),
but "polisport" no trouble >> only one term in this make.

#71 do not work for me.

>>> 3rd block taxonomy: no problem even if more than one "product" included in this term
because (???? mmm) 3rd block have a class defined in shop (ubercart > bike accessories )
1rst & 2nd block haven't class defined in ubercart (default product, bikes) It could be the reason ????

thanks for help.

------ edit

No troubles in terms like "Origin-8" in the 1rst block because many products but alls from accessories, i.e: from "defined class" in ubercart shop.

So only problem with terms linked with "ubercart: default product class", not with terms "from" ubercart defined class. !!! I hope it can help for reproducing this issue. thanks

Ugh. I had to resort to #71...

The issue for me is simple to reproduce. Any ubercart product node with attributes results in an $item array that lacks the taxonomy_term key and therefore it borks.

For performance reasons, I tried to not load every single time, so here was my hack.

Obviously, use with care and realize the upcoming 7.13 will break this.