[imac]

When I online shop for shoes, I select size 46 in the filters and if store does not have such filter, i remember not to visit that store again.
Store built on cs-cart would be escaped by me because the size is option there, and option variation is not product in cs-cart and it cannot be filtered. Same problem with colors. Color could be filtered only if it is not option of product.

This will be fixed in CS-Cart 5.0.x and we will add filter by options.
The main problem was that each product has its own options or could have a global options. Taking into account that there are also possible multilangauge name and dublicate variants for the options, filter by options could work unexpectedly.
In CS-Cart 5. we will leave only global options with personal variant values for each product.

Another nonsense, I have 3000+ products but cs-cart admin says it is only around 700 of them. Option variations are not products and thus are not counted. Is there any political reason for such discrimination? I do not see any reason at all. If this is just a mistake then it must be fixed. When i paid for my license i expected fully functional filter, not a trick.
Please, can anybody explain this?

Did not hear about this problem previously. The reason is CS-Cart architecture, we store option combinations in a separate DB table.
In fact CS-Cart options can be used in two main cases:
1) As an extra option for a product than can be "package", or business card properties. In this case you do not create option combinations, and track such product as one. And in there is no reason to track such variants a separate product.
2) Option combinations, this is I suppose your case, you create combinations and track each of them as a separate product.
But please keep in mind that in some cases admins create combinations just in order to have a combination image, and do not track it.

In other words to see a product combinations you have to go to the product page. Combinations are not displayed on the product list and thus are not counted.

[imac]

From RC to final is there going to be 3 Month lead time as usual?

Gizmo, Right now we plan the release for the end of April.

[Olof]

This will be fixed in CS-Cart 5.0.x and we will add filter by options.
The main problem was that each product has its own options or could have a global options. Taking into account that there are also possible multilangauge name and dublicate variants for the options, filter by options could work unexpectedly.
In CS-Cart 5. we will leave only global options with personal variant values for each product.

Did not hear about this problem previously. The reason is CS-Cart architecture, we store option combinations in a separate DB table.........

Imac, can you indicate whether CSC is considering to change the current CS-Cart architecture of storing option combinations in a separate DB table? And put all products into 1 DB table? Even if it is in version 5.0 or 6.0 or..?

thanks

[imac]

Imac, can you indicate whether CSC is considering to change the current CS-Cart architecture of storing option combinations in a separate DB table? And put all products into 1 DB table? Even if it is in version 5.0 or 6.0 or..?

thanks

Olof, yes we are considering it, but no decision yet.
We are investigating possible pros and cons of such refactoring.

[Olof]

Olof, yes we are considering it, but no decision yet.
We are investigating possible pros and cons of such refactoring.

Imac, great to hear that it's a topic of consideration! I fully realize the big headache for you guys to refactor, but in my humble opinion, very necessary. Wish you lots of wisdom during the investigation..

[e-carter]

In other words to see a product combinations you have to go to the product page. Combinations are not displayed on the product list and thus are not counted.

... and thus they cannot be filtered. Really. How would CSC work with options filter when its added. Combinations or just option variants, f.i. color, each has individual picture. If i filter for certain color, on the result page i will see the default picture of product. So then you need the code which would show picture of filtered color in place of default one on the result page.
Option variants have to be fully legal products. Otherwise CSC is hard to communicate with miulti-channel marketplace sales services. They are dozens already for us but without CSC integration.
When we think about bigger store, product filter becomes first priority. And most valuable feature of store. An example. I am looking for multi-channel solution and have to try different carts. Bigcommerce $80/month plan is right for me but it does not include product filter. I asked salesman why you do not offer filtering as an option at reasonable price. He said that only way to get filtering is to select $200 plan. So $80/month for everything and $120/month for product filtering only! He said it worth.
It really does, i think.

[tbirnseth]

Gee, no one has yet asked for a date for V5.0? You guys are falling behind.....

[P-Pharma]

lol. Please no CSC5 this year. I don't want to have all my addons and styles rewritten again. CSC 3 → 4 was a disaster that kept us hostage for 1.5 years. Now finally we can go live with our CSC4 stores and there is already talk about CSC5.

[tbirnseth]

V4 was a huge change. Hoping V5 is just going to be visual and not really functional as it relates to doing all the pointless (but very tedious) changes like directory locations/names, adding namespaces that are never used by anyone else, and all the other "gee, let's do it this way because I saw some other development organizations doing this". When CSC gets to the level of Amazon then some of these things make sense. But given that they've chosen to go to V5 rather than V4.4 I'd assume there will be tons of compatibility shortfalls and we will all have to start over one more time.

Do note that Magento sticks to their architecture so that addon developers don't have to re-release everything each year or so.

Note that for us, we don't even take advantage of lots of their new things because we had to find our own way to do them because of the lack of functionality. I.e. the ability to upgrade addons and also to add language variables to installed addons. We've been doing this the same basic way since V2. So when their method for integrating our addons into their view of what an addon upgrade "should be like" happens, my bet is that we will stick with our own tried and true methods.

[P-Pharma]

But given that they've chosen to go to V5 rather than V4.4 I'd assume there will be tons of compatibility shortfalls and we will all have to start over one more time.

I wish everybody good luck with that. I think that I will stick to v4 and check back when v5 is stable or maybe even v6. v3 to v4 was one big rollercoaster for me. I envy everyone who did stick to v2 and skipped v3 entirely. I like where v4 seemed to be heading. 4.3 looks to be shaping up great. I wish that CSC would keep following that road and that we would see a 4.8 at some point.
In any case: I'm not starting over from scratch again.

[The Tool]

Yep, 2.2.5 is still purring like a kitten but I am starting to get worried about deprecated server software.

On a side note, has anyone ever tried/tested altering CSC tables to innodb?

[Olof]

Gee, no one has yet asked for a date for V5.0? You guys are falling behind.....

lol. Please no CSC5 this year. I don't want to have all my addons and styles rewritten again. CSC 3 → 4 was a disaster that kept us hostage for 1.5 years. Now finally we can go live with our CSC4 stores and there is already talk about CSC5.

V4 was a huge change. Hoping V5 is just going to be visual and not really functional as it relates to doing all the pointless (but very tedious) changes like directory locations/names, adding namespaces that are never used by anyone else, and all the other "gee, let's do it this way because I saw some other development organizations doing this"....... .

Hmmm, I suppose my question/comments to Imac are the primary reason for these comments. So I feel the need to respond:

1. I fully understand that those of you with existing investments (time/money) into working custom solutions are not happy with any big changes in CSC. No arguments there.
2. However, I'm now at that crossroad where you all were a few years ago. I.e. to decide if investing in major custom adjustments in CSC is worth it, or if I should (reluctantly) start looking for another solution. And since these adjustments will require changes in the architecture, I believe it's reasonable to ask CSC whether such changes are on their product roadmap.
3. And no, this underlying product variant architecture issue in CSC can't be put away as just "gee, let's do it this way because I saw some other development organizations doing this"....... . I don't know if your comment was specifically referring to my post/question, but in case it does.. I disagree. I won't bother everyone here by repeating the 'why' here, but you can read it in another post (http://forum.cs-cart...ed-child-items/) and in the uservoice request http://cscart.uservo...y-amazon-and-go

Cheers,
Olof

[shoppingmantra]

Hi imac,
Can you add tracking number barcode in 4.3.1. You already have order number barcoding so adding a shipping tracking number in barcode form should not be a big task for you. Please do it as it will be benificial for us. Currently we are putting barcodes manualy which is very time taking job. Shipping companies doesn't accept shipments without Order and tracking number barcoding.

[P-Pharma]

Olof, I completely agree with you that CSC would greatly benefit from overhauling the options / variants functionality. Just like that are various other things that would be awesome to have. But if you are at a cross road to invest or not then consider to learn the past. v2 was in need of an update. v3 was the overhaul with many improvements. We started development on many addons and websites, but before v3 was stable it was already abandoned for v4. CSC 3.0.6 was the last version of v3. Then it took 1.5 years of monthly postponements before v4 finally came out. Now we are at v4.3.1 and finally we are seeing some stability of the product and good direction. A new overhaul of the product likely means that v4 is development is stopped and no stable product will be reached for a very long time. History shows that its not wise to go live with CS-Cart and addons before 5.1.1 is out. I don't know the future but it seems at least 1.5 years away.

If I knew that v4 was going to take as long as it has, then I would never have waited for it. Instead I would have used v2 and move over to v4.3 now. And then move over to 5.1.1 whenever that is out.

But even that approach there is one issue: it seems that CSCart gets rewritten before a major release is allowed to mature. We are lucky enough that CSCart has a very rich addon ecosystem. But how much sense does it make to develop larger or a large number of addons when you know that it will stop working within a few releases? If you start developing at 5.0.1 release and complete everything you need around 5.3 then chances are that next up is CSCart 6.0 so you can start over from scratch again. Round and round you go.

And this is the dilemma.

[tbirnseth]

On a side note, has anyone ever tried/tested altering CSC tables to innodb?

I have done it on some sites where full table scans are blocking queries until complete. I think you need to be selective and understand that if you optimize the reads (so your clients get a good experience), you might get slower on updates on the back end. I would never do it for the orders table but products, categories, pricing, users, etc. are all good candidates for innodb. Just MHO.

I did solve problems on these sites but do note that these were large, active sites

[tbirnseth]

Hmmm, I suppose my question/comments to Imac are the primary reason for these comments. So I feel the need to respond:

My responses were from a developer perspecitve trying to produce "commercial" (not necessarily custom) addons. But then any custom work that has been done for clients always seems to require analysis and maintenance to adapt to the changes. I have no problem with adding functionality. But I also think care should be taken to provide compatibility where possible and changing things for the sake of change with no customer/vendor benefit is extremely frustrating (like customer-->frontend, admin->backend, removing DIR_ constants, etc... All could have been either not done at all or done in a manner that still supported existing implementations).

[e-carter]

I think that only compatibility add-on included in CSC can make happy both who wants keep CSC consistant and stable and those who want to see it compatible with world standard approach.
Such add-on would just replace part of program that serve options with new one that organized differently. Then all the products would be filled in same table(-s) while option parent products would be an abstract representing option group.
Also, with suggested add-on, implementing product filtering (with option variants included) would not be an issue.

Edited by e-carter, 08 April 2015 - 08:44 PM.

[Olof]

P-Pharma, & Tbirnseth,

Thanks for responding. Very insightful (and worrisome..) information regarding your migration, stability, development & upgrade experiences. We started at 4.1.3 and have not done any migrations yet, So we have been blissfully unaware of such issues.
Definitely food for thought for us on how to proceed further.
Thanks again

[mokeshop]

aby news for bullet (4.3.1) ???

[mokeshop]

ps when in cs cart 5 planned? year?