Search broken after update to 1.6

Seems like it's not getting a keyword.  What does the url look like?  Are you just going to "/search/" without a search term?  What happens if you go to "/search/something"?

 

If it's not generating a proper url, it is probably a javascript issue.  The search bar used to rely on javascript to generate the search words.  In the old versions, you had to regenerate javascript for production environments with rake asset:packager:build_all.  (Hmm, is that in upgrade notes anywhere?)

 

It might also be possible that your browser is just caching old javascript, so before you do the above, you might just try a hard reload.

 

The good news is that this is unlikely to be a data issue, so you shouldn't have to be overly careful about step-by-step migrations.  I would be shocked if this issue persisted into 1.8 (still in prerelease).

---

Thanks for response. I have ran the rake tasks but it did not change anything, neither in a different browser.

Currently the site's running on the Master branch, commit b3ea0b80f2285dfb5d3a9924dde65ac8076a47e2,

and the error remains. Also when going to /search/something.

 

These are the parameters received in the request:

Parameters: {"_keyword"=>"something", "id"=>"*search", "view"=>"content"}

  --Patrick Roza.....Sun Jan 22 02:18:37 -0800 2012

---

hmm, those parameters are correct. So I guess it's not a javascript issue. And the message above gives the *search card content, which looks totally fine, so it's not a data issue.

 

OK, here's another theory. Perhaps some of the newer libraries (gems) are breaking the old wagn.

 

Versions 1.7 and later avoid this problem by using "bundler", which makes sure wagn is only using specified gems. But earlier versions of wagn are susceptible to this kind of problem.

 

Would it be possible to upgrade to 1.7.1 and see if this problem continues?

  --Ethan McCutchen.....Sun Jan 22 13:03:47 -0800 2012

---

Upgrading to 1.7.1 or even 1.8pre does not yield different results.

 

It does appear to be a data issue, because if I change the database.yml to use the database of the second wagn I referenced in my initial post (which does work) and clear the cache, then the search works.

The issue occured between 1.5.3 and 1.6, hopefully it helps narrowing it down.

  --Patrick Roza.....Tue Jan 24 00:02:34 -0800 2012

---

Is there any more information in the log that might be useful?

  --Ethan McCutchen.....Tue Jan 24 07:17:08 -0800 2012

---

If you're still seeing the strip! error in 1.8.pre, then something is very strange -- that method is completely gone from 1.8. The code has been extensively rewritten. You definitely would need to migrate for it to work.

 

As far as data is involved, there's really only one card that configures the main search, the "*search" card. It should be a search card, and it's content should be '{"match":"_keyword", "sort":"relevance"}'. Judging by the error, that all looks to be correct in your data.

 

And the parameter parsing you pasted all looks correct, too.

 

The issue is that we have to get that _keyword from the params to the WQL, and the error suggests that something is going wrong somewhere in between.

 

It's going to be a challenge to debug this from afar, but I'm guessing you wouldn't want to send a complete data dump to me for privacy reasons, so here is what I suggest.

 

1. Go to your wagn root directory

2. Edit packs/type/search_pack.rb

3. change line 5 from

 

card.item_cards( paging_params )

 

to

p = paging_params

Rails.logger.info "!!!! paging params = #{p.inspect}; raw = #{render_raw}"

card.item_cards p

 

4. clear the cache, restart the server, and try again

5. look at the log files and send me any warnings about paging params and error information you feel comfortable sending

  --Ethan McCutchen.....Tue Jan 24 12:51:50 -0800 2012

---

Thanks, indeed there was little other useful info I could find in the logs.

Perhaps could share DB in case there's no other way, for now I have applied the suggested changes and the output is:

 

 

!!!! paging params = {:default_limit=>50, :offset=>0, :_keyword=>nil}; raw = {"match":"_keyword", "sort":"relevance"}

 

 

with parameters in the request log entry:

 

"_keyword"=>"test", "id"=>"*search", "view"=>"content"

 

  --Patrick Roza.....Tue Jan 24 13:06:46 -0800 2012

---

very interesting. so we're losing the parameters somewhere along the way.

 

I guess for now we can keep narrowing it down. Try editing app/models/renderer.rb (in 1.6 -- this is moved later).

 

on line 175, add this:

 

Rails.logger.info "!!!! initializing Renderer: params = #{@params.inspect}"

 

That should tell us whether the params are lost before or after we get to the renderer. I think there will only be one of these, but check for multiple in the log.

 

Thanks for helping with this!

  --Ethan McCutchen.....Tue Jan 24 13:28:30 -0800 2012

---

while you're at it, why not do another in that same file:

 

on line 521 (a line after "@paging_params ||= begin"), add:

 

Rails.logger.info "!!!!paging params: root.params = #{root.params.inspect}"

 

This is assuming the params are lost after renderer initialization, which is my hunch.

  --Ethan McCutchen.....Tue Jan 24 13:32:07 -0800 2012

---

I have not migrated back to 1.6 due to probably having to revert DB etc, so the wagn runs on the latest master branch commit: b3ea0b80f2285dfb5d3a9924dde65ac8076a47e2 from January 9th.

 

It seems the renderer has moved and has been refactored, would you have new line numbers for me?

 

And no problem, thank you too!

  --Patrick Roza.....Tue Jan 24 13:57:44 -0800 2012

---

Some more findings from the log output due to search_pack.rb changes:;

There are actually multiple entries "!!! pagin partams = " per request, first 2 entries list the _keyword correctly (near cache read entries of some custom card type), however the last entry lists it as nil, so it is lost somewhere along the way.

 

Example success:

Cache read: aaa.bbb/development/Card/132744342785uu/aaa_dev_blog_entry-content
!!!! paging params = {:default_limit=>20, :offset=>0, :_keyword=>"test"}; raw = {"type":"Dev Blog entry", "sort":"create", "dir":"desc"}
Cache read: aaa.bbb/development/Cardtype/132744342786ok/class_names

 

Example failure:

Cache read: aaa.bbb/development/Card/132744342785uu/*search-content
!!!! paging params = {:default_limit=>50, :offset=>0, :_keyword=>nil}; raw = {"match":"_keyword", "sort":"relevance"}
Cache read: aaa.bbb/development/Card/132744342785uu/*foot

 

Perhaps with the other log output in place it could be narrowed down, or perhaps I could send logs or other data privately?

  --Patrick Roza.....Tue Jan 24 14:37:22 -0800 2012

---

Interesting. I'm now wondering if there might be something unusual about the page layout that might be causing this to happen (by exposing a Wagn bug). Do you have multiple searches on the page? (Especially one that occurs before _main). Does the error happen when you go to /search/something?layout=simple

 

I have a theory about what's causing the bug. Try making this change on line 157 of lib/wagn/renderer.rb:

 

Change

 

@params ||= {}

 

to

 

@params = @params ? @params.clone : {}

 

and add a warning for good measure in the following line:

 

Rails.logger.info "!!!! initializing Renderer: params = #{@params.inspect}"

 

There's some chance that this will fix the problem. If not, let me know how many times you see the warning message (just like in the previous example).

 

We're getting closer now :)

 

- ethan

  --Ethan McCutchen.....Tue Jan 24 17:51:59 -0800 2012

---

Great, adding layout=simple indeed works around the issue! I do get search results.

 

When applying the changes to renderer.rb the "initializing Renderer" log entry appears twice, but in separate requests.

 

First:

 

Processing CardController#show (for xxx.xxx.xxx.xxx at 2012-01-25 07:10:32) [GET]
 
  Parameters: {"_keyword"=>"something", "id"=>"*search", "view"=>"content"}
...
Cache write: aaa.bbb/development/System/132747541293vd/always
!!!! initializing Renderer: params = {"_keyword"=>"something", "format"=>"html", "action"=>"show", "id"=>"*search", "view"=>"content", "controller"=>"card$
Cache read: aaa.bbb/development/Wagn::Pattern/132747541294lb/METHODKEYS-*search-Search--
Cache read: aaa.bbb/development/Cardtype/132747541293qo/card_keys
 

 

 

Second:

 

Processing CardController#show to css (for xxx.xxx.xxx.xxx at 2012-01-25 07:10:33) [GET]
 
  Parameters: {"id"=>"*css", "12972"=>nil}
...
!!!! initializing Renderer: params = {"format"=>"css", "action"=>"show", "id"=>"*css", "controller"=>"card", "12972"=>nil}
 

 

  --Patrick Roza.....Tue Jan 24 23:18:21 -0800 2012

---

Okay I have found what the issue is, the issue is in the News card I have a search:

 

 

If I remove this search from News, the global search function works properly!

  --Patrick Roza.....Tue Jan 24 23:22:54 -0800 2012

---

Interesting. So do I take it that my little patch (@params = @params ? @params.clone : {}) did not fix the bug?

 

If not, I have another idea. What happens if you change line 167 of packs/type/search_pack.rb from

 

[:offset,:limit,:_keyword].each{|key| s[key] = p.delete(key)}

 

to

 

[:offset,:limit,:_keyword].each{|key| s[key] = p[key]}

 

I'm hoping that will let you keep the search in News and still have everything work. Let me know.

  --Ethan McCutchen.....Wed Jan 25 12:18:56 -0800 2012

---

Also, you can remove all those annoying logger statements now if you want to :)

  --Ethan McCutchen.....Wed Jan 25 12:19:34 -0800 2012

---

Bingo, that indeed was the issue!

The earlier changes did not affect the issue, but changing the line 167 in search_pack.rb resolved the issue!

The search is back in the News card, and the wagn search functions correctly.

 

Thanks again for your time and efforts, and WAGN in general!

  --Patrick Roza.....Wed Jan 25 12:30:54 -0800 2012

---

awesome. nice teamwork!

  --Ethan McCutchen.....Wed Jan 25 13:10:25 -0800 2012