Jump to content

Product Options and Search


JackP
 Share

Recommended Posts

This is an incredibly interesting thing to try to do. On the surface, this sounds like an easy thing to implement.

However, the way CC6 is coded, the exact row in the Options Matrix Table is not known until all selectable options have been selected.

For example, the customer chooses Style: Long Sleeve, and then chooses Size: 22in., then chooses Color: Blue.

These options, each by themselves, do not resolve to a Product Code. (It is not impossible to add data-abc attributes to the list of values of an option group if the product has only one option group, Color, for example.)

Link to comment
Share on other sites

Indeed, and with respect to jumping to a product page and pre-selecting options based on a matched matrix entry, given the matrix options_identifier (easily retrievable from the database during e.g. a search), there is no simple way of determining which options would need to be selected.

The only way I can think of is to re-generate all possible product combinations and their resultant matrix options_identifier much like CubeCart does when initially populating the matrix, at least until a match is found. While this would indeed work, it does add overhead to the page load times especially for a product with many matrix options.

As for the SEO issue raised by JackP, that would only be possible if each option mapped individually to a product code / SKU / UPC; for the vast majority of products, this is not the case.

What if the product code / SKU / UPC was dynamically added to the page once all required options were selected? See for example this page, under the Specifications tab - the product code updates based on the selected options, and there is no reason why the UPC or other fields couldn't behave similarly (in fact, the weight and dimensions on that page also dynamically update, it's just not noticeable because they are all the same for this product).

Link to comment
Share on other sites

It is very do-able. I made a Dynamic Stock Indicator (http://www.cubecartforums.org/index.php?showtopic=19100) that gets the details once all option groups have had a value selected. This is an AJAX request.

In the case of this SEO situation, I believe the need is for the data to be in the raw HTML, prior to any javascript trickery.

It would be trivial to fetch all the records from the Cubecart_options_matrix table for a product, and embed that raw recordset into the HTML. It doesn't have to display, just be scrapeable in the raw HTML.

But, with a bit of preparation, this data could be JSON-ized in such a way that javascript could use it for immediate calculations.

"the product code updates based on the selected options,"

Where is the javascript that powers that on this site? I would like to give a glance.

--I found it.

Link to comment
Share on other sites

It's powered by AJAX in the same fashion as (I presume) your dynamic stock indicator (and in fact it also dynamically updates stock levels among other things).

The issue I was describing is going backwards from a matrix options_identifier without knowing any of the selected options, and having to figure out what those option selections should be. I'm thinking about this because you would only have the product_id + possible options_identifier available after a search result and would have to then extrapolate which options need to be selected when auto-navigating to that page or otherwise building specific links.

In the case of adding all matrix product_codes, UPC, etc. to the HTML, that would indeed be trivial except that it isn't possible to tie them to specific options selections as in the example JackP used. I'm not that well-versed in SEO practices, so I'm not sure if that example is something to aim for or if simply adding them anywhere in the HTML would be sufficient.

Link to comment
Share on other sites

In the CubeCart_options_matrix table, there is also the cached_name string.

Having retrieved the one record that matched the UPC, with some judicious string splitting:

<strong>Color</strong>: Black, <strong>Size</strong>: 4-Cell

Split on comma:
[0] => <strong>Color</strong>: Black
[1] => <strong>Size</strong>: 4-Cell

Split on colon to striptags(key) => value
[Color] => Black
[Size] => 4-Cell

Then apply this to the options selectors.

Link to comment
Share on other sites

I'd much prefer using the option_ids and value_ids directly from the database, but what you've proposed is a potentially viable solution... I'm just always hesitant to use strings in that manner, especially ones that are both cached and potentially language-specific.

Still, the performance of your proposal is bound to be vastly superior to iterating through all possible option combinations building options_identifiers until a match is found, most notably as the number of options increases. It's certainly worth giving a try!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...