Live Search breaks JavaScript functionality

Is there an example site that shows this? Without a live JavaScript error showing up, it can be very hard to determine how the scripts conflict each other.

On Firefox, there's Tools > Error Console. An error output from Firebug would help a lot, as I can't imagine any kind of web development being sane without Firebug.

t has no properties
e(undefined, "live-search")jquery.js (line 2)
e(0, "live-search")jquery.js (line 2)
e(["live-search"], function(), undefined)jquery.js (line 2)
e(Document www.designers-opensource.de, "live-search")jquery.js (line 2)
e("live-search")jquery.js (line 2)
e([Document www.designers-opensource.de], function(), ["live-search"])jquery.js (line 2)
e(function(), ["live-search"])jquery.js (line 2)
e()jquery.js (line 2)
(no name)()livesearch.js (line 63)
e()jquery.js (line 2)
e()jquery.js (line 2)
e([function(), function(), function(), 1 more...], function(), undefined)jquery.js (line 2)
e()jquery.js (line 2)
[Break on this error] eval(function(p,a,c,k,e,d){e=function(c){return(c jquery.js (line 2)

maybe this helpes ...

greetings momper

sorry - i changed the title ...

I have the (I believe) same issue when, as a finishing touch, I decided to get fancy and added 'Message Effects"
( http://drupal.org/project/messagefx ), which required me to add JQuery Update ( http://drupal.org/project/jquery_update ) as well as JQuery Interface ( http://drupal.org/project/jquery_interface ).

I realize that these have DB writes, so who knows whats responsible for the disconnect, but after much trial and error, disabling LiveSearch completely fixed my problem. If I disable the JQuery modules and Message Effects, the problem then remains, so something appears to change once both JQuery and LiveSearch are simultaneously active.

Also, if it helps, once the error showed up, LiveSearch also stopped functioning (I figured the problem was somewhere else). It reverts to normal out-of-box search functionality, even though the LiveSearch module configuration page still works. Message Effects works when enabled with and without LiveSearch, but it sounds like it has few core hooks. It makes no difference whether LiveSearch runs in a theme or block configuration, compact or not.

To illustrate the error, all 'expandable' options (such as the admin options {like publishing, comments, etc.} available on new content creation only show the heading, and the 'triangle' twistie that shows each item is expandable becomes the 'circle' (to show no further expansion is possible). You can no longer edit (or acces) any of those dialogs.

So I'm not saying this is anyone's 'fault', just that we've discovered a conflict.

My site that demonstrated this problem is in production, but I have a VM I can dig up and recreate the problem for everyone later today. I'll grab screenshots and try to follow the earlier info gathering request. My only problem with accomplishing this right away is that my auto tran$mission died this morning, so I'll have to be attending to that today too. And doing my job(!). I'm also not skilled in PHP, CSS or Javascript (but I do know Prolog, Notes and other environments!) ;-)

I mention that because of the tensions between designers and developers on drupal.org. I guess I do more design work on my own time, and develop for a living. I (and our users) do very much like LiveSearch.

From my experience, it is very hard to debug these kind of stuff without actually tinkering with an actual live page. Is it confirmed that having both Live Search and Simple Menu will definitely cause an error? If that's the case, I can set up a local testing environment and install both module to try to resolve this issue.

These kinds of errors are usually caused by missing page elements. Any module or script that can modify the particular markup structure that houses the search field can potentially cause a JavaScript error and halt all script-related goodies. After all, because of Drupal's flexibility, themers can craft whatever kind of markup structure that can suit their design, and I've only tested Live Search with only two themes: Garland and Typography Paramount.

Once, someone had disabled the search field but not the Live Search module, causing to script to spit errors and come to a screeching halt, in turn shutting off collapsible fields. I later changed the Live Search script to only continue if a search field is actually present.

2 errors showing in Firefox, plus some FCK errors (not included):

ERROR 1
Warning: Error in parsing value for property 'display'. Declaration dropped.
Source File: http://hostname/drupal/modules/system/defaults.css
Line: 43
(default.css is unaltered, or I can attach it)

ERROR 2
Error: t has no properties
Source File: http://hostname/drupal/misc/jquery.js
Line: 2
Running JQuery 1.1.2 (unaltered)

I ran from a slightly older copy of my site, and it doesn't have the 'expandable twisties' (i.e., the triangle for 'expandable' and the circle for 'not expandable') I mentioned earlier, but the problem is similar. I took a screenshot and have attached it.

Using default Drupal 5.1 theme, taxonomy multi-edit, comment, path, taxonomy, upload, image attach, image gallery, FCK editor (the recommended version for Drupal 5.1), FAQ, fileshare, LiveSearch, printer friendly pages, search config, slideshow, tax. filter, tax. menu (the only dev module), tax super select, upload preview, JQuery Update, JQuery Interface, Message Effects.

You raise a good point, because at one point, I did try switching from Theme based search presentation to menu-based presentation, and its entirely possible I could have disabled both altogether (briefly) between turning one search UI 'off' and the other method 'on'.

I'll try to set up my own environment to test this, because this involves several layers of JavaScript function calling, and I literally have to tear the whole page's structure apart to figure out what's happening. Is there a particular theme that can cause this problem, or is it just all themes in general? If the latter is the case, I'll just use Garland.

Node 153027 is a duplicate of this issue.
I have tried to replicate this bug with Drupal 5.1, SimpleMenu 5.x-3.2, and Live Search 5.x-1.0, but the collapsible field functionality still works. No JavaScript errors appeared. I am using Firefox 2.0.0.3 on Mac OS X.

At first I tried the HEAD version of Live Search, and no errors appeared, so I thought this might be an old 5.x-1.0 bug. But then when I switched from HEAD to 5.x-1.0, there are still no errors nor any loss of functionality.

Can anyone fill in more details for me, such as your configurations for Live Search and SimpleMenu, and / or the theme you're using? That way it'll be possible for me to reproduce this bug.

Here are my Live Search settings:

Target search box:
Theme

Compact search box CHECKED

Hide snippets UNCHECKED

Show item info CHECKED

Ajax request firing delay: 1250

Update: It appears that my issue of fieldset labels not appearing on admin/build/modules only occurs after I hit the submit form to change my enabled modules. If I simply enter the path admin/build/modules in my web browser, the fieldset labels DO appear.

How about the configs for SimpleMenu?

(I tried enabling the Blog API module and then disabling it to see if I can reproduce the bug you encountered, but still nothing showed up.)

VM is running IE6.0.3790.1830 and workstation host (client connecting to Drupal VM guest on it) is running Firefox 2.0.0.4, but laptop (also client to same VM session) was running Firefox 1.5.x.something), so it might not be browser related, if that helps.

Using standard garland theme, with nothing odd done to it; some theme elements turned 'off' (site slogan, mission statement) and those elements weren't ever configured prior to turning them off. Content poster info is set to display for all except 'page'.

I tried all LiveSearch settings, but the first change I made was to lower the Ajax request firing delay to 0750 ms. I never extended that back, so perhaps that could have caused a problem. Host running VM was only running this session, and has 3 GB ram, ampe disk space, is dual core 3 GHz.

Not running SimpleMenu.

Thanks for the kind support for a donated/contributed module!

Are there any steps that can reproduce this bug? Because I've been trying hard but I still can't reproduce it, and to be honest, nothing else really helps, not even JavaScript errors. It's kind of funny how I've previously messed around with the theme settings so much that I thought I've gotten rid of all the theme-related bugs you could possibly imagine.

This doesn't work for me either. What I did:

Installed Drupal locally.
Used the default theme (Garland).
Installed LiveSearch, activated it.

Each time I did this it would break the javascript throughout the site, and wouldn't change anything about the search block. I wiped my mySQL database a few times and the result was the same.

Hope this helps.

I've just sent kourge a message with a pointer to a site showing the bug behavior described here. I was going crazy as I saw virtually all my nice jQuery behavior disappear - until I found these bug reports. Sure enough, disable LiveSearch and all my jQuery bells and whistles returned. Its probably something pretty simple.

I have a speculation on how this might be fixed. For now, please use the HEAD version of Live Search to test this, since the HEAD version does not have any known regressions (new bugs), has lots of old bugs fixed, and offers some nice new features.

First, please identify where your search field is coming from. If you turned on the field in the Block admin page, then it's from a block. If you turned on the field in the Garland config page (theme), then it's from your theme. Make sure you have to have at least one search box visible on your page. Live Search does not add one for you, since that's virtually reinventing the wheel. (Did I make this obvious on the Live Search project page? After all, this is a crucial step.) After this, go to Live Search settings and select the appropriate "target search box."

I'm not sure if the "target search box" is the problem that's causing all the issues here, but it seems like that is the case after reading all the feedbacks. Please follow up and reply if this fixes the problem. If not, please also reply.

I realize this part is perhaps the trickiest part of all when setting up Live Search, because people expect out-of-the-box functionality, and it seems like people tend to use the search block more often than the theme-provided search field. It looks like making "theme" as the default "target search box" is a wrong decision.

What I'm thinking right now is a so-called "auto targeting" behavior that tries to probe and see which kind of search box is being used and automatically use it. The question is:

1. Which kind of search box is used more frequently? Here it seems like the "search block" is more popular than the search box provided by your theme (like Garland), but it would be nice to have more feedback to confirm this.

2. What if both are present? Should both be used, or should it default to a particular type?

3. What if none are present? Should the script just throw a JavaScript error that tells you that?

Now, I might be overthinking the whole issue here, since I'm not really sure if this "target search box" is the whole culprit here, but this was one of the questions that I've thought would be very important to address.

Since everyone seems to have problems here, once this is fixed, a new release will be on its way. As I've said, the HEAD version has already accrued enough improvements and fixes.

I forgot to say, the current way the HEAD version handles a non-existent search box is that it fails silently.

Just tried re-enabling it, once for Theme-based search, and once for Block-based search, and tried both 'Compact' mode and normal. Afraid I didn't have time to try more.

Sadly, there was no improvement...

However, after the tests, and after disabling the LiveSearch module, all functionality appears to be restored and operational. So the good news is that any tests we perform don't seem to be a 'one-way' trip.

Wishing luck on finding this 'stealthy' little conflict,
dlj

Forgot to include my CAD$0.02 for future direction votes!

1. For my setup, block-based Search control is preferable to theme based, but I could switch fairly easily...

2. I would prefer consistency (so all dialogs inheriting LiveSearch functionality). But more importantly (IMHO), It is possible during testing to temporarily have two Search dialogs open simultaneously, so handling that gracefully would be my recommendation, In my case, if I ever discovered I had two Search dialogs open, I would fix it by closing the 'offensive' one (the one with an illogical layout); and I usually have more control through the Block layout, so that's my default choice.

3. A Javascript error would certainly get my attention! That's my preference, although I don't know if anyone could possibly have a site requirement that does not have a Search interface, and yet requires the LiveSearch module.

Thanks again!

Thanks to dlj, I'm finally able to reproduce the bug! This bug is similar to a bug in Fivestar; not everyone encounters it. It is related to getting descendants of an element in jQuery. Anyway, it seems that I was able to fix it, so I would like everyone to try out the HEAD version of Live Search.

Aside from the bug being supposedly fixed (try it out to confirm this!), the HEAD version supports paging, gives more control over node excerpts / metadata, and lets you specify a custom element to inject the search results. It is relatively stable (I use it on my own site), so please give it a try.

As a reminder, it would be even better if you can voice your opinion on the following questions (which I've already mentioned, but now with more emphasis):
1. Which kind of search box do you tend to use when building a site with search functionality? Here it seems like the "search block" is more popular than a theme-provided search box (like Garland), but it would be nice to have even more feedback to confirm this.

2. What if both are present? Should both be used, or should it default to a particular type? Although it is very nice to use both, this is potentially confusing. Another downside is that the JavaScript code needs refactoring if this should happen and that might introduce new bugs.

3. What if none are present? Should the script just throw a JavaScript error that tells you that? What message should it say in the error? "Live Search: no search fields found"?

Yes! Great Work Kourge, works like a charm.

Kourge - saw your post later this weekend, and couldn't wait to get back to the servers to test it!

Since there's no DB changes, the upgrade wasn't scary and was completely painless. I tested it in my older test site (the same one you recreated), and it worked like a charm. It restored the fileshare module functionality, and the taxonomy super-select module also worked perfectly, and most importantly, all core functions worked, and it even seems somehow slightly faster. Next, I tried it on my production site, which went every bit as easily, and had the same complete success.

Bravo! And unbelievably fast code changes too, once you had all the necessary details to sandbox.

This is the kind of support one gets (or rather, hopes to get) for a chargeable product.

Can't wait to poke around with the new functions, but also didn't want to keep you waiting, since you did so much so quickly.

A huge round of thanks and congrats for a slick contribution that raises the user-friendliness of Drupal a whole level.

Good! Three people have it working so far. Can more people voice their opinions on the "target search box" issue?

hmm, seems to have stopped working after an update from 5.1 to 5.2. Anyone else?

Never mind, false alarm. It was an issue with the jquery update module.

Regarding the "target search box" issue, i think it should degrade silently like it does, and in the settings have an option to be on either the built-in search, the search box, or both. I don't like the idea of a warning because what if you don't want the search box on every page? Maybe in the settings there could be a checkbox called debug mode or something that would display an alert for admin accounts only if the field is not found.

kourge,

Thanks for putting the bug fixes in HEAD. I wasn't having the SimpleMenu problem; rather the bug in node/168136 (multi-page results issue). Answers to your q's below:

1) I use the block search box.
2) Don't really know how to answer this, as I don't know what the theme search box looks like (if it's like here, on drupal.org, I would say one or the other, but not both).
3) If no search box is present, Live Search should fail silently.

Thanks - great module!

Okay, it seems like everyone's using the block over the theme's search box, so that will be the default. As for the options, I think the best way would be something like this:
* Automatically detect
* Force block search
* Force theme search
The "auto detect" would first look for the block search box, and if it's not found, the theme search box, and if that's not found as well, some other common ID names. If nothing can be found, it fails silently. The other two would exclusively look for the block or theme search box respectively, and will fail silently as well, should any error occur.

If everyone's okay with this, I'll start making changes and release a new HEAD snapshot. After yet another round of testing and if everything seems fine, I'll make a real release and start porting this to Drupal 6.

Hi;

Just a suggestion (that should probably require some agreement from other users)...

How about having "autodetect" not fail silently, but throw an error, while the 'force' block/theme options *would* fail silently. This might help people trying out the module that 'need' some feedback, while more skilled users will know their setup well, and would likely use the 'force' option.

Otherwise sounds great, and thanks for investing more time for d6 support!

What's everyone's opinion on dlj's suggestion? I personally agree with him, but if anyone disagrees, I'd like to see why, and perhaps we can sort this out.

i've duplicated this js bug
its still exist with the livesearch.module HEAD

livesearch + expanding admin menus only returns back to 'normal' when
jquery_update.module disabled + jquery.js version required (which is packed with update jquery_update.module required to be replaced by the one on the default Drupal 5.2 jquery.js in the /misc directory)

when its replaced by the default Drupal 5.2 jquery.js, livesearch functions as normal
than may mean livesearch conflicts with the updated jquery.js version (JQuery 1.0.1) packed with the jquery_update.module

First of all, from what I know, jQuery Update bundles jQuery 1.1.2, not 1.0.1. Another thing is that the jQuery bundled with Drupal is 1.0.4, which is newer than the 1.0.1 you mentioned. This can be confirmed by opening Firebug on a Drupal site page, then typing jQuery.fn.jquery and pressing Enter.

>>> jQuery.fn.jquery
"1.0.4"

Are you sure you're using the latest version of jQuery update? Are you sure you're using the latest version of Live Search HEAD?

You are right, my apologies. I was wrong on the version number bundled with jQuery Update

but also with the latest bundled jQuery 1.2. not jQuery 1.1 -as indicated on jquery.js on the bundle

meanwhile i tried the dev snapshot - JQuery Update 5.x-1.x-dev
and the bug is NOT dublicated livesearch and admin expanding items works

i advice all guys posted here try the JQuery Update 5.x-1.x-dev
that means the conflict/bug is related with the livesearch and if its not duplicated by others too the issue can be closed

great module.. thanks!

This issue has been dragging on for a while, and I want to get rid of it quickly. I want to:
1. Get a new release out for Drupal 5
2. Port this to Drupal 6

With little input, I can't do that. If no one shows disagreement with dlj's opinion on how JavaScript error-throwing should work in auto / forced modes, I'll take that as an agreement and implement it. Then, after testing I'll start doing the two things that I've mentioned above.

I'm experiencing this same problem (SimpleMenu not showing up anymore) - but I don't have LiveSearch installed. I think the problem started when I installed jquery_update (to use with lightbox2).

Cheers,
Alex

Discard my last comment - my problem was related to not having <?php print $scripts ?> in my theme's header. Btw - why doesn't this post show up under "track" for my account? Took me a while to find it - maybe it's listed somewhere else? I like the ability to subscribe to posts, but it seems like following up on issues doesn't subscribe me...

It looks like you can do it by going to:
http://drupal.org/project/issues/subscribe-mail/livesearch
I got there by first clicking Issues then clicking Subscribe on the breadcrumb.

By the way, I'll be closing this bug soon, because there's no more new feedback. I'll simply do stuff based on the current feedback that I have. So I'll push the suggestions, release a new release, and start porting this to Drupal 6.

It seems that HEAD is more stable than the official point release. I know that it works for me as where the 1.0 version does not.

Please roll out a new release so we can stay up to date with Update Status. Meanwhile, thank you for this fantastic module!

Note to self: add auto-detect functionality. I was cleaning up the code earlier this morning.

For everyone keeping up: the auto-detect feature is available for testing! Please check out the latest development snapshot two hours after this post is posted. (The packaging mechanism makes a new development snapshot every two hours.)

For what it's worth, I just lost 1.5 days of labor trying to figure out why fieldsets stopped opening/closing. Very long story short: when I disabled LiveSearch, they worked again.

I am running Drupal 5.7, with jQueryUpdate, and browsing with both IE 6 and Firefox 2.0.12, both on Win XP Pro.

Also note this: with the bluemarine theme, fieldsets work fine, even with LiveSearch installed. But with the theme called "CristalX4Drupal" they break. I will soon try the HEAD version of LiveSearch to see if this fixes the problem, as suggested many months ago in the above discussion. (Does that mean that HEAD is still the only place for the fix??)

So, is it safe to say that the problem occurs when, and only when, the user has a combination of jQueryUpdate, LiveSearch, and certain themes?

What is the "official" or approved way to fix this (for Drupal 5.7) if you need to use both jQueryUpdate and LiveSearch (and a susceptible theme)?

[As is common at drupal.org, these long support discussions often lack a clear resolution that a user can find without having to read every message in the thread (if even that helps!). Too bad drupal.org doesn't have a "latest advice" or "bottom line" section on these forms for the module author to help a user readily see the best way known thus far to fix or work around a still-open issue.]

Thank you.

UPDATE: Nope, using HEAD seemed to make no difference. LiveSearch installed, problem occurs. LiveSearch uninstalled, problem goes away.

UPDATE 2: Another JS-related problem has disappeared as a result of uninstalling LiveSearch: the "PNG Fix" module has resumed working. That module's purpose is to repair PNG transparency in IE 5.5 and IE 6. It worked fine, then it stopped working. After disabling LiveSearch, PNG Fix works again. :-) (It's also possible that disabling LiveSearch has fixed a strange problem [a vote shows up but it says that there are no votes yet] with FiveStar/VotingAPI, but that behavior improvement could be unrelated.)

Could it have something to do with your version of jQuery update? Because if something's not working, it's probably caused by a JavaScript error (one is all it takes to halt other scripts from running).

Also, when you're trying the HEAD version, can you try tweaking the Live Search configurations a bit? Having yet another glitch show up is exactly why I'm reluctant to release 5.x-1.1, let along porting this to Drupal 6.

Another question: when fieldsets stopped working, does Live Search itself work?

It's interesting to see how this doesn't break on Bluemarine but does on CristalX4Drupal. Have you tried Garland?

Good questions all.

First, I forgot to mention (sorry) that the problem occurs even when disabling jQueryUpdate and reverting to the version of jQuery that came with Drupal 5.7.

Second, I hadn't gotten around to tweaking or trying LiveSearch yet; I'd just had it enabled as something to try out when I got to it. Does that matter?

Third, I had not tried Garland. I've uninstalled LiveSearch for the time being, but when I get the rest of the site's featuers running the way I want, I'll go back and revisit this.

Thanks!

i encountered the bug using the jquery_update module that brings jQuery up to 1.1.2
i replaced the packed version of jquery with an unpacked one and step debugged the module with firebug:

 Drupal.LiveSearch.localizedTerm = localizedTerm =
    searchForm.find('input[@type=submit]').val();

searchForm.end().
    addClass('live-search').
    append('<div id="' + Drupal.LiveSearch.id + '"></div>');
  $('#' + Drupal.LiveSearch.id).hide();

searchForm.end() returns the document !

in fact, i think searchForm.end() should not be called
the way i understand http://docs.jquery.com/Traversing/end , you use end() when you reach the form through the $() function

this is not the case in your code since you're invoking searchForm.find('input[@type=submit]')

Nice detective work! But right now, for me, using this module is on the back burner for a little while (sorry).

I've been learning jQuery and all its great capabilities, and I want to use the latest version of it (1.2.3) with Drupal 5.7. However, I hear there are problems with that. So I've been reading up on attempts people have made (some reportedly successful!) to get that combination working, and I will be focusing on doing that on my main live site before I do most anything else.

(I'm sure there are a lot of people who want the big improvements in jQuery 1.2.x but cannot move to Drupal 6.x yet for various reasons.)

subscribing

Sorry for a long period of inactivity. It would seem that jQuery has quite an inconsistency when it comes to find() and end().
First, I'll be pushing a new release for Drupal 5, because I realized too many people shy away from HEAD, especially because drupal.org now hides development snapshots unless you're hunting for them.
Second, I'll be porting this to Drupal 6, because many people are still hesitant to upgrade to Drupal 6 because of Live Search. Now we don't want people to miss out on the awesomeness of Drupal 6, do we? Even I'm missing out, since my own kourge.net is still running on Drupal 5.

Good news! I have just released 5.x-1.1. It can be found on the Live Search project page, or it can be found here.
Everyone, please test out this release and see if there's any more bugs. If no bugs are reported in three (3) days, I'll start porting Live Search to Drupal 6.

Hi,
I dont have live search ( i tried deleting the module also), but still the expandable menu is not available for some views and some pages?

Any pointers what cud be the problem?

Thanx in advance.

If it's just for some pages and you're sure that Live Search isn't enabled nor installed, then JavaScript errors (possibly caused by some other module) are occurring.

It is a JavaScript problem and occurs for me only when I have Optimize JavaScript files enabled.
Go to /admin/settings/performance and Disable this setting.

I haven't had a chance to explore the WHY as yet ...

Btw I have never had LiveSearch enabled, so should this post be moved elsewhere?

Tagging as Drupal.org Redesign since this issue is holding up #220939: Porting Live Search to D6?

Meanwhile - http://drupal.org/project/finder

Linking this from the Redesign project #661686: Meta issue for Live Search because this issue was tagged 'drupal.org redesign'

.