[feature request] Use profiles module

[jessedobbelaere]

Have you thought about using the existing Fork CMS profiles module to let customers register/login on the website? Only thing to do is add additional fields in the php code for the address details, VAT number, telephone, ...

The profiles module already has login & register functionality as well as "forgot password" email functionality and a basic user page where the user can change his password (add some edit functionality for the address, VAT number, telephone here maybe?).

By using the (custom) profiles module, the shopping cart checkout could then show:

• "Existing customer" --> login form
• "New customer?" --> show a form to fill.

This 'custom' profiles module can also be pushed to this repository and be some sort of bundle together with this catalog module.

Oh and I would be happy to collaborate and make some pull requests as soon as I have some spare time this summer!

[wolfie90]

Yeah this has been on my mind since I created the module. The reason it has not been implemented yet is that I wanted a very easy & simple first version of the catalog.This feature will definitely come in the future.

Feel free to make pull requests any time!

[jessedobbelaere]

I am experimenting with the Profiles module in combination with the Catalog module. I could use some feedback however.

Here's screenshot of the checkout process of the shopping cart. I need to add some functionality to this. It's the login widget you see at the right, inside the catalog template.

And I added extra fields to the profiles module & database. Register now looks like this.

If you press "I have a VAT number" you get to see two additional fields: company name and VAT number.

I added an Ajax call when you select a country, it fetches the country zones like this:

I also modified the LoginLink widget of the profiles module. If you add the widget to your header, you get a 'login | register' menu. If you are logged in, you get:

Up next: modifying the profiles page and adding the fields so you can edit your address, name, telephone, ... And adding a menu item to the profile page where you can check your previous orders maybe. And finally, integrate the profiles module into the checkout process. Once that's finished, I'll push it to my github branch....

[wolfie90]

The functionalities mentioned above are a great way to improve the Catalog module, good job! I have a couple of questions/improvements based on what I see:

• What does the zone dropdown box do when you select f.e. Belgium? Do we have different zones for each country?
• We have to build some extra information within a account (purchase history as you mentioned, billing information). This might be useful when we add paying methods in the future.
• I think we should also add an option to easily disable/hide the profiles functionality as some clients prefer not to have profiles integrated in their Catalog/Webshop. The way to add this is by creating a extra setting for the module (profiles yes or no)?

[jessedobbelaere]

• If you select a country, the ajax call fetches the country zones from a table profiles_zones. This table includes all the existing zones (I actually got the data from the open source Opencart database and I added a column with the country iso code). Opencart uses another table with countries to fill the country dropdown, but I use \SpoonLocale::getCountries(FRONTEND_LANGUAGE) because then you can have country names in your own language and not just in English. If Spoon gets removed from Fork, you can probably use Symfony's locale component (Locale::getDisplayCountries('en')). But I don't think that component is already included in Fork CMS.
• The catalog_orders table should probably have a profile_id field to get the recent orders from a specific customer. And then add a section on the customers' profile page where he can view his recent orders.
• Good point. So I should add a checkbox on the catalog module settings page in the backend where you can choose to use the profiles module? You'll probably need to check in almost every action whether or not to use the Profiles module... I also thought about letting the customer choose @ checkout if he wants to register for an account or continue the checkout as a guest.

[wolfie90]

• Cool, I think that should work :+1: .
• Yes, this profile_id should only be filled when the profiles module is activated or a user is logged in/registered.
• A checkbox would work, we only need to check the value when a user proceeds to the checkout process because f.e. filling the shopping cart will still use the current cookies method. Or am I missing something?

Besides checking the setting for the profiles module we also have to check if it is installed..

[jessedobbelaere]

Ok, I added a setting to the Catalog module to enable profiles. And I checked in the checkout process if the profiles module is enabled and if it's installed. I also checked this in the backend when you fetch data for the orders datagrid. If the profiles module is enabled&installed, it should get his customer data from the profiles tables.

A customer can now edit his data in the profile settings page. I'm still gonna add a "my orders" page to the profiles page to see previous orders. And I'm working on the backend of the profiles module so the admin can edit customer data (is already built-in the profiles module, but I should add fields for country & zone & address).

I was wondering, what would be a good flow for the checkout process of the catalog module? Can you think of good examples? I posted a screenshot (in the post above) where the user could choose to checkout as guest or register an account. But I'm a bit stuck on the flow. Should we work in multiple steps like Opencart does, or maybe use one page for the registration&info like Shopify does? Or any other ideas?

Shopify example:

• Step 1 --> fill in information and choose if you want account (register) or not.
• Step 1b --> If you click 'already have account' you can login and redirect to checkout
• Step 2 --> payment & shipping info

[wolfie90]

Good to hear you are making progress with integrating the profiles module. About the checkout process, I think we have to keep two important elements in mind; SEO & User (Friendly) Experience. A lot of examples can be found on the internet (f.e. bol.com, coolblue.be and amazon.com), all work with different but obvious steps. Based on the examples several websites have given I would suggest to use the following steps (as individual frontend actions):

1. Login using existing account, create a new account or proceed as guest (no account will be created) (action: Account.php)
2. Account & Billing details (action: AccountDetails.php)
3. Shopping cart overview (action: ShoppingCartOverview.php)
4. Payment (action: Payment.php)
5. Thank you (action: ThankYou.php)

Regarding the two elements:

• SEO; Marketing specialists can track the (step-out) actions because of the different urls.
• User Experience; We should show the user where he is (which step) and what he has to do to complete the order (upcoming steps), like this. Important is that the user should always have the option to go back to a previous step by clicking on it. So we should save the details of each step in the database. We could attach all details to the user profile account or when he is a guest to a temporary account, we could also attach the tracking_id (cookie) in the database for knowing the user when he re-enters the website.

For now, these are several things I could think of. There are more things to consider which we will discover along the way. Let me know if you have any questions or you get stuck with something.

[jessedobbelaere]

I saw that during the checkout (Account.php) the form data is stored in Cookies. However, the shopping cart saves a catalog_order record with status "pending". During checkout, I update that record with a session_id and a profile_id (if user is logged in). If the user is a guest, the data is also saved to the db. Should we keep the cookie code and store form data fields inside those cookies or can I remove them?I think we only need to have the order_id inside a cookie like it already does thanks to the ajax shopping cart code.

If you return to previous step during checkout it can fill the form fields from the order table and the profile module data or from a guest customer table.

[wolfie90]

Yeah, removing the cookies sounds good to me :+1:

[jessedobbelaere]

So I made a basic multi-step checkout and also integrated the profiles module (as optional module, so you don't have to use it). Here's a short video of the Catalog & profiles module (with profiles enabled). I modified the Triton theme a bit.

Features:

• [x] Extended profiles with additional fields needed to register a customer
• [x] Profiles integration into the catalog module
• [x] Multi-step checkout with possibility to return to previous step
• [x] Merged the latest code with my version of the module (a pain in the ass)

Testing

If you want to test this, you can find it in my branch here: https://github.com/jessedobbelaere/catalog/tree/feature-profiles%26checkout-integration The code often needs to check if the profiles module is enabled and/or the user is logged in. Beside that, If you can optimize or cleanup the code, feel free!

If you create a new branch, I can probably add a pull request to that specific branch instead of the master, so people can test and fix that "new" version of the catalog module and hopefully after lots of testing, this can get merged into the master repo

You can copy both the Catalog and profiles module to the backend and frontend modules folders. Install only the catalog module and try checking out (you're a guest, no account is created). Then, install the profiles module. By default, the profiles module is disabled in the Catalog module settings in the backend.

While the profiles module is still disabled, you can't checkout with your account. It will handle your order as a guest like it did when the profiles module wasn't installed.

When you enable the profiles module in the catalog module settings and you make an order, you'll get to see a view where the system asks to login with your account or continue as guest. If we login, our information is prefilled. If we continue as guests, we can fill in our information and are given the option to register and enter a password, or keep checking out as guest.

I kept the payments checkout step empty

Triton theme modifications

If you want the shopping cart and profiles tpl in the header of Triton theme like I did in my video, here are my changes. But first you'll need to execute the two steps from the Readme.md that you can find inside the Profiles module 'Installer' folder.

(General) Feature requests

Offtopic: I would love a fully functional Fork CMS shop module. Here are some feature's I could think of to extend the catalog module. Should I add them to the issues/feature requests? I can also think of some bugs. I'll do my best to create some features in my spare time, or solve bugs.

• [ ] Make it possible to add a second address (shipping address). This is now greyed out in the template.
• [ ] Add Google Analytics
• [ ] Create tiny shopping cart widget to use inside header. It displays how many items are in the basket. You can probably just parse the widget inside the template like this for example: {$var|parsewidget:'Search':'Form'}.
• [ ] Send confirmation emails after order is received
• [ ] Choose the countries you will serve in settings (e.g. only belgium and netherlands).
• [ ] Generate unique order number to display in invoices
• [ ] Invoice pdf generation
• [ ] VAT calculation inside shopping cart
• [ ] Setup different VAT percentages for each country. Or different VAT percentages per product (dropdown)?
• [ ] Add variations of a product (colour, sizes).
• [ ] Inside product edit: add new specification button that is product-specific. So it won't appear in the general specifications, but it's a specification for this product only.
• [ ] Specification groups, or add specifications to a certain product category (batteries category all has "voltage", "dimensions", ...).
• [ ] Configure address output settings (an address is written differently in each country)
• [ ] Implement profiles module into the comments section of a product. So registered users can enter comments for your product.
• [ ] Coupon code & giftcard : possibility to enter a coupon code in the shopping basket. Let the admin create coupon codes in the backend. Extra: make it possible to use the coupon code for only certain product(s) or categories.
• [ ] Add more statuses to the order: approved, shipping, payed, delivered, ...
• [ ] Setup payment provider(s) and methods that don't require a payment provider (pay in store, bank transfer) in the settings. Also useful to implement 1 or two well-known payment providers. In Belgium this is Ogone/Ingenico. Paypal is also a good option.

Issues/Bugs

• [ ] If you register a new account, you can choose a region/zone in your country. This is fetched from the profiles_zones table. But because the catalog module (without profiles module) also has to register guests, it also needs access to this table. So I suggest renaming the profiles_zones table to catalog_country_zones or something like that.
• [ ] When you register an account, you have to activate it with a confirmation mail. But when you checkout, you are logged in automatically after you choose to register an account with your info and password. How should we handle that?
• [ ] After I finished the order, my shopping cart isn't emptied. It seems like the cookie isn't deleted and I cant figure out why.
• [ ] If you do multiple checkouts as a guest, you keep overwriting the same order.
• [ ] There is no category image preview when you already uploaded a category image
• [ ] While you add a new product, the fields are "required" but aren't validated.
• [ ] live' event handler deprecated in Catalog.js

[wolfie90]

Great job Jesse, me and my colleagues will test this in the upcoming weeks! :+1: Regarding to your ambition to create a fully functional webshop module:

I think we should create a different module for this and let the catalog module to be for what it is (very basic and simple). Because some clients/people just want to use a easy module to show some products and don't want to use a full webshop module for this. We could use the catalog module as a starting point when functionalities mentioned above are implemented?

[jessedobbelaere]

You're right, it's best to keep it simple. Ok, I'll think about a shopmodule for Fork CMS that consist of the (extended version) of the catalog module, the profiles module and a new shopmodule that handles orders and payments and general settings.

[wolfie90]

Hi Jesse, we did not viewed the features you have built yet. We are extremely busy with creating things for our clients, we still want to implement the features though. I will let you know as soon as we looked into it :)!

[jessedobbelaere]

Or maybe it's best that — like you suggested —it all should be modular. The catalog module is great for products. So maybe move the whole 'order' part to a new add-on "orders module" that adds extra functionality to the catalog module. It contains the shopping cart, the order process, some well-known payment provider(s), backend functionality to handle/approve/delete orders, backend dashboard widgets, ...

If you would combine the catalog, (extended) profiles and add-on orders module, then you can make a small webshop on your website (which is what I'm hoping to be able to do in the future). Or someone can just install the catalog module like it is today and have a page where someone can discover the products with some information, find similar products, etc (like the catalog module does today).

Also, merging this pull request would be quite hard I think...

[wolfie90]

That would be not a bad idea at all. Although I think we also have to keep a little order system in the current catalog module (e.g. shopping cart and ordering without payment => send e-mail with order). Some clients want to show their products and also be able to let customers order without payment service. Maybe you could create something like a "use payment service" button in the backend settings from the "orders module" to decide which method to use.

Regarding the name of the module, is orders module telling enough? Or should we combine/relate it to the catalog, for example "catalog order extension module"? I'm asking this because the module would be an extension specially made for the catalog module. I'm Not really sure what is the smartest way, what do you think?

[jessedobbelaere]

Hmm but maybe use the catalog module just for keeping an index/overview/detail of products like it is today, maybe add filters and such to it.

If someone wants to have a basic order functionality and shopping cart, they can add a new extension module "catalog-orders" (not sure about the name) and that module comes by default with shopping cart and basic checkout without payments service. If you go into settings, you can setup the module (add a payment provider like paypal, or a simple payment option like "pick-up & pay at store" or "bank transfer"). In the settings you should also be able to choose if you want guest checkout or people should register an account (or combine the two: guest/profiles checkout).

The orders module could be used for a quick-and-easy simple shopping cart without payment service. And people can add a payment provider or delivery option later if their business is going well.