Custom Search
Printed From: ProductCart E-Commerce Solutions
Category: ProductCart
Forum Name: Using ProductCart
Forum Description: Running your store with ProductCart
URL: https://forum.productcart.com/forum_posts.asp?TID=2204
Printed Date: 07-October-2024 at 3:28pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Custom Search
Posted By: cmason
Subject: Custom Search
Date Posted: 01-December-2008 at 3:34pm
1. Is there a menu link somewhere in the CP to "Manage Custom Search Fields"? I'm only finding that link by first going to "Manage Categories" selecting a category and then finding the link.
2. I "thought" that selecting custom search fields in the categories would limit the search fields displayed for a product but that doesn't appear to be true. For each product I still have to go in and select the fields all over again. Why select custom fields for categories if they're not going to be used within the product setup for custom fields? What if there are search fields used by a product that aren't indicated in the category? Being able to copy custom search fields from category to subCategories is nice but shouldn't that also replicate to the products? What if the product is linked to multiple categories?
3. We have an existing "specifications" database that currently has over 4000 entries, grouped by what will be 478 distinct custom fields. So far I've just imported 178 custom search fields and PC grinds to a halt. What's the max custom search fields this was designed to manage? I only see around 4-6 on the demo store.
4. I'm trying to figure how to import our existing specs into the db tables. PCCustomSearchFields is easy, although the field names caused some initial confusion. pcSearchFields_Categories s/b easy, though I'm not sure what difference it makes, except that the categories that I setup using the CP reference idSearchData entries of 3,17, 164, 170 and the PK idSearchData in pcSearchData only has entries of 1 through 5. Is that really referencing the idSearchField in pcSearchData? pcSearchFields_Products.idSearchData entries are all between 1 through 5 so that makes sense.
I see no FKs setup in any of those tables so next I'm wondering what happens if you delete a custom search field? From looking at delSearchField.asp it appears that idSearchData id is sometimes referenced as idSearchField (in pcSearchData table and in the pcSearchFields table). Correct? Why?
5. Ignoring the mappings table, I'm perplexed about why there are so many tables. I expected one to list the search field names, one for categories that would also determine show/no showlink for search fields and one that would contain the products, searchname id and entry. I don't understand splitting pcSearchData from pcSearchFields_Products.
|
Replies:
Posted By: cmason
Date Posted: 08-December-2008 at 1:18pm
I found the link buried in the long list of links under "Products". Still would like answer on other questions.
Christie Mason
|
Posted By: Matt
Date Posted: 08-December-2008 at 1:46pm
1. Correct, the link is available via “Products > Manage Custom Fields” on the main menu. The link is also available in the help manual. http://wiki.earlyimpact.com/productcart/managing_search_fields?s[]=category&s[]=search&s[]=field
2. Category search fields do not propagate to products. They have a different purpose, which is to create Drill-down menus. Category Search Fields are explained in the help manual here: http://wiki.earlyimpact.com/productcart/search_fields_widget?s[]=drill&s[]=down
3. Where is it slowing down, what page? I am happy to look into it.
4. Are you having problems deleting something? Have you tried contacting a certified developer for help integrating your specs?
5. It is a relational table. The same is true for products and categories. They are separate tables joined by a relational table. http://en.wikipedia.org/wiki/Relational_database
Please also read over the following article, which should also be very helpful:
http://wiki.earlyimpact.com/productcart/managing_search_fields?s[]=category&s[]=search&s[]=field
|
Posted By: cmason
Date Posted: 08-December-2008 at 2:10pm
5. I understand relational tables and from what I'm seeing, what s/b the PK and FK aren't always the same field name, correct? In pcSearch_Categories, it appears that PK pcSearchFields.idSearchFIELD = FK pcSearchFields_Category.idSearchDATA. There is a PK in pcSearchData.idSearchData but it doesn't appear to be related to pcSearchFields_Category.idSearchData. If there actually were relationships setup in the db then I wouldn't have to guess.
There's also no relationship between PK categories.idCategory and FK pcSearchFields.Categories but I haven't had time to see if deleting a category also deletes the entries from pcSearch_Fields.Categories. A diagram w/b very helpful.
4. I'm not having any problems deleting anything, it's just that I had to read through the delete code to verify my suspicion that PK and FK were sometimes differently named fields.
3. It's slow on every page, include file is in the footer.
2. I can see creating category->category drill downs, just wish something was available to avoid scrolling through 400+ fieldnames for categories and 400+ fieldnames for each and every product.
|
Posted By: Matt
Date Posted: 08-December-2008 at 2:52pm
2.) Are you referring to making a selection in the dropdown menu (while assigning the custom field)? If you do not want to look for the selection in the dropdown you can use the import wizard. You can put the selection in your spreadsheet and import them all at once. If you have an idea for something to replace the dropdown we will listen.
3. ) The include file is in the header or footer but is only active when drill-down menus are needed on category pages or search results. I am assuming you have a very large drill-down navigation setup on your category pages. The performance will decrease as the size of the drill-down navigation increases. We are already looking into ways to improve performance on large drill-down menus.
4. & 5) I am happy to your accept feedback for our wish list and look into possible bugs. Certified developers are available for more in-depth technical consultation.
|
Posted By: cmason
Date Posted: 08-December-2008 at 3:26pm
Yes, EI's always been very good at being open to suggestions. Something that would help a lot w/b an option to restrict the list of field names showing in the product add/edit pages to a subset of only those field names that have been used by the categories the product is joined to.
I'm looking at the database to determine how to import the existing 4000 product specs with 400 field names. I think there is a problem in the db where a different name has been used to setup a relationship between the PCSearch_Categories and pcSearchFields. Please have the developer of this module verify that.
I'm looking at the product import PDF and it show only how to import up to 3 custom search fields. Plus I already have several thousand products loaded so don't need to reimport them. I know how to use T-SQL to do a table update, but I'd like to know that I'm updating the right info to the right place. It would help to above the above mentioned db quirk verified. I think that's what I'm seeing when I look at the test data that I've entered through the control panel but I'd like to be sure.
I'd also like to have some idea of a target # of field names for categories/products that can be entered before performance degrades. Do I need to think about trimming this to 50, 100, 200 field names or just give up on using custom search for now?
|
Posted By: Matt
Date Posted: 08-December-2008 at 4:15pm
Hiding the product search fields based on category assumes you are using the category search fields, and that none of the Products (in that category) have custom search fields that are not category specific (which is not usually the case). What is the reason you do not want them to show? Is it slow to load them all? The manage search fields page allows you to hide search fields from product details screens. If you are using the import wizard for updating search fields you can just hide them all on the product details. Will that work for you?
The import wizard allows you to import 3 groups at a time. You currently need to run rerun if you have more groups. However, you can use that code to create the customization you need to import additional groups. We are not aware of any problems in the import script. If you believe there is a problem in the import script please open a support ticket and show a specific example of where the data was imported incorrectly. You will need to attach your spreadsheet as well.
|
Posted By: cmason
Date Posted: 08-December-2008 at 4:39pm
How about we just boil this down to one question?
In pcSearch_Categories, does the relationship to pcSearchFields = PK pcSearchFields.idSearchFIELD -> FK pcSearchFields_Categories.idSearchDATA?
|
Posted By: cmason
Date Posted: 09-December-2008 at 11:25am
A couple of other things I've noticed. Since pcSearchFields.pcSearchFieldName allows nulls and is not indexed as unique, a user could enter duplicate field names all day long.
I also cannot figure out why there needs to be three tables. One for products and one for categories and one for data. Why not combine them into one table and have one field "idProduct" and one field "idCategory" then idSearchField and "pcSearchDataName" (which really isn't a name so "pcSearchData" would make more sense to me) and "pcSearchDataOrder"? I suspect it would greatly improve performance and require a lot less coding.
|
|