Saved Searches not saving the HS filter values
sdsheridan - August 13, 2008 - 21:55
| Project: | Views Saved Searches |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | minor |
| Assigned: | Wim Leers |
| Status: | won't fix |
Jump to:
Description
I'm using Views Saved Searches, which was saving my searches fine until I implemented Hierarchical Select in my view for a location filter. Before, I had a simple multi-select box / list for a location filter, along with nine other filters, all of which were being saved. Once I updated to the latest version of content_taxonomy, HS rc2, and patched the view.module file, the other nine filters (all of which are simple multi-select lists) still save fine, but the location filter does not. I've set up the taxonomy and the filter as indicated in http://drupal.org/node/295016.
What am I doing wrong?
#1
Hah, a Saved Searches user! Either Saved Searches is so incredibly stable, or so few people are using it. I bet it's the latter :P
Did you check the status report? Can you give me access to this site?
#2
I can... what's the best way to do that?
#3
Use my contact form to send the login details.
#4
All kinds of weirdness on your site.
- The Remove checkbox isn't being hidden… because something on your site breaks the JS.
- The HS in the exposed filters still causes a hs_form_build_id to end up in your GET parameters. This is again reason to believe that something on your site breaks the JS. If it's not that, then you must have somehow installed HS incorrectly, because it's working just fine here, and has for many people for quite some time.
- Your site has a boatload of modules.
Enough reasons for me to won't fix this support request. You'll have to investigate this closer yourself.
#5
Hmmmm... ok, well, any ideas of where I might begin?
#6
I think this is also strongly related to http://drupal.org/node/295016, which has been fixed. Marking as duplicate for now, but if you find that it still doesn't work, feel free to reopen.
#7
I just tried the dev version and my other problem of the selections not sticking around (http://drupal.org/node/295016) does indeed seem to be solved with this one (nice work!), although had to do some double-clicking on the below-first-level dropdown listboxes (which I read someone else was also doing) in FireFox, although Safari seems fine. Haven't had the chance to try it in IE7 yet.
However, the hierarchical select fileters are not being included or appropriately recalled still for saved searches. :( was hopeful.
#8
This is actually a saved searches bug. It should trigger the
prepareGETSubmitevent on each Hierarchical Select in the exposed filters form.#9
Awesome. Glad you discovered the issue. Any idea on an ETA? I'm using the saved searches in production now (so yes, there is at least one site ;-), so this would likely be the last thing keeping my from doing a wholesale upgrade of content_taxonomy, hierarchical_select, and views_saved_searches.
#10
I'll try to do it before September 5, which is the day I will leave on a internetless vacation.
#11
That would be great! Thanks!
#12
Wim:
Any progress on this?
Thanks, Shawn
#13
Wim:
Wondering if there's anything I can do to help move this along. This is the only thing that's preventing me from upgrading my site to the newer version of HS.
Thx, Shawn
#14
Wim:
Any ETA on this bug fix? I've tried to look at the code, but am not quite sure exactly what needs changing. Is it something relatively simple that you could point me to doing the actual code work, or... ?
Thx, Shawn
#15
OK, I think I might have figured this out. Is the following correct? This is in the views_savedsearches.js file:
function ahahSaveBeforeSubmit(formData, jqForm, options) {
var $name = $('div#view-'+ view_name +'-views-savedsearches-container div.views-savedsearches-save-ahah form:first input#edit-name');
// Validate the name field.
if ($name.fieldValue()[0].length == 0 || $name.fieldValue()[0].length > 30 ) {
alert("You must enter a name for this saved search (maximum 30 characters)!");
return false;
}
// The form is validated, it will be submitted. Now let's add the form
// data of the views filters form, to save it.
// Remove the Hierarchical Select form build id and the form id, to <--- start of code to account for Hierarchical Select
// prevent them from ending up in the GET URL.
$('#edit-hs-form-build-id, #edit-views-filters, #edit-views-filterblock').remove();
// Prepare the hierarchical select form elements that are used as
// exposed filters for a GET submit.
$('form#views-filters, form#views-filterblock')
.find('.hierarchical-select-wrapper')
.trigger('prepare-GET-submit'); <--- end of code to account for Hierarchical Select
formData.push({ name: 'views_filters_form', value: $('form#views-filters').formSerialize() });
return true;
}
This now seems to be working, although I'm having multiple-choices problems with rc7 of Hierarchical Select at the moment, so can't be sure it's saving every choice just yet.
shawn
#16
Unfortunately, I don't have the time anymore to work on this module. So until you can provide a patch, I'm marking this as won't fix.