Paging breaks search results

This is a real bug. I need to add paging functionality. This might take a week or so, and we'll need to test it after paging is implemented.

Another issue you brought up is on customizing where the search result goes to. Currently, adding another <div id="live-search-results" /> is more of a hack. I'll need to allow people to assign the target element that will be injected with search results.

Please keep a tab on this issue.

I've just committed the new code that should fix paging. The nightly development snapshot should be packaged with the new code sooner or later. The Last Updated field should be a date later than May 5, 2007. If it's May 1, 2007, then it's not updated yet.

If you don't want to wait, you can also check out the livesearch.js file directly and use it to replace your copy of livesearch.js.

Please note...
1. If paging works or not.
2. If the scrolling behavior is desired. Because your search result is lengthy, I thought that scrolling back to the top of the search result would be a plus on usability (the user wouldn't have to scroll back up to view the next page). Please give some input on this. More specifically: should this behavior be on by default? I'll definitely make this a configurable option, but for an average site maintainer, should this be on by default? My site, kourge.net, for example, will actually scroll down because of this.

I would also like to implement an option where you can configure where to inject the search results to. Currently the module blindly appends <div id="live-search-results" /> after the search field and injects the results into it. I want people to be able to choose between this default approach or an element of their choice. The element would be identified by its id attribute.

The reason I would like to do this is because although your hack works, it is technically wrong to have two elements with the same id to exist on a page. IDs are supposed to be unique. I'm actually surprised that this hack works.

The paging mechanism is provided by Drupal's internal guts. And yeah, the paging numbers in the URLs are funny because they shift a value, but that's normal. I've tried to fix the code (again) and I'm sure this'll work. (I wonder if I'm putting my foot in my mouth by saying this.) Anyhow, the new livesearch.js can be checked out directly. The HEAD snapshot should follow the lead soon. Having a date of May 7, 2007 means it's updated. If it's not, you can check the file out directly and use it to replace your copy. Or you can wait for the new HEAD snapshot if that feels more secure. ;)

1. The scrolling behavior is not made a configurable option yet, but will soon be.
2. Should the scrolling behavior be on by default?
3. I'll also start coding the custom region injection feature. Can you help and test this too when it's available?

A few interesting notes on the mechanisms: the gibberish you saw was actually raw data of the search result that was passed back from the server. All I had to do was to grab the target URL of the paging link when it's clicked, fetch the URL with Ajax, and spit it back to the search results region. What I had problem with was how links were grabbed. Now there should be no link-grabbing problems.

I've just committed the new code. The HEAD snapshot should say May 8, 2007 when the package is updated.

Scrolling should now be a default behavior that can be optionally turned off. (I've tested this.) As for animated scrolling, I would love to do that, but the only thing is, jQuery doesn't provide such a mechanism. If you'd like to use script.aculo.us, replace line 58 in livesearch.js:
if (settings.scrollToResults) {scrollTo(target.get(0));}
with this:
if (settings.scrollToResults) {new Effect.ScrollTo(target.get(0));}
If you're familiar with Prototype, you'll notice that I stole the scrollTo function right from Prototype's Position.cumulativeOffset() and Element.scrollTo().

In the settings page, if you set the search results location to "Use specified custom element" and specify an element id in the textfield, Live Search will not insert a new <div> like previously mentioned. Instead, it'll use the element you specified.

In your scenario, since you already have the custom markup in your template, you simply need to choose "Use specified custom element" and specify the same id "live-search-results" as the custom element id.

Wow, the scriptaculous effect does look nice! ;)

I didn't change the teaser text, though. The Search module controls the teaser text. More specifically, the search_excerpt() function does the job. However, Live Search does offer options for hiding the metadata for nodes. I do that on kourge.net because I think they're somewhat extraneous.

When you mean a block for Live Search, do you mean a live search form? Live Search doesn't have its own block because the Search module already has one. In fact, if you were using the Search module's block instead of the theme's search box, all you have to do is to set the target search box to "block" instead of "theme. What I had in mind was to avoid reinventing the wheel and provide YAB (Yet Another Block).

From my own testing, the watchdog logging has been fixed. It should log events in the exact same style and manner as the search module does, such as the type and the message format, except for the accessed URL which is livesearch/node/keyword instead of search/node/keyword.

Hi,

I have checked the site above given www.genericgeek.com , the pager still breaking in it.Can you plz help me to get rid of that pager problem in live search results page?

Thanks in Advance.......!