Cs-Cart Progress: February 2019 Video Report

CS-Cart Progress: What We’ve Done in February 2019 - YouTube

What we’ve done:
00:41 – JQuery updated from 1.9.1 to 3.3.1.
01:44 – information about vendors’ activity on the dashboard in Multi-Vendor.
03:57 – vendor invitation functionality.
06:37 – new product variations based on features.
10:26 – online chat via Telegram.
14:00 – research: warehouse-based stock management.
17:06 – storefronts for Multi-Vendor.


What we’re working on:
18:56 – one-page one-step checkout in 4.10.1.
19:55 – final adjustments to the new product variations; they will be released and out of beta in 4.10.1.
20:43 – storefronts in Multi-Vendor.
21:06 – mobile application for vendors.
21:59 – improvements to our Marketplace of third-party add-ons.

Developing a new edition when the MVP is still work in progress with many unsolved issues and lots of addons either in BETA state or not working because of internal incompatibility - is not a good idea. Either you discontinue MVP - if it has not succeeded to accrue a substantial client-base of, say, 100 users, - or make it more attractive to the potential buyer by adding multi-stores to its base functionality.

Developing product variations looks like solving cases in higher mathematics when the basic arithmetics of MVP is still not working...

Will customer side, skin ever be updated ?? I understand that from techy side cs-cart may be ahead, but from what customers feel see, what skins available in marketplace cs-cart is 5 - 10years behind..

why cs-cart is not making its root page https://www.cs-cart.com/with product skin ?

Will customer side, skin ever be updated ?? I understand that from techy side cs-cart may be ahead, but from what customers feel see, what skins available in marketplace cs-cart is 5 - 10years behind..

why cs-cart is not making its root page https://www.cs-cart.com/with product skin ?

CS-cart is all about adding more and more features...

Branding, user interface is not their forte...You will never hear them talking about branding options or enhancements..

You will also not hear about user interface improvements enhancements..

Cs-cart is run by engineers and coders so it will always be about features..

I just dont understand this, why u dont add product barcode? All systems want barcode, amazon google ebay what u know, but cs-cart still dont plan barcode. Just add two field thats all

I've asked for the product barcode (gtin, ean) multiple times in different threads. No response so far from the cs-cart architects team.

It should be moved to cscart_products table, it's the only logical place to be. It's not a feature, it's not translatable and it would highly improve datafeed generation for amazon, google, ebay etc.

Could someone finally tell us, why you don't want to do this?

Before cs-cart I had cart from other coders also from Russia who so improved their code constantly that it is out of business now...

It is a real shame that no decent coders designers join. The choice for templates is soo poooor. Probably no more then 5 temples all others are just color patterns..

CS-cart is all about adding more and more features...

Branding, user interface is not their forte...You will never hear them talking about branding options or enhancements..

You will also not hear about user interface improvements enhancements..

Cs-cart is run by engineers and coders so it will always be about features..

Will customer side, skin ever be updated ??

I understand that it would be great for a CS-Cart user to get an all new and awesome look in one of the updates. Still, everyone would need to tailor it for their needs, and third-party developers might have to update their add-ons to work with a new theme.

Although a new theme isn't planned at this time (whether or not it will be added in the future depends on demand for it), we are planning to rework the checkout page in version 4.10.1. In my opinion, that does count as an improvement to the customer side.

I've asked for the product barcode (gtin, ean) multiple times in different threads. No response so far from the cs-cart architects team.

It should be moved to cscart_products table, it's the only logical place to be. It's not a feature, it's not translatable and it would highly improve datafeed generation for amazon, google, ebay etc.

Could someone finally tell us, why you don't want to do this?

It's just my personal opinion, but I think that having all those extra fields by default would detract from usability and clutter the interface. That's why extra fields are added as "Features". Custom product fields (as in, the fields that not everyone would use) are exactly what the functionality is for, and the "Google Export" add-on even adds those features (because Google requires them).

As a non-programmer, I see only one problem here: the fact that it required to specify the value of a "Text" feature multiple times for different languages. I can't promise anything just yet, but I'll ask if we can do something about it.

It's just my personal opinion, but I think that having all those extra fields by default would detract from usability and clutter the interface. That's why extra fields are added as "Features". Custom product fields (as in, the fields that not everyone would use) are exactly what the functionality is for, and the "Google Export" add-on even adds them.

As a non-programmer, I see only one problem here: the fact that it required to specify the value of a "Text" feature multiple times for different languages. I can't promise anything just yet, but I'll ask if we can do something about it.

Ikoshin, there are multiple problems with not having barcode (gtin, ean) as a field in cscart_products table.

1) Performance in datafeed generation. If you have 300 products in the db and only 1 data feed you will feel no difference. If you have 40 000 products nad 10 different datafeeds, you will see significant performance boost.

2) Duplicated values for many different languages.

3) No ability to display different value for different variation in new product variations (e.g. There is a t-shirt in 3 different colors and each color has 3 different sizes: S M L - you can only set different barcode as a feature only for different colors. If each phisical product - color/size has it's own barcode, you cannot display them on the product page).

4) Barcode is a globally unique identifier - there should be a check if such a value exists or not in the database on save the data event.

Why did the cs-cart company updated their company website now many times..

Why you dont you simply sell your cart from your original demo store?

I understand that it would be great for a CS-Cart user to get an all new and awesome look in one of the updates. Still, everyone would need to tailor it for their needs, and third-party developers might have to update their add-ons to work with a new theme.

Although a new theme isn't planned at this time (whether or not it will be added in the future depends on demand for it), we are planning to rework the checkout page in version 4.10.1. In my opinion, that does count as an improvement to the customer side.

https://youtu.be/-Rlhc2htUO4

What we've done:
00:41 – JQuery updated from 1.9.1 to 3.3.1.
01:44 – information about vendors' activity on the dashboard in Multi-Vendor.
03:57 – vendor invitation functionality.
06:37 – new product variations based on features.
10:26 – online chat via Telegram.
14:00 – research: warehouse-based stock management.
17:06 – storefronts for Multi-Vendor.


What we're working on:
18:56 – one-page one-step checkout in 4.10.1.
19:55 – final adjustments to the new product variations; they will be released and out of beta in 4.10.1.
20:43 – storefronts in Multi-Vendor.
21:06 – mobile application for vendors.
21:59 – improvements to our Marketplace of third-party add-ons.

Hello,

This has definitely raised more questions than answers. I see you are preparing for a more globalized strategy when it comes to CS-Cart but how is this supposed to work when you have a stateful application? Let's imagine you really are that big that you have multiple warehouses, than for sure you need more than one server to power your application?

Multi-server environments are becoming more common by the day and it is better to head the least and have a system capable of this. Therefore I'd make the following 3 choices:

1. Move frontend from backend. The frontend and backend should not be in the same root directory. There are a number of reasons for this:

* Security: separating the frontend and backend makes sure that unauthorized persons are unable to execute functions which update sensitive data;

* Better scalability: by moving the backend to a seperate directory and making it only interact with the storefront via database, it gives customers better scalability results;

* Continuous integration: it allows developers to change things seperately in the backend and frontend, thus making certain operations way easier since they are not directly bound to the storefront;

2. Make the application stateless. Images and such are stored on in a directory, you would be better of moving these to a seperate domain to allow users to use their own domain for a CDN more easily (instead of some slow migration script for cloudfront). As far as I can see this can easily be done by modifying the abstract storage classes.

3. Add-on management should be refactored for multi-server environments. Whenever someone would like to install an add-on, it will need to reload all the instances, therefore this functionality should be removed and should be managed through a git service which will destroy the older instances and redeploy new servers with the new version of the application.

If you need any more information regarding this (we already have done all of this in our own private version), please feel free to contact us.

Kind regards,

I can’t comment on all of the points brought up (that’s for Ilya Makarov and the developers to consider), but there is something I can address.

Let’s imagine you really are that big that you have multiple warehouses, than for sure you need more than one server to power your application?


“Warehouses” don’t necessarily warrant multiple servers (although they probably do in the example provided in the video). The way I see it, “warehouses” are just a way to be more precise about shipping time and product availability. For example, you have some products in stock at your local store, but other products are available only from a supplier’s warehouse, and it would take these products a few more days to get to the store. That way you’ll be able to show customers whether or not they can pick up the item today, and when their order will be shipped. That’s one of the single-server scenarios that “warehouses” will hopefully cover.

"Warehouses" don't necessarily warrant multiple servers (although they probably do in the example provided in the video). The way I see it, "warehouses" are just a way to be more precise about shipping time and product availability. For example, you have some products in stock at your local store, but other products are available only from a supplier's warehouse, and it would take these products a few more days to get to the store. That way you'll be able to show customers whether or not they can pick up the item today, and when their order will be shipped. That's one of the single-server scenarios that "warehouses" will hopefully cover.

I think that warehouses doesn't solve above scenario in the best way possible.

If you have some kind of integration with your supplier and you know that the items that are not in your warehouse can be shipped to you in a given time (let's say 3 working days) and you repack those supplies in your warehouse then you have a cross-docking scenario.

In this case it would be best to add to Out of stock actions option show shipping time in working days with additional field working days to ship.

Why?

We have about 200 suppliers and about 40 000 sku in our store. Each supplier has a minimal shipping value to get a free shipping to our warehouse. So we define per product shipping time. E.g. The supplier has minimal fee shipping for $300. In it's offer you can buy cheap products for $30 (accessories) but you can also buy more expensive products where only 1 item meets the requirement of free shipping. So we set for accesories longer shipping time (14 days) and for items which meet the free shipping requirement only 3 working days.

In order to achieve this we've modified the cs-cart functionality by ourselves.

If we were to do this using warehouses, we would have to define 200 warehouses for each supplier with different shipping time and we would still loose the ability to define the quicker shipping time for part of it's offer.

I've asked for the product barcode (gtin, ean) multiple times in different threads. No response so far from the cs-cart architects team.

It should be moved to cscart_products table, it's the only logical place to be. It's not a feature, it's not translatable and it would highly improve datafeed generation for amazon, google, ebay etc.

Could someone finally tell us, why you don't want to do this?

Dear Jacek,

Thank you for the paying our attention to products barcode.

Can you please write a workflow you are planning to use the barcode? Something like:

- barcode number should be displayed and editable at product page in admin area

- barcode should ..

- admin shoud ..

- ..

etc.

I'm asking because each company has their own workflow to use barcode. I will appreciate you feedback on this.

Dear Jacek,

Thank you for the paying our attention to products barcode.
Can you please write a workflow you are planning to use the barcode? Something like:
- barcode number should be displayed and editable at product page in admin area
- barcode should ..
- admin shoud ..
- ..
etc.

I'm asking because each company has their own workflow to use barcode. I will appreciate you feedback on this.


Thank you imac for finally paying attention to this matter.


1. barcode number should be displayed and editable at product page in admin area

2. barcode number should be editable via API

3. barcode number should be unique within cscart_products table (one product has one barcode)

4. barcode number should be displayed within features section on product page

5. storefront user should be able to search products by barcode

6. backend user in admin panel should be able to search products by barcode

7. barcode should not be translatable to other languages (current implementation of entity - value pair in case of features creates new value for each language).

8. Products API should allow to query products by barcode (curl --user admin@example.com:APIkey -X GET 'http://example.com/api/products?barcode=3700217381721'). The response should return single product, not a product array.

9. Print packaging slip option should print the barcode below the product name.

10. It should be possible to update products via import/export addon (the new one) based on the barcode as a product identifier.

In my opinion most of the 3rd party services rely on barcode as a product identifier and are required by Google Shopping, Ebay, Amazon, price comparison engines etc. that barcode should not be treated as a standard entity - value feature.

Moving them to cs-cart products table would increase performance in datafeed generation. You can ask developers of datafeed generation tools (e.g. Alexbranding) what is their opinion.

In our case, barcode is the standard 13-digit ISBN. It is entered in a simple text field as a feature and is displayed in the corresponding tab of the product page. We are also putting it in the meta-description and the meta-keywords fields so that it can be searched for.

When searching for the ISBN, which is alias known as EAN, ASIN, etc., all products are displayed that bear the same ISBN, so this feature cannot be and shouldn't be unique. There are many vendors that may offer the same book in their stores; even the same vendor can list different copies of the same book as different products, not just as product options.

So, the big question is why have three different codes - product_id, CS-Cart CODE, and EAN/ISBN. Why not use the CODE as your barcode? Because products come from different stack DBs and go to different remarketing dbs, which will definitely become even more confusing with so many re-marketing marketplaces and social services.

We are thus creating another futile task for the developers to steal their time, instead of using it to resolve the many really fundamental issues of CS-Cart products.

I stopped long ago wondering why people are so obsessed with trifles and cannot focus on what is substantial in their work and life...

We are thus creating another futile task for the developers to steal their time, instead of using it to resolve the many really fundamental issues of CS-Cart products


Let me try to explain it to you in the easiest way possible. Let's stick with the t-shirt example which is so widely used as an example.

Each color AND each size according to GS1 should have a unique barcode(ASIN, UPC, EAN, etc).

In current implementation of option combinations it's not possible to have the barcode assigned as a feature because features are inherited from a base product.

In variations which are right now developed, it's also not possible to assign barcode as a feature because for the sizes you should use feature with purpose Group variations in one catalog item. If you choose this option, then the features are also inherited from the base product (marked with a star).

The field product_code is used to store SKU.

When searching for the ISBN, which is alias known as EAN, ASIN, etc., all products are displayed that bear the same ISBN, so this feature cannot be and shouldn't be unique. There are many vendors that may offer the same book in their stores; even the same vendor can list different copies of the same book as different products, not just as product options.


I didn't take into account the multivendor scenario with duplicate products. Good to have a second opinion.

About different covers for the same book, I'm aware that we don't live in a perfect world but ISBN standard forbids this kind of behavior. You can find more info about that on https://www.isbn.org/. Amazon in it's market place creates only one product for each ISBN.

Uniqueness of barcode is not a deal breaker for me.

I stopped long ago wondering why people are so obsessed with trifles and cannot focus on what is substantial in their work and life...


Yet, I'm still wondering why people cannot look at problems more broadly and are convinced that their input is a one-size-fits-all solution.

About different covers for the same book, I'm aware that we don't live in a perfect world but ISBN standard forbids this kind of behavior.

I am aware of this too. My publishing house has been established 28 years ago. And I hate paying thousands of dollars for a software that does not provide what has promised to provide. So my irritation is not with you...

Will be able vendors to use addon Stores and pickup points? In demo couldn't figure out.

Regards