Future of Padloper - New Project Lead Announcement

[kongondo]

13 minutes ago, szabesz said:

Please find them in your inbox. Thanks!

Received, thanks.

[bernhard]

27 minutes ago, szabesz said:

Please find them in your inbox. Thanks!

17 hours ago, bernhard said:

Also interested, please share it in public

I wrote that on mobile, maybe you missed it? It was related to your post.

[szabesz]

2 hours ago, bernhard said:

It was related to your post.

I'm sorry, I did not get it. Here it comes:

Spoiler

WooCommerce coupon code settings extended by some plugins being used:

Note that tooltips of the options are usually informative and helpful.

 

[apeisa]

So happy to follow this reborn of Padloper! 

[Mikie]

Excited about this.

One feature request that I am not sure is covered above (apologies if I missed it and am doubling up) is a front-end customer account area. Again, woocommerce is a good reference point for the basics involved. A separate optional module would make sense, and ability to style / customise as needed would be important. Maybe it could be less of a predefined account area and more of a module to manage users, authentication and customer endpoints on the frontend.

 

[kongondo]

9 hours ago, mke said:

One feature request that I am not sure is covered above (apologies if I missed it and am doubling up) is a front-end customer account area. Again, woocommerce is a good reference point for the basics involved. 

I'm just finishing up on a module to manage customers information/data. I'll consider the frontend customer account area. Do you have a direct link I could look at? Thanks.

9 hours ago, mke said:

Maybe it could be less of a predefined account area and more of a module to manage users, authentication and customer endpoints on the frontend.

The account area and managing users (customers) are two separate things. Regarding the latter, shop admins will be managing users in the backend, in a dedicated area. There will be both bulk/batch actions (edit) and single customer edit. They'll be able to tag customers (e.g. as wholesale buyers, etc), create customer notes, groups, etc. 

The account area, from what I understand, is like a frontend login but the customers stay in the 'frontend' :-). ProcessWire will handle authentication.

10 hours ago, mke said:

customer endpoints

Please clarify this, thanks.

[Mikie]

Hi @kongondo, sorry for any confusion. I am purely talking about a frontend account area for customers where they can review orders, manage account info etc whilst staying on brand to the look and feel of the shop. When I mention authentication I meant incorporating a login / registration flow similar to Ryan's Login/Register module.

See some screenshots from WooCommerce Storefront theme below. The code for this is here, but I can spin up a demo for you if you want.

[kongondo]

Hi @mke

Thanks for the clarification and example. That fits into the planned separate pro frontend module.

On 9/3/2018 at 4:35 PM, kongondo said:

Frontend

Past requests have included the development of a full featured frontend shop. This is planned for Padloper 2. However, this will be an optional pro module priced separately from Padloper itself. The ability to build own frontend shops using Padloper API will still continue. For those who want a plug-n-play solution, this frontend shop will come in handy.

 

As stated, those who want to build custom frontend will have the full API at their disposal. Something like this (pseudo code, although some API is ready)

 

// assuming user is logged in, they are redirected to My Account area
$out = "<span>$user->name</span>";

// your Orders Table [orders API in the works]
$orders = $pages->find("template=orders,order.customer_id=$user->id,limit=10");
foreach($orders as $o) {
	$order = $o->order;
	/* 
		Date: $order->date;
		Status: $order->status;
		etc...

	*/
}

// Addresses [customer API 95% done]
$customer = $user->customer;
/*
	First Name: $customer->firstName;
	Last Name: $customer->lastName;
	Email: $user->email;
	Address: $customer->address;
	City: $customer->city;
	Postal/Zip Code: $customer->code;
	Region: $customer->region;
	Country: $customer->country;
	Phone: $customer->phone;

	// etc...including if customer is tax exemp and whethey they accept marketing. 
	// Any custom properties added are also available, e.g. $customer->company, etc.
	
*/

 

[kongondo]

On ‎10‎/‎10‎/‎2018 at 4:25 PM, Basil said:

great news! may i ask if we can download/buy?

i have bought padloper before 1year just to support it never used in real project yet.

Hi @Basil. Sorry I missed your post. Just seen it now. Please see the first post In this thread for details. Existing users will be able to buy the new padloper at a discounted price. The discount % hasn't been decided yet :-).

[Mikie]

On 10/13/2018 at 9:55 PM, kongondo said:

That fits into the planned separate pro frontend module.

Thanks for the update. Makes sense you want to keep this functionality in that separate.

[Marco Ro]

Hi @kongondo First thank you for your work!

In this moment we are using the unpublished order section, that is generated in the confirmation page, as if they were abandoned carts. Which is correct, but it would be useful for marketing to have all abandoned carts of the users. 

Would it be possible create the order page as soon as they insert a product into the cart? and insert them a specific page such as Unpublished Orders. In this way we can have track about what people add to the cart and if that useres are login we can also know who is. 

 

[kongondo]

Hi @MarcoPLY,

First, apologies I have not had the time to resolve your other issue.

On 10/29/2018 at 11:04 AM, MarcoPLY said:

but it would be useful for marketing to have all abandoned carts of the users. 

I agree.

On 10/29/2018 at 11:04 AM, MarcoPLY said:

Would it be possible create the order page as soon as they insert a product into the cart? and insert them a specific page such as Unpublished Orders. In this way we can have track about what people add to the cart and if that useres are login we can also know who is. 

Yes it is possible and that is the approach I have taken and currently working on. All orders have 'payment status' and 'fulfilment status'.  Padloper will ship with some common status and shop admins will be able to create custom ones. Examples include:

Payment Status: abandoned, paid, pending, refunded, etc

Fulfilment Status: pending, cancelled, shipped, delayed, invoiced, exchanged, etc.

Some will be set automatically, e.g. order paid will set 'paid' status.

I'll write more about this later but it is possible to filter abandoned carts like this:

// all abandoned carts
$abandonded = $pages->find("template=order,payment_status=$abandonedStatus");
// by specific user
$abandonded = $pages->find("template=order,order.payment_status=$abandonedStatus,order.customer_id=1100");
// by cart amount
$abandonded = $pages->find("template=order,order.payment_status=$abandonedStatus,order.total_price>100");
// by cart quantity
$abandonded = $pages->find("template=order,order.payment_status=$abandonedStatus,order.total_quantity>5");

 

Remember we will have a possibility to create discounts for customers who abandoned their carts. This is how we'll be able to identify them (depending on the point at which they abandoned their carts).

Customers/Users

Regarding users, I'll be seeking feedback from your guys. My current thinking is that all customers are users. There will be an option to require login for all purchases, or both login (registered users) and guest checkouts allowed.  For registered users will be able to login and manage their account, track past orders, etc. As mentioned in the previous posts, they will stay in the frontend all the time. For guest checkouts, we still need to store at the very least their names and email addresses as well as postal addresses if shipping a physical item to them. In both cases, we do not store credit card details. I don't want to go there, at least now. This is where I need the input of devs.  How would you like customers to be handled? I thought about creating a separate customers 'system' but the idea seemed a bit silly since ProcessWire can already handle users. Registered users will have a role, e.g. customer or registered-customer whereas guest customers will have role 'guest-customer'. Guest customers will not be able to login since they will not know their login name. I'm not sure whether the system should auto-generate a cryptic name or base it on their first and last names. We'll also generate a secure password for them. They just won't get sent this information. For registered customers, they'll be able to change their passwords (we'll use the Login/Register module).

Any thoughts? Data protection issues? Security? 

[szabesz]

5 hours ago, kongondo said:

Registered users will have a role, e.g. customer or registered-customer

Currently I use customer for registered customers, so I prefer that one. Will these names be configurable?

5 hours ago, kongondo said:

the system should auto-generate a cryptic name or base it on their first and last names.

How about usernames based on email address? WP/Woo does that too.

5 hours ago, kongondo said:

Any thoughts? Data protection issues? Security? 

I'm very busy this week but I will be happy to get back to these around the weekend.

 

[kongondo]

13 minutes ago, szabesz said:

Will these names be configurable?

Not sure yet. I want to balance ease-of-use/user-friendliness and flexibility. I wouldn't want shop admins bothering about roles/permissions, at least not directly. We could maybe prefix our roles and permissions with pad-.

16 minutes ago, szabesz said:

How about usernames based on email address?

If ProcessWire allows it, then OK. I seem to recall such a discussion but I don't know what became of it.

17 minutes ago, szabesz said:

I'm very busy this week but I will be happy to get back to these around the weekend.

Thanks. We still have some time ?

[szabesz]

1 minute ago, kongondo said:

18 minutes ago, szabesz said:

How about usernames based on email address?

If ProcessWire allows it, then OK. I seem to recall such a discussion but I don't know what became of it.

Maybe @ and . could be replaced with something else, eg: john_example_at_xyzmail_com

This way we  get a unique name while using first and last names do not guarantee it.

[kongondo]

7 minutes ago, szabesz said:

Maybe @ and . could be replaced with something else, eg: john_example_at_xyzmail_com

This way we  get a unique name while using first and last names do not guarantee it.

OK, let's have a think.

[arjen]

As a customer I wouldn't be too happy when I chose to order as a guest and there is an account created in the back-end kinda secretly. Lets say the customer after a guest order wants to create an account and the system errors with a message: you already have an account. Imho the only customer data as a guest should be on the invoice/order.

Registered users I would prefer as regular PW users with a role indeed.

[kongondo]

@arjen,

Thanks for your input. 

1 hour ago, arjen said:

Imho the only customer data as a guest should be on the invoice/order

So, for digital products, an email and names (first + last?) would suffice? For physical products, the least required should be a full address + full names and I think an email for order status updates, no? In both cases, this data has to be stored somewhere though. Only difference is an account is not created.

Thanks.

[szabesz]

Regarding customer's private data: any data which is directly related to (i.e. "required by") the order should be considered as "must have" because legally speaking there is a contract between the seller and the buyer, and the customer cannot ask the shop-owner to delete such data from the system. However, "ordinary user" data – which is not related to a particular order – should only be stored if the customer explicitly agrees to it, and such data should be deletable without breaking the integrity of any order's data.

[kongondo]

Thanks for the insight. I think I'll let Padloper take a passive role on this. Shop admins will decide what data they deem 'required' and what data is optional. Padloper will store what they want to be stored.

[Jozsef]

Hi @kongondo, I've just seen this thread and couldn't be happier.
I used Padloper in the past as an early adopter but I always felt it wasn't for the faint hearted. It's great to know that it has a future and I hope v2 will be possible to use without PHP guru skills. I build almost all my sites on ProcessWire and it'd be nice to have the basic features covered by the module itself (promotion, tax, shipping, user accounts, order management etc…). Many of these were up to us to implement and it was prohibiting for front-end people.
Best of luck with the project and thank you for your commitment!

[kongondo]

55 minutes ago, Jozsef said:

I hope v2 will be possible to use without PHP guru skills

Definitely. The plan is to build on and extend the powerful PW/Padloper API but also providing an easy to use and friendly interface with most useful functionalities for a shop within easy reach. 

58 minutes ago, Jozsef said:

the basic features covered by the module itself (promotion, tax, shipping, user accounts, order management etc…)

Apart from promotion (we can think about that in the future), the rest of your list is tick, tick, tick, tick + more...

1 hour ago, Jozsef said:

Best of luck with the project and thank you for your commitment!

It's a great project to work on, thanks! ?

[Marco Ro]

Thank you @kongondo all this is perfect! No worry for the padloper post, sure the new one will be great also for the other question! 

Compared to what others have said, I can only add that it might be useful have the e-commerce users in a separate page like a Padloper Customers, also for the abandoned carts, maybe with tag for better filter the useres beetween purchased, not purchased, registered and unregistered. 

About the problem for the anonymus customer, those who aren't registered but have made a abandoned cart without arrive to the confirmation of the data, I think we can use the data only for statistical purposes to know what was in the cart. So, maybe they can only register as IP addresses in this way we can know also where come from. 

I swear they are the last requests ? 

Will be good if the user isn't registered add a checkbox at the end of the checkout form to ask if he wants to register. Cloude be a backend question.
For the Shipping Price coulde be useful if we can also trigger for the total cost of all items.
Always for Shipping Price, could be an option, in the category shipping backend, calcolate the costo adding the singular shipping prices or only take the highest, as it is now.

 

[Jozsef]

14 minutes ago, kongondo said:

Apart from promotion (we can think about that in the future), the rest of your list is tick, tick, tick, tick + more...

Sorry, when I said promotion, I meant discount codes or discount rules including option for free shipping.

[kongondo]

1 hour ago, Jozsef said:

Sorry, when I said promotion, I meant discount codes or discount rules including option for free shipping.

That's a tick then ?. It's already implemented ?!