Notice: Trying to get property of non-object in hs_taxonomy_hierarchical_select_valid_item()

Seeing the same error, quite likely in a different context. I have few vocabularies term-referenced in user account. Users pick terms in user profile via hierarchical_select, profiles are displayed ok and everything works nicely. As soon as I enable domain_taxonomy I get this error when displaying a user profile. If I disable domain_taxonomy the error goes away.

I do not see the error any more after applying the patch.

This appears to be just one of several instances in hs_taxonomy.module where the return value of taxonomy_term_load() is not checked.

I've looked at all of those calls, and made what seem like the appropriate changes (along with a fix for the related error mentioned below); however I'm not familiar with this code, so someone definitely needs to review it.

The change I'm mostly unsure about is in hs_taxonomy_hierarchical_select_item_get_label(), where I'm now returning the string "<invalid>" for the term label, but I'm not really certain how (or if) it's going to be used.

For searchability, along with the error detailed above, I had also been seeing the following when a term no longer existed. This code wasn't loading the term itself, but the tid which was causing the error was one which no longer existed. The patch addresses this as well.

Notice: Undefined index: hs_lineages in hs_taxonomy_field_formatter_view() (line 402 of [...] hs_taxonomy.module).

Works for me.

patch in #4 works for me, fixing the "Undefined index: hs_lineages in hs_taxonomy_field_formatter_view() (line 402 of [...] hs_taxonomy.module)" error. I am not changing status to RTBC, as I have not much insight into software development.

I've been using the patch for a while and haven't seen any problems, so RTBC.

firebird: Are you sure about that?

After re-reading the RTBC requirements, here's a more verbose "Works for me":

I do consider myself "an experienced developer". The patch has been in use in a largish actively developed project with five developers working on it, and no-one has noticed any side-effects with it.

I've gone through the code changes, and it looks like there are just new checks against missing or empty values, and changes in indentation. The one other change you were unsure about just returns a string to the UI level; I don't see any potential problems with that either.

That said, the dropbox functionality isn't actually in use in our project, so it might be better to hold off until someone who is using it reviews the patch as well. Back to "Needs Review".

I've been using this dropbox in development and finally got annoyed at the warnings I was seeing spewing all over the site. I spent 2 minutes and hacked a quicky solution:

using '@' on line 402

@$metadata = $item['hs_lineages'];

and using a fail safe check on line 588

return ($term) && ($term->vid == $params['vid']);

for the original bug error.

This worked fine, solving the problem perfectly to the satisfaction of my team and my client. Then I was going to post a patch for the changes so I searched here and found this issue. My patches and those proposed are technically the same, but the ones in #2 and #4 are both far cleaner and clearer, so I unwound my changes and applied the patches, and asked my team and client to review again, we give #2 and #4 a pass.

:D We're not the full community, but my vote is RTBC.

If someone could please review the usage of hs_taxonomy_hierarchical_select_item_get_label() and confirm that the change to that is going to be sane, RTBC would be appropriate.

By default it's only called by hs_taxonomy_views_hierarchical_select_item_get_label() which is implementing hook_hierarchical_select_item_get_label(), which is invoked in _hierarchical_select_dropbox_generate(). $item would be a term id, as it is passed to taxonomy_load_term()

edit:
In fact, I think that code never gets executed. _hierarchical_select_dropbox_generate() invokes hook_hierarchical_select_valid_item to clean the $selection array. That calls hs_taxonomy_hierarchical_select_valid_item() which should filter out invalid terms, and that array is the source of the data which is passed to hs_taxonomy_hierarchical_select_item_get_label()

Confirmation?

(I'd still keep the change, but it would no longer be a hindrance to getting this patch committed.)

I've been using the 'Feeds Tamper' plugin (with Feeds, of course) to match on multiple terms which uses hierarchical select.

I've ran into this error message today when trying to insert terms that are numbers using a CSV import (via Feeds).

The vocab ("Coupon Type") looks like this:
-% Off
--5
--10
--15

I'm getting the '% Off' part but I'm not setting any of the children. In fact, they're getting inserted into the db as their respective value as opposed to their tid.

If I change the vocab to look like this:
-% Off
--five
--ten
--fifteen

.....it works.

I've posted this issue in both the feeds tamper module and this one. Thanks for any advice.

AaronELBorg: By "this error message", are you referring to the subject of this issue?

And if so, have you actually tried this patch?

I'm unsure whether the remainder of your comment is related to this issue. You might also like to link to your duplicate issue, rather than just saying that you've done that.

Yes, the error message in question is indeed the subject of this issue.

I tried #2 and although that stopped the error from being displayed it didn't fix the issue I'm having with numbers in the vocab. Haven't tried #4 yet.

Here's a link to my issue in the Feeds Tamper project:
http://drupal.org/node/1441750

Thanks for the reply.

#4 is a more comprehensive version of #2, so I would suggest using that one.

It doesn't sound like your problem with numeric terms is related to this issue.

You're correct, jweowu.

The issue was with Feeds and patched here:

http://drupal.org/node/1426762#comment-5612248

Thanks again.

The patch in #4 also solved the issue for me. The change to hs_taxonomy_hierarchical_select_item_get_label() looks fine to me. I'm not entirely sure if this case will ever pop up but it can't hurt to have a fallback when a term doesn't exist.

So considering the above and that this solved the issue for other people I'm marking this RTBC.

Patch working for me..

Thanks !!

the simple patch in#11 worked for me. But i had to combine it with another patch:
http://drupal.org/node/1324070 - because i had both the errors. Now worked. "both" the patch should, imho, committed... thanks to all! :)

Thanks jefkin @#11

francoud, msamavi: #4 is the current RTBC version of the patch for this issue.

Committed (http://drupalcode.org/project/hierarchical_select.git/commit/22acf869782...) #4 with the exception of:

diff --git a/modules/hs_taxonomy.module b/modules/hs_taxonomy.module
index bb83b25..666728f 100644
--- a/modules/hs_taxonomy.module
+++ b/modules/hs_taxonomy.module
@@ -704,6 +704,9 @@ function hs_taxonomy_hierarchical_select_item_get_label($item, $param
     }
     else {
       $term = taxonomy_term_load($item);
+      if (!$term) {
+        return '<' . t('invalid') . '>';
+      }
     }
 
     // Use the translated term when available!

That's never been necessary in the past, so it shouldn't be necessary now.

Thanks! And sorry for taking so long…

how to relate two different vocabulary in with term ... if you have any suggestion give