A more refined product search

Zen allows you to setup categories and sub categories to help site visitors "drill down" to the products that they want. I'm setting up a music site. The category/sub-category feature is not the most elegant solution for this type of site because there are too many options to list here. The Genre list box allows visitors to select one criteria option but I want to allow users to choose Genre, Tempo and Mood. Can anyone help me figure out how to set up three boxes to do this. This is the same request that went unanswered in this thread

http://www.zen-cart.com/forum/showthread.php?t=52499

It can be done, but would require some serious programming skill and Zen Cart knowledge. I did something similar recently on this site.

Although at first glance that won't look like what you're looking for, generically it's similar except that the conditions visitors select from are represented as pulldown menus rather than the explicit lists used by the Bluefly site referenced on the thread to which you refer.

I did this by creating a new product type (although it could conceivably be done via attributes, though that would probably be more complex). I then wrote a search function based on Zen Cart's advanced search, to process the parameters that I was passing it as $POST variables. Though if you wanted something that worked more like Bluefly you would probably load each selection as it is made into the URL parameter string and then extract them from there for processing.

Thanks kuroi. You presented a good solution but what I had in mind uses the Zen sideboxes more directly. How can I use Genre, Artist and Record Company, sideboxes and change label to read Genre, Mood and Tempo (that's the easy part) but also make them "sticky" (that's the hard part) so the user can selecting one, two or all three options in order to create a list based on their multi-dimensional criteria? Currently, these side boxes will reset after the user releases the mouse button allowing for only one type to be listed. If I can change the behavior of these three sideboxes, then I can achieve this without the need of a "send" or "ok" button.

Your assessment of the area that would be difficult is absolutely correct. These sideboxes will give you a reasonable set of code to get the info that that you need to display for selection, but then tying the selected data together will be very difficult, primarily because it's not designed to be so.

Personally, I'd create a new sidebox containing all three of the factors you want in your filter by copying the relevant code form the three existing sideboxes, and tracking the settings in a $_SESSION array.

Then I'd create new custom pages based on index_categories and product_music_info to display the information selected, by creating new "header" and "main_template_vars" files in the relevant modules/pages folder to filter the results using as many of your three data items as part of the database extract filter conditions as are set.

kuroi, Thank you for your reply. I can see that this is already becoming complicated. Just a few questions. If I create a box containing all three of the factors, then how does the user combine factors? Would that be managed by the $_SESSION array?

Yes. Each time the visitor makes a selection the information is sent back to your server and the page is re-drawn based on the new information. Specifically, by adding a filter to the search for the page that is being displayed. This information is passed in a $_GET or a $POST variable that survives only until the page is redrawn. So you need a method of keeping the information longer. A $_SESSION variable (or array) would do this for you.

You would then add filters to the search for the page you are displaying based on the contents of that array. Although conceptually simply, this is the point at which the (necessary) complexities of Zen Cart's structure will prove the most challenging.

You should also be aware that you will be operating in an area that may change in Zen Cart 1.4, whose plans include> 1.) Introduction of new improved database abstraction layer

2.) Significant reductions in database queries
...
5.) Standardize functionality and appearance of the product-listings pages
(from the Zen Cart Roadmap)

I would like to customize the product search to provide visitors a more detailed product search result. I am building a site for unique house plans and will need search features such as square footage, bedrooms, bathrooms etc.

url to this thread removed*

Any input, instructions or direction would be greatly appreciated. Thanks.

Moderator Note: Please do not start a NEW thread when a thread with the topic is already in place. Thank you.

primehouse:

I would like to customize the product search to provide visitors a more detailed product search result. I am building a site for unique house plans and will need search features such as square footage, bedrooms, bathrooms etc.That sounds generically very similar to the situation that we faced when developing the custom search facility on the site that I referenced above.

The client wanted some very specific items to be included in the search such as location, material condition, available date and minimum quantity. Here's an outline of what we did:

1. We created a new product type and extended the product table (initially we created an extension table that complicated all the SQL queries).
2. For those fields that could be categorised we built new lookup tables and an Admin page for maintaining them.
3. We wrote a series of functions to extract these lookup values into arrays ready for use in pulldown menus in both Admin and the Catalog search.
4. Normally you would then create an Admin handler for the new product type to be used in Admin for maintaining these products with their extended data - in our case it was slightly different as the client's customers will be entering data themselves, so we had to build in a lot of validation, and we wrote a completely new Catalog page to manage this process, validate the inputs and update the database.
5. We then cloned the advanced_search and advanced_search_results templates and their associated modules/pages folders. This cloning isn't strictly necessary, but seemed like a good idea as the pages folders aren't yet officially over-rideable.
6. In the header_php.php for the advanced search equivalent we actually collate the information from the lookup table and collect any data that the user has already entered into the form for redisplay if they have made an input error.
7. In our tpl_advanced_search_default.php clone file we build the form using this data and the zen functions in html_output.php.
8. It really comes together though in the advanced_search_result/header_php.php clone. Here we validate the inputs, load the message stack if there are any and send the user back to the search page. Or, if there aren't, we construct the search query according to the selections made by the user.
9. The tpl_advanced_search_result_default.php clone simply calls the custom product listing template module that we wrote for product type. This is head9ing towards the boundaries of your question, but can;'t really be left out ... having added fields to our custom product type we needed to either change all the listing pages (products_all, products_new, featured, specials and categories, or write a new custom listing module to replace all of them. We did the latter.
10. The customer listing template module calls a custom module that actually runs the search for the advanced searches (and in fact all other types of search) and prepares the results for display before returning control to the template module which actually formats and outputs the display.
11. In addition, we built a customer product_info page that included to handle the extra data fields.
12. And of course, we both created new language files and made oodles of changes to some of the existing ones.
    Although this may sound fairly straightforward, the real challenge was in handling the enormous amount of detail required to get all of these changes right. Even now when I look back, I am surprised at how much effort and energy that took. So the real challenge is not so much understanding the overall approach, as not getting lost in the enormity of the detail that you have to handle.

So there's a lot of work here, but you will learn a huge amount about Zen Cart by undertaking it.

If anybody knows of a more straightforward approach that doesn't compromise Zen Cart's architecture, I'd be very interested to hear it.

Thanks Kuroi, you have definitely put quite a bit of effort into this. I appreciate it!

All I really want to do is allow people to search by attribute, which currently is giving me now results for any products... What about that?

Hi all,

I would also like to be able to search by attribute... anyone know a link to doing this or how to do it...

Thanks in advance

(Sorry for digging this back up...)

Hey Kuroi, would you like to resell what you've developed. I'd definitely like to have this feature.

Please reply or PM.

THanks

I am also really interesed in this software.
Want to sell clothes, but the size of the clothes in an attribute.
I have categories by brand and not by size.
Is there any way to present it that in the productlisting you can search on the size attribute??

Me too, I sell autoparts among other stuff and this could an great addition to my site as parts are located based on engine model and year...

kuroi:

That sounds generically very similar to the situation that we faced when developing the custom search facility on the site that I referenced above.

The client wanted some very specific items to be included in the search such as location, material condition, available date and minimum quantity. Here's an outline of what we did:

2. We created a new product type and extended the product table (initially we created an extension table that complicated all the SQL queries).

3. For those fields that could be categorised we built new lookup tables and an Admin page for maintaining them.

4. We wrote a series of functions to extract these lookup values into arrays ready for use in pulldown menus in both Admin and the Catalog search.

5. Normally you would then create an Admin handler for the new product type to be used in Admin for maintaining these products with their extended data - in our case it was slightly different as the client's customers will be entering data themselves, so we had to build in a lot of validation, and we wrote a completely new Catalog page to manage this process, validate the inputs and update the database.

6. We then cloned the advanced_search and advanced_search_results templates and their associated modules/pages folders. This cloning isn't strictly necessary, but seemed like a good idea as the pages folders aren't yet officially over-rideable.

7. In the header_php.php for the advanced search equivalent we actually collate the information from the lookup table and collect any data that the user has already entered into the form for redisplay if they have made an input error.

8. In our tpl_advanced_search_default.php clone file we build the form using this data and the zen functions in html_output.php.

9. It really comes together though in the advanced_search_result/header_php.php clone. Here we validate the inputs, load the message stack if there are any and send the user back to the search page. Or, if there aren't, we construct the search query according to the selections made by the user.

10. The tpl_advanced_search_result_default.php clone simply calls the custom product listing template module that we wrote for product type. This is head9ing towards the boundaries of your question, but can;'t really be left out ... having added fields to our custom product type we needed to either change all the listing pages (products_all, products_new, featured, specials and categories, or write a new custom listing module to replace all of them. We did the latter.

11. The customer listing template module calls a custom module that actually runs the search for the advanced searches (and in fact all other types of search) and prepares the results for display before returning control to the template module which actually formats and outputs the display.

12. In addition, we built a customer product_info page that included to handle the extra data fields.

13. And of course, we both created new language files and made oodles of changes to some of the existing ones.

Although this may sound fairly straightforward, the real challenge was in handling the enormous amount of detail required to get all of these changes right. Even now when I look back, I am surprised at how much effort and energy that took. So the real challenge is not so much understanding the overall approach, as not getting lost in the enormity of the detail that you have to handle.

So there's a lot of work here, but you will learn a huge amount about Zen Cart by undertaking it.

If anybody knows of a more straightforward approach that doesn't compromise Zen Cart's architecture, I'd be very interested to hear it.
Kuroi,

any chance you can post example files of this tedious process? how similar would they be to MOKUs example downloads?

~elastic

elastic:

any chance you can post example files of this tedious process?Sorry, but this was done as part of a much larger project which included an explicit condition that we would not release any of the code.
elastic:

how similar would they be to MOKUs example downloads?I'm not familiar with "MOKUs example" so can't say.

kuroi:

Sorry, but this was done as part of a much larger project which included an explicit condition that we would not release any of the code.
I'm not familiar with "MOKUs example" so can't say.

Possibly you could talk to you client and request the code be "donated." It is obvious that their contribution would benefit many other ZenCart supporters. You should explain that the core software that they are using was taken from the innovative hard work of literally thousands of developers who did not make a dime from it. It is about collective and collaborative development, not theirs for the taking, that is unless they paid a fee equivalent to building ZenCart from scratch, which would be how much? A million dollars?

Your contribution would definitely be appreciated :smile:

kuroi:

Sorry, but this was done as part of a much larger project which included an explicit condition that we would not release any of the code.

Isn't that similar to when Amazon was being sued because someone thought they had Patented the 'one-click checkout'? :wink:

Sounds like a basic coding job that anyone could be hired to do. A bit above my mySQL knowledge but I can contribute JS code for a 3 step dropdown list.

Choosing 1rst dropdown populates the 2nd with predefined entries and the 2nd will populate the 3rd.

Not sure if that is the type of "look" people are wanting but it's an option. :smile:

softomatic:

Possibly you could talk to you client and request the code be "donated." It is obvious that their contribution would benefit many other ZenCart supporters. You should explain that the core software that they are using was taken from the innovative hard work of literally thousands of developers who did not make a dime from it. It is about collective and collaborative development, not theirs for the taking, that is unless they paid a fee equivalent to building ZenCart from scratch, which would be how much? A million dollars?

Your contribution would definitely be appreciated :smile:For reasons that are hopefully obvious, I don't plan to enter into discussion about the contractual arrangement between myself and a client.

However, it's worth noting that this was a large, complex and very specific development and is unlikely to be of much use to anybody else anyway. However, the overall approach would be, and that is freely available earlier in this thread.