Posted by cybermache on February 4, 2009 at 9:32pm
Jump to:
| Project: | Recipe |
| Version: | 6.x-1.0-beta1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I found this node http://drupal.org/node/354762 but there didn't seem to be a posting on the recipe project page. I have just realized that I am having the same problem.
I am unable to use the search feature while viewing individual recipes and Views of recipe categories. I'm not sure if this is a bug from a newer version of recipe.module. As luck would have it I never tried to search for things while looking at my recipes. My uncompleted searches do not show up on my sites logs and the only thing that occurs is a refresh of the recipe that I'm viewing including a reset of the yield.
Comments
#1
Wow - that's true. I had never tried searching from a recipe page either and I have the same problem.
#2
Problem also exists in version 6. Updating "Version" for this issue to reflect this.
#3
Just tried using the dev version 6.x-1.x-dev and the problem exists there too. Using site search when viewing an individual recipe returns nothing and seemingly simply reloads the current page.
#4
I have to say up front that I do not know exactly how Search works, but here is what I notice:
If I go to / and View HTML Source, the search target is /
If I go to /recipe and View HTML Source, the search target is /recipe
If I go to /faq (FAQ module installed) and View HTML Source, the search target is /faq
On /recipe, if I search for FAQ (I have an FAQ containing "example FAQ"), I see in the results my FAQ entry.
If I go to /faq and search on "barley" (I have a homebrew recipe entered), I see in the results my Recipe entry.
So in my case, I agree that the search target is always the current node. I believe this is actually correct (Drupal will intercept the POST to /recipe and branch off to handle it's search, as needed).
Also in my case, I can not reproduce the problem.
Those of you with this problem, can you try something similar to the above using 2 different modules (neither of which are Recipe)? Say FAQ, and something else. Let me know if you can reproduce this with other modules.
#5
#6
My problem only exists when viewing an individual recipe page and submitting a search on that page. Not when looking at a list of recipes (i.e., /recipe) and doing a search. The search target (or action="") for a recipe page such as Crunchy Granola is pointed to "recipe/crunchy_granola". Its at this page that pressing search button reloads page and fails to provide a page of search results. I am using pathauto to create the url aliases for my recipe pages and I have porter stemmer. I have disabled and uninstalled both to test their involvement and found problem to still exist.
So to maybe reproduce some steps - I can go to my front page and type 'barley' into the search bar and press 'search'. I get a list of results (search action points to "/search/node/barley"). One of them is 'Crunchy Granola' I click on that. I am now on the recipe page crunchy granola and I type 'barley' again into the search bar and press 'search'. The page simply reloads. "Barley' not being significant, any word would simply reload the crunchy granola page or any other recipe page.
Anything else that I can provide to help pin point this issue let me know.
#7
Committed fix to HEAD. Problem was related to clearing $_POST variable in the theme_recipe_node function.
Drupal search would POST to the recipe page which would then clear out the $_POST variable, causing
search to 'forget' what it was doing:)
#8
#9
Thanks for all the work.
So after remembering that I had the old code in my template.php and updating the necessary code I got this fix to work. But now I realize that it eliminates the patch that helped carry the custom yield value to the html export and print page. So now when users navigate to the print page the yield value is reset. Any ideas how we can do both here?
#10
@christophoffman, the html view should contain the proper yield in tonights dev snapshot (Feb12).
#11
Automatically closed -- issue fixed for 2 weeks with no activity.