I found this issue in the Hierarchical Select issue queue after discovering the problem in one of my views. (http://drupal.org/node/762920) and the maintainer indicates in #4 that it may be an issue with Views and not HS.
With fastsearch stuck in D5 and the taxonomy search patch being submitted to core for D8, Hierarchical Select becomes one of the best solutions for custom searches in Views.
When leaving the exposed Taxonomy:Term filter set as 'optional', aside from adding to the HS options it also lists every node until an 'optional' filter option is chosen. See http://www.sanduskyspotlight.com/biz-search-opt for an example of how it looks with optional setting on the exposed term filter left on. Functions correctly, but not optimal for using as a search block or panel.
If optional is unticked, and choosing a level out of the herachy is required, it creates a very nice HS search box that can be implemented anywhere on a block or in a panel, and does not list any unfiltered node results prior to choosing the hierachy.
Unfortunately, the warnings make it 'scary' for users and the additional warnings generated for each level of sub category would become extremely annoying in deep trees. Between that and the fact that it turns the text red in the HS drop boxes, making users think they are not supposed to be choosing that text, it becomes quite useless to make the HS filter required; however, that basically kills a very nice search refinement feature for both HS and Views. See http://www.sanduskyspotlight.com/biz-search-req for an example of the view with exposed Taxonomy:Term filter set to required.
I am not certain on this as to say "I am unfamiliar with coding" is an insult to people who have graduated to the 'unfamiliar with coding' level, but it seems to me that the warnings should only apply in the required version after someone attempts to apply the search without selecting a 'Business Type' (as categorized in my example).
Any input you can give on this would be greatly appreciated.
Comments
Comment #1
bstrange commentedWanted to add, in case you are going to test functionality of the required filter search, you can find results under:
Automotive > Dealerships
Business and Professional Services > Computer Service & Repair
Food and Beverage > Deli / Delicatessen
(Thought I'd add that in so aren't guessing at searches or pulling blank results if testing functionality)
Comment #2
bstrange commentedBeing the hack and trash cobbler that I am, I thought maybe I'd just search all Views components for the error handler
form_get_errors()which I found in views.inc and form.inc in views/includes.I thought perhaps the obvious solution would be to remove lines 418-425 from views inc:
unfortunately, that threw the following error site-wide:
Parse error: syntax error, unexpected T_CLASS, expecting T_FUNCTION in .../sites/all/modules/views/includes/view.inc on line 1619which helped reinforce the fact that you should probably have some understanding of the code functions before you remove them...
ah well, trial and error is my friend as long as I can undo my experimentaions ;)
Comment #3
bstrange commentedI made an interesting discovery while playing with this. If you go to http://www.sanduskyspotlight.com/biz-search-req , we see that the error is pregenerated before making any selection and on pageload, a 'field is required' message is already present. Selecting any category from the dropdown that has a sub category initiates the sub category's own dropdown box and again throws a 'field is required' warning before any selection is made.
Here is where it gets interesting... if you choose any primary category and hit apply without choosing a sub category, it applies the filter and returns results. Once this has been done once, you can change the primary category to any value (except the blank value at the start of the dropdown) and upon doing so a subcategory dropdown, for whatever primary category you have chosen, is generated without throwing the 'field is required' error unlike the way it functions prior to an initial search being performed.
Comment #4
merlinofchaos commentedIt sounds to me like the problem is that Views forms are *always* submitted even if the submit button was not selected, so that we can get the values out to apply to filters based upon defaults. I think that Hierarchical Select doesn't know how to deal with this situation. HS needs to be able to properly prepopulate the input ($form_state['input']) if there is no value so that it does not throw a "Field is required" error.
Comment #5
bstrange commentedThanks for the reply Merlin,
I will present this back under the issue queue for HS.
One thought on a work around (as the functionality seems relatively flawless after an initial search has been initiated) is toset a blank category as 'default'. Now in configuring the "Configure filter Taxonomy: Term" there is no option to set a default category (that I can find). Is the functionality required to implement a default category something that is implemented (or would need to be implemented) in Views, or is that functionality that would need to be implemented from within the HS module itself?
Comment #6
bstrange commentedAfter hours of cobbling and reading a lot of similar issues... (though for different modules) I managed to make it work...
The fix was to just create an empty primary category (I called it "Select Business Category" ) and set the operator to 'is one of' and then used the always empty "Select Business Category" as the entry for 'Select terms from vocabulary Business Classification', not sure how I got to a HS list that allowed me to choose a single category as default as prior to all the cobbling, it always defaulted to 'any' or 'none'. Oddly, the ever present 'Any' has been replaced by 'None' whether the filter is set to optional or not.
http://www.sanduskyspotlight.com/business-search-alpha
Unfortunately, now that I got it working, I am unable to place it in a panel as anything besides a block. When it was throwing the errors, I had it in a panel as a page, which is desirable because I want it to return results without it navigating away from the main page as it does when the exposed form is placed in a block.
Granted this is ugly.. and has a host of drawbacks (such as if someone ever actually added their business to the 'Select Business Category' category) but for the time being it works... sorta... just not in a panel , lol
Alternately, I could just use a second view to display the results of the exposed filter block that I have been able to get to work.. I haven't the slightest idea how to do that or if it's even possible, but if the top panel could be the system block and then the results view could be put into a panel below, that would fix me up in a convoluted, but functional way that doesn't take users away from the main page ;)
(sorry if my post is semi incoherent, been working on this like 7 hours straight and my poor brain is now mush)
Comment #7
Flow_TnT commentedCould CSS be used to hide the error?
Comment #8
wim leersHow should
$form_state['input']be prepopulated then? :)Comment #9
crea commentedThe problem for me is caused by HS always inserting level label. The level label when submitted makes View form validation fail.
I solved the problem in a rather hackish way: I've made Views to accept unfilled widget (level label value) but at the same time have made HS to remove "any" option that is redundant in this case. I.e. from the point of Views the filter is optional but from the point of HS it's not.
Comment #10
merlinofchaos commentedThe same way every other filter in Views does it: It tests to see if $form_state['input'] contains a value, and if it is not set, it puts the default value in there so that FAPI can process it properly.
I'm not sure, at this point, why this is marked as a bug in Views. Ultimately the problem is FAPI and we have crappy workarounds to deal with the fact that FAPI made assumptions that we don't want to be true (namely, exposed filters like to create new URLs so that you can link to them directly).