Razor Commerce Demo
Permalink
I'm very happy to announce that Razor Commerce, a free commerce suite for C5.7 is nearly ready to demo. It's only going to be a front-end demo at this stage, and we're aiming for end of April to have it available to beta test and to submit to the marketplace. I'll post the demo links in this thread when it's setup and I'll be happy to answer any questions here about the Razor.
What have we managed to bundle into this first version of Razor Commerce? The focus has been on making a good foundation with solid order flow, cart/checkout. Here are some of the features and the design concepts in place so far.
1) The shop main page is a regular PageList block that is installed when you install the package. It has a custom template for showing price, again that template activated on install. Later we might build a custom block type like Core Commerce does, like ProductList. For now using a regular PageList works and enables developers to use familiar override techniques. It's very easy certainly to edit the custom template for the product grid. There is no sorting or filtering features currently.
2) There is a product detail page. Razor Commerce has a custom PageType named product and a custom block for product_detail. This block is installed into the PageType Default. Developers can change the display by adding block templates. We also have plans for an alternative approach which involves individual blocks for each product display area. This would be a more advanced way to organize the product detail for example there would be a price_display, product_details, product_gallery, product_add_cart_form. These blocks can then be moved around in the PageType Default enabling a very customized layout without needing to code a template.
3) The shopping cart is almost a pixel-for-pixel copy of WP WooCommerce (WOO WOO!!) we're proud to be copycatters in this case because Woo rocks. The cart features a stepper for quantity updates, removal of items, subtotals and a continue to cart button.
4) Programming additions to cart is easy. We take the approach that the cart is a wrapper for an Order object. Every visitor on the site has an order created using their session ID. You can pull the current cart object at any time, and use the Order object to add item(s) to the user cart.
5) We have taken a stance on cart merges that by default we archive rather than merge anonymous carts. This is because it is a commonly reported problem in Magento and other systems that shoppers often mistakenly duplicate orders by shopping anonymously while their logged in user already has items in the cart. With Razor commerce if a user adds items to the cart as anonymous, then logs in, their anonymous cart becomes their active cart. If they already had a cart with items when logged in, we archive that order. Orders are almost never deleted in Razor Commerce, partly because our analytics system will compile data about abandoned orders which requires the orders to be held intact. Instead we archive carts, which also means that a cart that has been "replaced" by an anonymous cart can be restored to the active cart after the user checks out their existing cart. We will probably offer a merge cart feature if it requested, or somebody can build that as an addon but in our research we found merging carts is problematic more than it is helpful.
6) Our checkout is currently single page only. We have divided the checkout form into CheckoutPanes which are registered, we plan to make it possible for developers to easily add fields or register new checkout panes. We've made each checkout pane in Razor Commerce an element. jQuery validate is used to validate the form.
7) Razor Commerce already has Stripe integration. We'll also be providing non-transaction options out of the box like "Invoice" or "COD". PayPal is not supported currently, we're not sure we'll get it integrated by version 1 launch we kind of made the decision to invest the effort into the Stripe integration instead. Our Stripe integration is deep, we utilize Stripe customer creation and setup references between the store customer and their Stripe account which means we can offer single-click checkout for returning customers.
8) 100% of the checkout fields can be loaded from a stored user account if that user has the data available. All the data is stored using User Attributes, names, phone, address(es). Our goal is to make checkout swift, we use the Core Authentication form with a redirect back to checkout to login existing customers.
9) Razor Commerce does not require or provide customer registration, instead we automatically generate user accounts from the checkout data. I'm sure some shop owners will want a different approach because of a need to collect certain registration data, so this approach might become a configuration option later. For now we set it up the way we often see WooCommerce setup, where we generate account data automatically and email the customer their account details. The user is also logged in automatically so after they complete checkout they can see a personalized message with their orders summary, and a link to their customer dashboard.
What have we managed to bundle into this first version of Razor Commerce? The focus has been on making a good foundation with solid order flow, cart/checkout. Here are some of the features and the design concepts in place so far.
1) The shop main page is a regular PageList block that is installed when you install the package. It has a custom template for showing price, again that template activated on install. Later we might build a custom block type like Core Commerce does, like ProductList. For now using a regular PageList works and enables developers to use familiar override techniques. It's very easy certainly to edit the custom template for the product grid. There is no sorting or filtering features currently.
2) There is a product detail page. Razor Commerce has a custom PageType named product and a custom block for product_detail. This block is installed into the PageType Default. Developers can change the display by adding block templates. We also have plans for an alternative approach which involves individual blocks for each product display area. This would be a more advanced way to organize the product detail for example there would be a price_display, product_details, product_gallery, product_add_cart_form. These blocks can then be moved around in the PageType Default enabling a very customized layout without needing to code a template.
3) The shopping cart is almost a pixel-for-pixel copy of WP WooCommerce (WOO WOO!!) we're proud to be copycatters in this case because Woo rocks. The cart features a stepper for quantity updates, removal of items, subtotals and a continue to cart button.
4) Programming additions to cart is easy. We take the approach that the cart is a wrapper for an Order object. Every visitor on the site has an order created using their session ID. You can pull the current cart object at any time, and use the Order object to add item(s) to the user cart.
5) We have taken a stance on cart merges that by default we archive rather than merge anonymous carts. This is because it is a commonly reported problem in Magento and other systems that shoppers often mistakenly duplicate orders by shopping anonymously while their logged in user already has items in the cart. With Razor commerce if a user adds items to the cart as anonymous, then logs in, their anonymous cart becomes their active cart. If they already had a cart with items when logged in, we archive that order. Orders are almost never deleted in Razor Commerce, partly because our analytics system will compile data about abandoned orders which requires the orders to be held intact. Instead we archive carts, which also means that a cart that has been "replaced" by an anonymous cart can be restored to the active cart after the user checks out their existing cart. We will probably offer a merge cart feature if it requested, or somebody can build that as an addon but in our research we found merging carts is problematic more than it is helpful.
6) Our checkout is currently single page only. We have divided the checkout form into CheckoutPanes which are registered, we plan to make it possible for developers to easily add fields or register new checkout panes. We've made each checkout pane in Razor Commerce an element. jQuery validate is used to validate the form.
7) Razor Commerce already has Stripe integration. We'll also be providing non-transaction options out of the box like "Invoice" or "COD". PayPal is not supported currently, we're not sure we'll get it integrated by version 1 launch we kind of made the decision to invest the effort into the Stripe integration instead. Our Stripe integration is deep, we utilize Stripe customer creation and setup references between the store customer and their Stripe account which means we can offer single-click checkout for returning customers.
8) 100% of the checkout fields can be loaded from a stored user account if that user has the data available. All the data is stored using User Attributes, names, phone, address(es). Our goal is to make checkout swift, we use the Core Authentication form with a redirect back to checkout to login existing customers.
9) Razor Commerce does not require or provide customer registration, instead we automatically generate user accounts from the checkout data. I'm sure some shop owners will want a different approach because of a need to collect certain registration data, so this approach might become a configuration option later. For now we set it up the way we often see WooCommerce setup, where we generate account data automatically and email the customer their account details. The user is also logged in automatically so after they complete checkout they can see a personalized message with their orders summary, and a link to their customer dashboard.
Screenshots from Razor Commerce, still some WIP before launching the demo site.
Products will be entered in a backend I assume? Also, can one make attribute sets like Magento, or are you making it "basic"? I see there is a lot of interest in both getting eCommerce for 5.7 but also creating it. I have quite some experience creating eCommerce modules/packages and if this looks promising, you can count me in on developing some stuff.
Yes products will be entered through the dashboard. The products are a PageType named product. Like any collection, it supports adding attributes. We haven't made any special handling of that if that's what you're asking like in terms of making it easier to add attributes. If you were manually adding them through the dashboard it would be done through the C5 attributes manager. If you were adding them programmatically in a package, I've written a Field Class which is used by Razor Commerce installer that simplifies the process of adding an attribute set, attribute, and then putting it into the set and putting it into the composer. Those 3 or 4 steps done through the C5 core classes can get really repetitive and can take 15-20 lines each because you have to load various objects and set things up in certain ways. With the Razor Commerce Field Library you can add a new field in 2-lines and have it show up on composer for product.
Example of the field class:
Looking forward to you trying out Razor Commerce and coming with ideas on extensions.
Example of the field class:
// add field set $field->addSet( 'customer_address', 'Customer Address' ); // add field $field->add( 'billing_address', 'Billing Address', 'address' ); // add field to set $field->set( 'customer_address' );
Looking forward to you trying out Razor Commerce and coming with ideas on extensions.
OK, an eCommerce without attributes and attributes is not an eCommerce in my eyes. So very good that you've taken care of this. You will do categories the same way too with attributes? And products can be assigned to multiple categories? If you need a beta tester or need some info/input, do let us know. The core team will be working on an eCommerce too, but it wouldn't harm anyone to have 2 big players.
Keep up the good work.
Keep up the good work.
Sure I'll let you know when it's ready for beta testing.
Seems we have a few eCommerce packages on the way now. Which leads me to think that some users will be swapping back and forth between them to see which best fits their requirements.
To facilitate that, please, all eCommerce developers, include an xls or csv import/export for products.
To facilitate that, please, all eCommerce developers, include an xls or csv import/export for products.
Good point John. I've been reading through the ContentImporter and ContentExporter classes and they seem to be same/similar as in 5.6. Which means probably some of the same issues with CIF importing we run into developer PageImporter. No validation checks, so areas end up duplicated, fatal errors when block types are not available etc.
My game plan for getting around those issues is first off don't use ContentImporter, instead use the import($x) methods in Page, Area, Block directly. That way we can do some tests on the data first like checking if required objects exist, checking if the import is an add/update. Skipping areas with blocks that don't exist.
Currently the plan for Razor Commerce product importing specifically is that we'll offer 2 types of export/import - "ProductPage" and "ProductObject". ProductPage migration means the entire C5 page including attributes, areas and blocks. Now because we can't possibly deal with every block, and some blocks added to pages don't export or don't import, ProductPage migration will always be kind of a hit/miss affair where developers might have to edit the XML input to avoid errors, or use only in situations where they have some pretty good control over both the exporting and importing sites.
ProductObject importing will be the much more clean/reliable approach. We'll only export the Product attributes and it will be in a more human-friendly structure instead of the large trees from the ProductPages. The idea there is also that when you make a new site, you could build the product catalog by making XML product pages rather than using the interface. The downside to this approach however is the product pages would probably have a default pagetype, no blocks in areas, anything "extra" that was in pages would be lost if migrating from an existing site. Between the 2 options though developers will be able to choose what suits their product migrate best.
For our other objects, currently just Orders, Payments these are custom objects and I haven't given much though yet to how we'll handle them. It will be XML though, not CSV... I think we'll only offer XML from Razor Commerce Core, and if developers want CSV imports they can build packages that convert CSV imports to XML and then use the core migration package.
We also want to have migration from other systems, WooCommerce, Magento, Core Commerce. Again these would be extensions, so our focus is making Razor Commerce migration library easy to work with so whatever the incoming data is developers can convert it and then use a standard migrate interface.
My game plan for getting around those issues is first off don't use ContentImporter, instead use the import($x) methods in Page, Area, Block directly. That way we can do some tests on the data first like checking if required objects exist, checking if the import is an add/update. Skipping areas with blocks that don't exist.
Currently the plan for Razor Commerce product importing specifically is that we'll offer 2 types of export/import - "ProductPage" and "ProductObject". ProductPage migration means the entire C5 page including attributes, areas and blocks. Now because we can't possibly deal with every block, and some blocks added to pages don't export or don't import, ProductPage migration will always be kind of a hit/miss affair where developers might have to edit the XML input to avoid errors, or use only in situations where they have some pretty good control over both the exporting and importing sites.
ProductObject importing will be the much more clean/reliable approach. We'll only export the Product attributes and it will be in a more human-friendly structure instead of the large trees from the ProductPages. The idea there is also that when you make a new site, you could build the product catalog by making XML product pages rather than using the interface. The downside to this approach however is the product pages would probably have a default pagetype, no blocks in areas, anything "extra" that was in pages would be lost if migrating from an existing site. Between the 2 options though developers will be able to choose what suits their product migrate best.
For our other objects, currently just Orders, Payments these are custom objects and I haven't given much though yet to how we'll handle them. It will be XML though, not CSV... I think we'll only offer XML from Razor Commerce Core, and if developers want CSV imports they can build packages that convert CSV imports to XML and then use the core migration package.
We also want to have migration from other systems, WooCommerce, Magento, Core Commerce. Again these would be extensions, so our focus is making Razor Commerce migration library easy to work with so whatever the incoming data is developers can convert it and then use a standard migrate interface.
Razor Commerce demo link. Note, this is alpha version the dashboard is under development so this is front-end only demo to showcase how the user experience, cart/checkout looks. Goal is to have a working version in the marketplace for download, and on GitHub for development contributions before end of April.
http://demo.goldhat.ca/razor/1/index.php/shop...
http://demo.goldhat.ca/razor/1/index.php/shop...
Will there be categories too? So you can create categories pages and have products appear on the specific categories pages? Or will it be a "simple" product overview page and its detail page?
There will be some form of categorization but we haven't figured out what the best route is. Unlike WP/Drupal which has taxonomy API's, C5 does not have a significant categorization API. It does however have the page tree, and in a sense that is what taxonomy is a tree of objects. So one possibility we've explored that *might* work nicely in C5 is to create a pagetype "Catalog", which lists all the products and/or catalogs under it in the page tree. You would then be able to create as many catalog pages as you want, put them anywhere you want. And these catalog pages then have various display options to fit different styles of display such as "show child categories", "show direct child products", "show all child products".
The question mark on "catalog pages" as categories is whether this is too cumbersome for larger stores where you need to make 100+ categories. But then if you need 100+ categories you must have 500+ products. The other consideration is how would products go into multiple categories, aliasing?
The question mark on "catalog pages" as categories is whether this is too cumbersome for larger stores where you need to make 100+ categories. But then if you need 100+ categories you must have 500+ products. The other consideration is how would products go into multiple categories, aliasing?
What was the main reason to go for a page type for a product page then? Only because of the Concrete5 page attributes? Because, if you make it all backend (categories and products), you could do the same as with Woocommerce/Magento/OpenCart/Whatever other eCommerce product. Live editing is cool for sure, but not sure if that will work for products though... Then again, you will lose some capabilities if it's all backend and don't make it a page type. Me myself am more used to being such things in a backend, rather than go and live edit such things.
We have set the products pagetype to use composer for product editing. I feel there are many benefits to using collection objects instead of custom objects. Yes the attributes support is part of it, and then composer, page tree. It's also about having a familiar object (collection) that is at the base of the product object, even though certainly we'll add some convenience by having a product object that extends collection.
A big issue in using a completely custom object is okay maybe it gives more control over the editing interface, but then how the products get displayed? We want to avoid the scenario where you make products, but then have to go somewhere else to make pages to display each product. Is it limiting to have each product be a page, well maybe but I think there are ways to work around that. For example if you wanted to have a page that displays 3 products like in a comparison table layout, could you do that with products as a collection? Sure, even though they are pages they can be loaded and displayed as data, we just maybe need a way to hide those products from catalog/tree if they are not meant to shown individually.
A big issue in using a completely custom object is okay maybe it gives more control over the editing interface, but then how the products get displayed? We want to avoid the scenario where you make products, but then have to go somewhere else to make pages to display each product. Is it limiting to have each product be a page, well maybe but I think there are ways to work around that. For example if you wanted to have a page that displays 3 products like in a comparison table layout, could you do that with products as a collection? Sure, even though they are pages they can be loaded and displayed as data, we just maybe need a way to hide those products from catalog/tree if they are not meant to shown individually.
Here is a glimpse of the product composer with the tabbed menu so you can get a feel for how that part looks.https://www.youtube.com/watch?v=-7yY3hOmjcc...
Hi!
The project looks very nice!
As for the categories, have you checked the new "Topic List" feature in concrete 5.7?
http://www.concrete5.org/documentation/using-concrete5-7/in-page-ed...
Jordi
The project looks very nice!
As for the categories, have you checked the new "Topic List" feature in concrete 5.7?
http://www.concrete5.org/documentation/using-concrete5-7/in-page-ed...
Jordi
Thanks Jordi, I'll check it out from the description sounds like Topics are a solution to taxonomy. We'll need the api though not the block, but presumably the block is powered by an API we can tap into in packages? If so, I wonder if it can have attributes?
