Padloper 2: Ready to Test!

[kongondo]

Hello Padloper Alpha/Early Beta Testers.

Shortly after this post, you will receive an email inviting you to access and test Padloper 2. Thanks! If you don’t receive an email within 2 hours, please let me know.

 A few things to note before you dive in.

What to Expect

• Padloper 2 is a native ProcessWire module. It is not an SPA. A previous iteration powered by VueJS was discontinued. Instead, there is some sprinkling of htmx, alpine.js and Tailwind CSS here and there.
• Bugs: how many? We’ll find out soon. There are a lot of bd(), even db() calls left, deliberately, in the code. Most (all?) have been commented out. They have been left in the code for a reason; to help debug the product.
• A shop app that you can use incrementally. Many of the features are optional and can be left out (or added later) at install.
• Inbuilt invoice and PayPal payment gateways/systems. The latter uses V2, the latest PayPal SDK.

What not to Expect

• Although it boasts a rich set of features in its current state, a number of features have not yet been implemented. Some have been implemented but not fully, so may not work as expected. In the expression of interest form I listed the features I’d want to implement next. I asked you to express your preference for these. I’ll be guided by your choices when prioritising the next set of features.

Implemented but Incomplete

Orders (backend)

• Manual order creation (creating orders via GUI) is incomplete.
• Actions including print invoice, mark order as complete, etc are incomplete.

Products (backend)

• Product variants should lazy-load when the product is being edited. Currently, they are all loaded and can slow down the page if they are many.

Checkout Settings (backend)

• Some of the settings including abandoned orders follow-up are not yet functional.

General Settings (backend)

• The settings to limit allowed image and file extensions is not yet synced with the respective image and file fields.

Shipping Zones (backend)

• It is not possible to prevent countries from being added to more than one shipping zone.

Shipping Rates (frontend)

• If more than one shipping rate is matched for a customer for a given shipping zone, it is not yet possible to let the customer select their preferred shipping before finishing their checkout. A side note: matched multiple rates can be desirable in cases you want to offer more than one delivery method to your customers, e.g. a free but slower shipping and a faster but paid-for delivery.

Downloads (frontend)

• Delivery of digital products is incomplete.

Not Yet Implemented

Access (backend)

• Access control via permissions and/or roles not yet ready.

Other Desirables

Not in any particular order and planned for future release(s).

• Bulk product images management
• Customer management
• Discounts
• Staff management
• Shipping classes
• Notifications management
• Detailed Analytics
• Additional in-built Payment Gateways (Stripe, etc.).
• Better management of abandoned baskets
• Invoice generation and management

Known Issues

• PayPal showing lots of JavaScript console errors. These are all related to CORS as far as I can tell.
• PayPal struggling with some floats (prices). It will crash and payment will fail. Maybe this could be solved by charging in cents (in PayPal) but I haven’t yet found a way to do this in V2.

If you have any questions please ask here. I will contact you later for where and how to report bugs. Please don’t use this thread for that. For generic issues, such as not being able to install, etc., please let me know in this thread.

Thanks and happy testing!

[Jozsef]

Thanks, Francis. Quick question: Is it an introductory price? Will it increase when you release it to the public?

[szabesz]

14 minutes ago, Jozsef said:

Is it an introductory price? Will it increase when you release it to the public?

Also, what kind of upgrade/support policy and price can we expect?

Also, as I stated in the other post, in order to use Padloper 2 at all, I will surely need: Discounts + Stripe + Invoice generation (but not management). For all of this, a developers "API" is enough at the beginning, adding admin management can come later, as that is not a dealbreaker for me.

Generally, I think you can make better progress, if you do not spend too much time on admin features but instead on the docs and features that we developers can use to roll out our "custom" solutions, so that we can fill in the gap for ourselves until you get there with your own implementation...

[Jozsef]

11 minutes ago, szabesz said:

in order to use Padloper 2 at all, I will surely need: Discounts + Stripe + Invoice generation

Yes, this is the exact reason why I asked about it. In its current state it's not even as complete as Padloper 1 so the most I could do is playing around with it. And that would not be a proper beta test I'm afraid.
It's been years since I last used PayPal for anything so Stripe is a must have on my list, I'm not so much into custom solutions though...

[kalimati]

Preferences for features to implement next:
Payment Gateways which are a necessity for an ecommerce module. Especially configuration / setup of alternative gateways beyond Stripe and Paypal.  

[Pixrael]

I had already suggested to @kongondo that he could use Omnipay Library as part of the Padloper module. But I don't know if this Library is a good choice, since no one here in Processwire has ever implemented it as a module.

[szabesz]

For anyone interested, I have created a set of placeholder images to be used for webshop projects and such. Should be useful for fellow Padloper 2 testers :) Download it from over here:

https://szabesz.hu/_dl/pw/shop/dummy_webshop_images_v1.0.0.zip

Note: some items have color variation images included as well.

[Pete]

On 1/11/2022 at 5:10 PM, Pixrael said:

I had already suggested to @kongondo that he could use Omnipay Library as part of the Padloper module. But I don't know if this Library is a good choice, since no one here in Processwire has ever implemented it as a module.

I don't think you can rely on Omnipay for all  but it may be okay for some. A warning sign for me is the age of some of the open issues in the Omnipay PayPal repo: https://github.com/thephpleague/omnipay-paypal/issues and the date of the last commit being quite a while back. A few other Omnipay modules have similar issue lists.

PayPal and Stripe I imagine are going to be the two most common and have pretty good docs and vaguely similar interfaces (they both suggest the JS checkout - PayPal are starting to direct developers that way and are using wording suggesting the old ways of initiating the payment are becoming legacy though I can't remember the exact docs). Both have the PHP libraries for manipulating payments after the transaction is in their systems which is fine as I believe they're all trying to make the PCI server compliance issue go away by the card data never being on your server.

Even Worldpay has gone JS + PHP now with a similar implementation from what I've briefly seen of their docs.

I would think that if any were to be officially supported as part of the project it would be PayPal and Stripe as the two most common. PayPal is still going to be more common than Stripe sadly so probably that as the first one.

I do agree with the Omnipay approach of a common interface, so perhaps if these were the first two and @kongondo you took inspiration from how they've done it in terms of the common interface, then those devs capable of writing additional payment modules can use the same approach. Or perhaps because this is such a critical piece of the puzzle it needs collaboration right from the start with those with a lot of experience with payment libraries - I'm not sure - but that wouldn't be me (I just follow the provider docs and if it works it works ? ).