Upon upgrade to new version:
Unexpected term id 32 associated with [node-title]. Please report this to https://drupal.org/node/1918272.
Happens with valid term id's.

Comments

StephenRobinson’s picture

This happens with anonymous users, I have debugged and cannot reproduce:

  $node=node_load(9806);
  $tids = array();

  // Get the vids that tac_lite cares about.
  $vids = variable_get('tac_lite_categories', NULL);
  if ($vids) {
    // Load all terms found in term reference fields.
    // This logic should work for all nodes (published or not).
    $terms_by_vid = tac_lite_node_get_terms($node);
    if (!empty($terms_by_vid)) {
      foreach ($vids as $vid) {
        if (!empty($terms_by_vid[$vid])) {
          foreach ($terms_by_vid[$vid] as $tid => $term) {
            $tids[$tid] = $tid;
          }
        }
      }
    }

   $query = db_select('taxonomy_index', 'r');
    $t_alias = $query->join('taxonomy_term_data', 't', 'r.tid = t.tid');
    $v_alias = $query->join('taxonomy_vocabulary', 'v', 't.vid = v.vid');
    $query->fields( $t_alias );
    $query->condition("r.nid", $node->nid);
    $query->condition("t.vid", $vids, 'IN');
    $result = $query->execute();
    foreach ($result as $term) {
      if (empty($tids[$term->tid])) {
        print 'empty';
      }
      else{
        print 'found '.$tids[$term->tid];
      }
    }
}

scaringly when this happens, no access denied occurrs so the access control fails....

Dave Cohen’s picture

"This happens with anonymous users," makes me think you can reproduce the problem, while "I have debugged and cannot reproduce" makes me think you can't. Which is it?

The node(s) where this happens, are they tagged with term id 32? How are they tagged? Via a regular term reference field or some other way?

StephenRobinson’s picture

I have added some debug statements and the tid's array is an empty array when this happens, which is not every time, very strange

    foreach ($result as $term) {
      if (empty($tids[$term->tid])) {
        watchdog('tac_lite', 'Unexpected term id %tid associated with !node.  Please report this to !url.', array(
            '%tid' => $term->tid,
            '!node' => l($node->title, 'node/' . $node->nid),
            '!url' => 'https://drupal.org/node/1918272',
          ), WATCHDOG_DEBUG);
          /////////////////////////////////// DEBUG /////////////////////////////////////////////////////
          watchdog('tac_lite_debug - Unexpected term id', $term->tid . ' not found tids=<pre>'.htmlspecialchars(print_r($tids,1)).'</pre>');
          watchdog('tac_lite_debug - Unexpected term id', 'vids=<pre>'.htmlspecialchars(print_r($vids,1)).'</pre>');
          watchdog('tac_lite_debug - Unexpected term id', 'terms_by_vid=<pre>'.htmlspecialchars(print_r($terms_by_vid,1)).'</pre>');
          /////////////////////////////////// DEBUG /////////////////////////////////////////////////////
      }

results

vids=Array
(
    [8] => 8
)

terms_by_vid=Array
(
    [9] => Array
        (
            [470] => stdClass Object
                (
                    [tid] => 470
                    [vid] => 9
                    [name] => SESS
                    [description] => In event type SESS
                    [format] => 
                    [weight] => 20
                    [vocabulary_machine_name] => vocabulary_9
                )

        )

)

 tids=Array
(
)
StephenRobinson’s picture

I am using a term reference from /admin/structure/types/manage/campus_event/fields

StephenRobinson’s picture

flakey database API?

StephenRobinson’s picture

The plot thickens, I think this happens when cron is sending content to apachesolr

StephenRobinson’s picture

correct data, from another debug statement:

terms_by_vid=
Array
(
    [9] => Array
        (
            [470] => stdClass Object
                (
                    [tid] => 470
                    [vid] => 9
                    [name] => SESS
                    [description] => In event type SESS
                    [format] => 
                    [weight] => 20
                    [vocabulary_machine_name] => vocabulary_9
                )

        )

    [8] => Array
        (
            [32] => stdClass Object
                (
                    [tid] => 32
                    [vid] => 8
                    [name] => All
                    [description] => Can be seen by everyone (EBI, WTSI, Wellcome Trust).
Note: You must use this option if you wish events to appear in email bulletins.
                    [format] => 
                    [weight] => 0
                    [vocabulary_machine_name] => vocabulary_8
                )

        )

)
vids=
Array
(
    [8] => 8
)
 tids=
Array
(
    [32] => 32
)
StephenRobinson’s picture

does not happen if you index data as a logged in admin user

StephenRobinson’s picture

tac_lite_node_get_terms is missing a return value when cron runs

StephenRobinson’s picture

I think this has to do with node_load not having the term id for anonymous, as this is used in tac_lite_node_get_terms, I have a scheme for Visibility and Visibility on create and edit forms, I have allowed this term for anon, so it shows up when you view nodes as anon, so therefore is available upon node_load for anon, so this should have fixed the issue, didn't throw errors with previous versions, but looks like it was a configuration issue, so this may have fixed the issue, will find out on tomorrows cron?
Thanks for the time,
Stephen :)

Dave Cohen’s picture

A little history might help understand what's going on.

In Drupal 7.x, tac_lite has no clean reliable way to get the terms associated with a node. In previous versions of drupal there was simply a table with term ids and node ids. Now with fields and entities, that simple table got lost and nothing replaced it.

So tac_lite for D7 used the taxonomy_index table for this purpose. Until not too long ago someone pointed out that table is only maintained for published nodes. Unpublished nodes appeared to have no terms associated with them, to tac_lite.

In reponse to that, I added some code that inspects fields, specifically term reference fields, and use that to build the list of terms associated with a node. This approach works for both published and unpublished nodes. However, I was never 100% confident in the new code, so I left the old code intact, and when the term list derived by the new code fails to find a term derived by the original code, you see that warning.

The good news is that when the warning appears, tac_lite does treat the node as tagged with the term. This is, I think, the right thing to do. however it would not honor this term if the node is unpublished. Possibly a problem there, although I doubt the cron job acts on unpublished nodes.

My question is, why is this code being called during cron jobs? I don't think it is simply building the search index, because the code is rebuilding the node access table, which happens when nodes are saved. I'd be interested in seeing a stack trace. That might point out the root cause.

Dave Cohen’s picture

There is a setting in tac_lite for term visibility. Make the terms (as opposed to the nodes tagged with them) visible to everyone should make this problem go away.