After enabling the module the following error message is displayed on a migrated 6.20 site:

Fatal error: Call to a member function condition() on a non-object in /var/www/html/cm7/sites/all/modules/faq_ask/faq_ask.module on line 1537

Can this be fixed by patch?

CommentFileSizeAuthor
#17 faq_ask_category_setting.png3.5 KBstenjo

Comments

boftx’s picture

boftx commented

The following code changes eliminate the initial WSOD in the case of an annonymous user. This seems to be either a result of changes to the DB API or just a simple misuse. In any event, it seems that chaining of the various functions is no longer supported in the same way. Similar changes will need to be made to the other db_select calls in that function.

Note that I had to had the join clause to pull in the users table, which made the final condition call unneeded.

  else { // Edit own.
    $query = db_select('node', 'n');
    $query->join('users', 'u', 'n.uid = u.uid');
    $query->join('taxonomy_index', 'tn', 'n.nid = tn.nid');
    $query->condition('n.type', 'faq');  // n.type = 'faq'
    $query->condition('u.status', 0);  // AND n.status = 0
//    $query->condition('u.uid', $user->uid);  // AND n.uid = $user->uid (the user and the node owner are the same)
GStegemann’s picture

GStegemann commented

Yes, that works so far. But shouldn't "u.status" be changed to "n.status"?

And, all references to table name "taxonomy_term_node" have to be changed to "taxonomy_index".

boftx’s picture

boftx commented

Yes, the table name needs to be changed wherever the old name occurs. I would say you are correct that u.status should be n.status. I'll need to work thru the logic to see if u.status should be used, too, but I wouldn't think so.

This was just a quick fix to prove the concept. I'll post a full diff later on, probably tonight sometime.

rogical’s picture

rogical commented
Priority: Normal » Critical

a fresh install on D7.10

stenjo’s picture

stenjo commented
Assigned: Unassigned » stenjo
Status: Active » Needs review

This shall now have been fixed in dev. Please verify that this is the case

GStegemann’s picture

GStegemann commented

No, now it fails at line 1537, at the following statement:

   // Join the term_data table to select based on tid.
   $query = db_select('node', 'n')
     ->leftJoin('taxonomy_term_node', 'tn', 'n.nid = tn.nid')
     ->condition('n.type', 'faq')  // n.type = 'faq' (this is a 'faq' node)
     ->condition('n.status', 0)  // AND n.status = 0 (node is not published)
     ->condition(db_or()  // AND ( (one of the following is true:)
       ->condition('tn.tid', $terms, 'IN')  // tn.tid IN (" . db_placeholders($terms) . ") (the term of the node is in the
sers terms)
       ->condition('tn.tid')  // OR tn.tid IS NULL) (or there is no terms associated with the node)
     );

I.e. at the first call of condition().

stenjo’s picture

stenjo commented
Status: Needs review » Needs work

There is something wrong with that query. This error do not appear for me, are you able to figure out where the problem might be?
Some documentation can be found on http://drupal.org/node/310086

stenjo’s picture

stenjo commented
Status: Needs work » Needs review

There was quite a set of database access stuff that had to be corrected. Issue seemed to have more with the fact that the taxonomy database structure is changed.
This error should be gone now.

stenjo’s picture

stenjo commented

Have been working on this for a while now and it seems one of the changes from D6 to D7 on taxonomy is that the tables are changed. So is the way the tables are used.
The table holding the relationship between nodes and terms is now called taxonomy_index but that table only keeps track of all published nodes. See issue #962664: Taxonomy Index for unpublished entities. Un-published nodes are kept in field tables and not introduced into the taxonomy system until the node is published.

I am tempted to resort to a supporting module http://drupal.org/project/taxonomy_entity_index that solves this for us by maintaining also the relation to unpublished nodes.
I am reluctant, however, as this means introducing a dependency we really should try and be without.
Any ideas or comments here?

nancydru’s picture

nancydru
she/her/hers
Primary language English
Location Boston
commented

I am very much opposed to a dependency. How difficult is it to use the field tables?

GStegemann’s picture

GStegemann commented

Yes, the error is gone. Thanks.

stenjo’s picture

stenjo commented
Status: Needs review » Fixed

I assume I can close this now then

GStegemann’s picture

GStegemann commented

But now I get a new error:

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal7.igs_intra_field_data_field_tags' doesn't exist: SELECT COUNT(*) AS expression FROM (SELECT 1 AS expression FROM {node} n LEFT OUTER JOIN {field_data_field_tags} ft ON n.nid=ft.entity_id OR ft.entity_id IS NULL WHERE (n.status = :db_condition_placeholder_0) AND (n.type = :db_condition_placeholder_1) AND( (ft.field_tags_tid IN (:db_condition_placeholder_2, :db_condition_placeholder_3, :db_condition_placeholder_4, :db_condition_placeholder_5, :db_condition_placeholder_6, :db_condition_placeholder_7, :db_condition_placeholder_8, :db_condition_placeholder_9, :db_condition_placeholder_10, :db_condition_placeholder_11, :db_condition_placeholder_12, :db_condition_placeholder_13, :db_condition_placeholder_14, :db_condition_placeholder_15, :db_condition_placeholder_16, :db_condition_placeholder_17)) OR (ft.field_tags_tid IS NULL ) )) subquery; Array ( [:db_condition_placeholder_0] => 0 [:db_condition_placeholder_1] => faq [:db_condition_placeholder_2] => 236 [:db_condition_placeholder_3] => 237 [:db_condition_placeholder_4] => 238 [:db_condition_placeholder_5] => 239 [:db_condition_placeholder_6] => 240 [:db_condition_placeholder_7] => 241 [:db_condition_placeholder_8] => 242 [:db_condition_placeholder_9] => 259 [:db_condition_placeholder_10] => 260 [:db_condition_placeholder_11] => 261 [:db_condition_placeholder_12] => 262 [:db_condition_placeholder_13] => 263 [:db_condition_placeholder_14] => 264 [:db_condition_placeholder_15] => 265 [:db_condition_placeholder_16] => 266 [:db_condition_placeholder_17] => 267 ) in _faq_ask_list_unanswered() (Zeile 1573 von /var/www/html/cm7/sites/all/modules/faq_ask/faq_ask.module).
stenjo’s picture

stenjo commented
Status: Fixed » Active

It is not fixed then. Can this be related to the need for a "Tags" vocabulary?
I think it is a bug in the code if this is in a way hardcoded to a given vocabulary name. I need to have a look at that...

GStegemann’s picture

GStegemann commented

It is not fixed then.

Yes.

Can this be related to the need for a "Tags" vocabulary?

I would say yes.

I need to have a look at that...

Thanks.

jlea9378’s picture

jlea9378 commented

Any update on this issue?

stenjo’s picture

stenjo commented
Status: Active » Needs review
StatusFileSize
new faq_ask_category_setting.png3.5 KB

Have implemented some sort of workaraound where the admin must select field in
admin/config/content/faq/ask
for the category to work from.
FAQ-Ask category field
Save the settings page and see how this works

stenjo’s picture

stenjo commented
Status: Needs review » Fixed

In the latest dev release this should be fixed now. The workaround in #17 is removed as well and should work without the need of setting the category selection field specifically.

Status: Fixed » Closed (fixed)

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