Closed (fixed)
Project:
Finder
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
4 Jul 2011 at 14:54 UTC
Updated:
3 Apr 2012 at 19:55 UTC
Jump to comment: Most recent file
When using a select list box to select node type I want to search on, Finder is returning the {name} field instead of the {type} field from the node_type table for the select list option value.
So for example... my select display value is 'Bumper Sticker' the machine readable name option value should be 'bumper_sticker', but finder is trying to search the node {type} field with 'Bumper Sticker' and obviously finding no results.
Ill have to go in and hack this so it works properly, but wanted to call attention to the problem since I didn't find any other posts on the matter.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | bumpersticker.jpg | 145.26 KB | danielb |
Comments
Comment #1
danielb commentedCan't reproduce.... finder isn't searching the node_type.type field, it's searching the node_type.name field....
Comment #2
Reevescorp commentedTry using 'two word' node types vs 'oneword' node types.... Actually... you are searching node.type using the node_type.name field... which is incorrect. It will work fine with one word node types. Pages, Stories, Articles etc... but when you use two word node types... the node_type.name field becomes "Bumper Sticker' for example... and the node_type.type field becomes "bumper_sticker" When you pull "Bumper Sticker" from node_type.name and you try to search it against node.type... it will fail... because the variable in node.type is "bumper_sticker" not "Bumper Sticker". I suspect the module doesnt really get tested using multiple word node types hence why the problem hasnt been detected before now. I already tested this theory... I changed the human readable name of my node_type.name to 'bumper_sticker' to match the machine readable node_type.type BAM... it worked. Problem there is I dont really want to use 'bumper_sticker in my select list... looks cheesy.
Comment #3
danielb commentedI don't think so mate, plenty of my content types are two/three words, e.g. "Book page".
Just to be certain I created a content type Bumper Sticker with machine name bumper_sticker, and added one node of this type.
Then I created a finder as you described, and it worked fine.
Attached is a screenshot of my test finder. You can see at the bottom a result of the bumper sticker node, after "Bumper Sticker" was selected. At the top you can also see debugging information about the query, which shows node_type.name being the field that is matched and "Bumper Sticker" as the keyword.
IMO, if you are experiencing a bug, then you have not identified the right bug.
Comment #4
Reevescorp commentedQuery string that doesnt work:
SELECT DISTINCT node.nid, "nid" AS base_field, "node" AS base_table, node.title AS finder_element_3_node_title, node_type.name AS finder_element_4_node_type_name FROM node node INNER JOIN node_type node_type ON node_type.type = node.type WHERE ((node.type IN ('adhesive_decal_10x14','bumper_sticker','button','magnetic_sign') AND ((node.title LIKE '%obama%'))) AND (node.type IN ('Bumper Sticker','','','') AND ((node_type.name LIKE '%%')))) AND node.status = 1 GROUP BY node.nid LIMIT 0, 5
This (node.type IN ('Bumper Sticker','','','') is wrong. Clearly it IS trying to search 'Bumper Sticker' IN node.type which will fail.
If I change the node_type.name to 'bumper_sticker' and rerun the query again
SELECT DISTINCT node.nid, "nid" AS base_field, "node" AS base_table, node.title AS finder_element_3_node_title, node_type.name AS finder_element_4_node_type_name FROM node node INNER JOIN node_type node_type ON node_type.type = node.type WHERE ((node.type IN ('adhesive_decal_10x14','bumper_sticker','button','magnetic_sign') AND ((node.title LIKE '%obama%'))) AND (node.type IN ('bumper_sticker','','','') AND ((node_type.name LIKE '%%')))) AND node.status = 1 GROUP BY node.nid LIMIT 0, 5
Now it works... now it finds all Obama bumper stickers
Just to be clear... I am running two elements. One is a text box for the wording the other is a drop down list for the type.
Also... your screenshot shows the query being called at line 1143.... in my module (6.x-1.10) line 1143 is a blank line:
Comment #5
danielb commentedWait a second, I'm using 6.x-1.x-dev not 6.x-1.10. If the 6.x-1.x-dev version does not fix the problem please post an export of your finder here in an attachment, codeblock or pastebin.
Comment #6
Reevescorp commentedOk... I updated to the dev version.
Still experiencing the same problem
Its still looking in node.type for 'Bumper Sticker'
SELECT DISTINCT node.nid, "nid" AS base_field, "node" AS base_table, node.title AS finder_element_3_node_title, node_revisions.body AS finder_element_3_node_revisions_body, node_type.name AS finder_element_4_node_type_name FROM node node INNER JOIN node_revisions node_revisions ON node_revisions.vid = node.vid INNER JOIN node_type node_type ON node_type.type = node.type WHERE ((node.type IN ('adhesive_decal_10x14','bumper_sticker','button','magnetic_sign') AND ((node.title LIKE '%obama%' OR node_revisions.body LIKE '%obama%'))) AND (node.type IN ('Bumper Sticker','','','') AND ((node_type.name LIKE '%%')))) AND node.status = 1 GROUP BY node.nid LIMIT 0, 5
Comment #7
danielb commentedResetting the "Restrict nodes that can be found to only these content types" on the text field element to 'all' seems to fix it.
Not sure why that's interfering....
Comment #8
danielb commentedWithout picking content type restrictions on the text field:
With picking content type restrictions on the text field:
We are missing 3 arguments in the 2nd case - the second set of node types... and the last argument is coming out in the wrong spot... hmmmm
(obviously in my example I'm using different content types than you, because I don't have the same ones you do)
I will look into the code and see how this happens.
Comment #9
danielb commentedThere is a for loop in finder_node_finder_find() that adds arguments for the type restrictions, however each time it does so it wipes the previous arguments....
oops!
Comment #10
danielb commentedFixed in 6.x-1.x-dev, will also look at 7.x-1.x-dev. Thanks for your persistence!
Comment #11
danielb commented7.x-1.x-dev works too differently to have the same bug.
Within the next 12 hours the 6.x-1.x-dev will be updated with the changes, check the date on the release.
Comment #12
Reevescorp commentedThank you for identifying the issue. At the time of this posting I notice the dev 7 version had been updated but not the dev 6 version (still showing a July 3 release).
Comment #13
danielb commentedugh I must have messed up the commit :/
Comment #14
Reevescorp commentedIf I had a nickel for every time I saved to the wrong file... I'd be retired to some secluded beach with half naked women serving me frozen drinks with little umbrellas all day long. Btw... thank you for all your hard work providing a superior search module. The functionality of this code is awesome! Heads above the rest.
I do have one more question. Is there a way on this node.type search to make an all of the selected types? For example I dont want to include all node types, I want to only select individual product types... but also give the user an ALL selection to check ALL product types for the search terms?
Regards,
Comment #15
danielb commentedYes when you edit a select/radios/checkboxes element there is a fieldset called 'form element' or something like that. Within that are some options for 'empty choice'. You can label it 'select all' or something like that. Basically what it means if they choose that option; this element won't affect the query, and won't cause any 'restrictions' on the results - which is effectively the same as picking all the options. The settings for node type in the element should still apply.
Comment #16
Reevescorp commentedI hate to be a PITA.... but I downloaded the newer code... still having the same problem and I dont see any changes in the finder_node_finder_find() between the old and new code. So Im wondering if you accidentally posted the wrong version?
Comment #17
danielb commentedNo, the changes are there...
Comment #18
danielb commentedComment #19
danielb commentedPretty sure this is fixed, make sure you're getting the 6.x-1.x-dev version and not re-downloading the broken 6.x-1.10.
Comment #21
john.chriss commentedI am facing the same problem. Already tried all the given solutions but all in vain, the error is still there..
Any other solution?
________________
I love printing stickers.