Plugin platform: e-commerce

Bloke · 2019-12-28 16:44:47

Although this is probably not the right time to mention this, I have some vague ideas about building an e-commerce platform for Txp in the form of a plugin that ties together various aspects of the system. Not sure if anyone’s familiar with yab_shop (which I modded to add a whole bunch of stuff for a client, once). But I’d like to revisit that idea and redo it, in a little more modular fashion, using modern Txp components as building blocks.

The reason I’m holding back on this is because I think unlimited custom fields are an absolute must to make this work. They’re coming (honest).

The general idea is to use Articles as Things to Sell – whether they be downloads or physical products, using:

Custom fields as attributes like size, price, colour, features, etc
Excerpt and Body as short/long description
Article images as product images
Keywords as tags (forthcoming in Txp, we hope)
…

and so forth. That way, you can put sellable items in Sections and/or tag them (categories/tags) so people can find them. You can filter them (natively in v4.8) from the URL, use custom permlink schemes per section (again, from v4.8+). A lot of the functionality in 4.8 allows us to do this, and adding unlimited custom fields and (perhaps) keywords tagging in the next version is the final piece of the puzzle.

Anyway, integral to this e-commerce platform/plugin are two additional features:

The ability to tie a product combo to an image set, so if you pick, say, medium + red, the image changes accordingly. That’s complex and I don’t know how to manage that yet, but I expect matching custom fields across content types to feature heavily.
The ability to add modular plugins to accept payment gateways such as PayPal (IPN), MoneyButton, Visa/Mastercard, Square, Authorize.net, WePay, Stripe, AmazonPay, WorldPay, ApplePay, blah blah.

The latter feature, I envisage, would be bolt-ons to the main plugin’s cart functionality, so anyone using it could add the main shopping cart system and then either roll their own 3rd party payment system (perhaps offsite) or install one or more payment modules to have the main plugin support those gateways at checkout.

I’ve not thought it through much beyond that, but I think a project like that has good scope for Textpattern – if we define what it is and, more importantly, what it isn’t.

Current options in the marketplace are the usual cart platforms like Shopify or OScommerce or even Wix if you’re a masochist. But they want your entire site to be “the selling platform” with other stuff on the side. If you have a site with selling on the side (e.g. small cafe offering branded merch, paintings/photos to sell, an event photographer who wants to offer bundles of services, etc) then these platforms either work out too expensive or too unwieldy to manage as your portfolio grows. That’s where I see a Txp solution fitting.

If anyone’s interested in being part of this when the time comes, I’d love to put together a bunch of us to scope out how this platform might work and integrate with Textpattern.

kuopassa · 2019-12-28 16:56:29

Good stuff. :-] yab_shop did things so nicely that it could be used 1:1 as a source of ideas. I think it could’ve been much better with more payment methods, an inventory system, and with logging (saving to a database significant events that happen).

Inventory could be as simple as having a custom field with an integer that decreases when someone makes a successful purchase.

Bloke · 2019-12-28 17:48:09

Yes, I really like yab_shop. As you say, things that would make it better in this next realisation would be:

Some configuration mechanism to map CFs so that combos can be made more easily. Bonus points if they can be tied to images and other entities (see below).
Modularised payment systems.
Product dimensions – w x h x d and weight, per combo.
Postage and packing table band options, by carrier/weight/size. This is something I built into my fork, but it was a kludge and needs to be done better.
Tax rates. This is an absolute minefield, because some tax jurisdictions and rules apply to the product/combo (and perhaps where it’s sourced) while others apply to the shipping depending on where it’s being sent. Quite often both, with different rates. I added a “product tax rate” custom field based on a bunch of pre-configured rates, but it was unsatisfactory. It needs applying to the ‘article + CF combo’, not just the article. For example, in the UK, physical books don’t attract tax, but e-books do. So if you made one product (article) for a book, and used a “type” custom field (paperback/kindle) to distinguish which format the buyer wanted, the tax rate for the paperback would be 0 but the kindle edition would be 20%. If you don’t permit this level of config, you need to create two articles – one for each ‘version’ – which doubles the amount of duplicate metadata.
Inventory – good idea. Hadn’t thought of that, but very handy.
An event table – yes, this is something that I added as part of smd_ipn so when a transaction was complete and the webhook was pinged, it updated the table with the txn ID and details (payment amount, tax, product SKU, success/failure and reason, etc). This was then (via a little admin panel) tied to the product to see what was sold, and when. It was a hack, but it worked.

Instead of handling such event logging in the payment gateway module, it would be better if we had a simple API in the main plugin so that when the return path from a webhook fires and the transaction is complete, results can be recorded in a central table. The hook could then go on to perform a chain of customisable “business logic” depending on the outcome. So, for success, it might decrement the inventory counter against that product, send off an email to a nominated dispatcher/dropship supplier/customer, and so on.

yab_shop has a lot going for it. Just really needs to have the payment stuff stripped out and modularised (using callbacks to handle them instead), add webhook management, and shoehorn the above stuff in somehow!

Pat64 · 2020-01-26 04:05:49

Hi Stef.

I’m very interesting about this kind of new enhanced e-commerce plugin and I can support its development (up to 100€) in the next 3 months.

jakob · 2020-01-26 12:06:39

It’s not a situation I’ve faced much, but I am aware that it is a ‘shortcoming’ of Textpattern and that people go elsewhere for that reason. So I would likewise be willing to chip in to the same tune if that helps in providing motivation :-)

Bloke · 2020-01-26 15:25:49

Thanks, guys. Seems there’s a need for this, so let’s get some traction going. First job: decide what we want it to do, and where we can add value to Textpattern, and (possibly more importantly) decide what is out of scope, or those goals we are not considering.

There’s no point trying to make this a Shopify competitor or to battle against the might of a dedicated selling platform. This is system to augment the article and image concepts we have and unify them in such a way that people can sell stuff. Need to take into account the new custom fields branch. Maybe this shop system is integral to it?

Here’s my starter:

Products are articles, with supporting image(s). Files too, if the item being sold is a digital download.
Custom fields supply metadata. Need to find a way to tie CFs and images to provide specific “instances” of products for sale (e.g. variations in size, colour, weight, price or other physical factors).
These specific instances are tied to inventory. Sell a Large Red Thing, the large-red-thing counter goes down.
A shopping cart with ability to add, edit, remove, alter quantities.
Support pre-orders. Simple, perhaps? Future-dated articles with the release date. However, I suspect payment needs to be taken on release date not in advance, which implies some kind of trigger required.
Checkout page with shipping estimates (if possible) based on lookup tables that use the metadata (such as size, weight) combined with a carrier/method chosen by the site visitor. Carriers and delivery tables configurable by administrator.
Tax – urk, see above.
Payment modules – bolt on, depending which provider the site wishes to support.
Support a unified, configurable callback webhook to receive payment confirmation/denial.
Configurable business logic chain on success/failure of payment.
Log at each step wherever necessary, especially at transaction success/failure points.
Search/filter – any way to help people shop by brand, price range, size, whatever would be helpful. This should be fairly easy to build on 4.8+ with the custom field filtering from the URL.
(possibly) Create customer account – a user at a dedicated level in Txp that has front-end only permissions. Rudimentary bio info. No card storage at all – that’s a minefield. BUT how would pre-orders work in that case?

I know design by committee is bad, but if anyone has any preliminary thoughts/additions/amendments to the above scope, please state them in this thread. We should then capture this info in a document and make sure it’s achievable. Then dive deeper into how to actually make it work.

This may actually spawn some changes to the way Txp works, or augment our recent article concepts. For example, I could see product variants being defined in a pageless section. There’s some nice compartmentalization here to have a “master article” that contains the full blurb with generic product pics, base price, etc, and then a series of ‘child’ articles each with a single value in the appropriate custom field – price size, weight, whatever.

When viewing the main product page, a bunch of dropdowns can be built automatically based on the custom field values for price, size, weight. If these child articles have their own image(s) and their own descriptions (body text), when someone chooses a variant from the dropdowns, the new image and its blurb can be displayed. Not sure if the variant-specific blurb would replace the base description or add to it. Further, any article combinations that are out of stock can be indicated via the inventory counters, perhaps with email alerts when back in stock or option to pre-order, depending on feasibility of doing so.

Possible sticking point: these articles – the variants – are not directly accessible from the URL unless they are accompanied by the master article ID. So while they are shareable, are they searchable/indexable?

Lots to think about. My brain only stretches so far. Let me know your thoughts on this stuff.

WebmistressM · 2020-01-27 19:11:07

I have been following this topic, as I have been interesting at some of the case studies (for websites) that are closer to what is probably the edge of Textpattern’s capability. (e.g. “How far can you take Textpattern? Well, lets find out”)

Concerning Textpatterns base structure, it seems that everything is basically an article or page. In regard to other types of content, it always comes down to suiting things around the article content type. As you have cited in your list, Products would be no different. It might be considered a “content type” that definitely leans towards having imagery. I would be curious what kind of expansion can be done on display of images, including interacting with variant products.

trenc · 2020-02-10 15:29:23

Aww Stef,

that’s a really nice idea. I would really see yab_shop going further or – at least – used in some way in the future. The code base is really, really old and needs refactoring.

Thumbs up.

zenman · 2020-07-13 02:43:31

Very good idea!

Custom fields as attributes like size, price, colour, features, etc

Let’s say a site has about, blog, contact articles, the site administrator or publisher does not need to see an empty custom field “price” when editing article from blog section. In theory, would it be possible to hide size, price, colour custom fields in sections other than shop section?

Bloke · 2020-07-13 06:41:26

zenman wrote #324466:

would it be possible to hide size, price, colour custom fields in sections other than shop section?

When unlimited custom fields hit the Txp shelves, yes. This functionality will be easy to add with a simple plugin.

Longer term we might offer the feature in core.

colak · 2020-07-13 06:47:30

Bloke wrote #324468:

Longer term we might offer the feature in core.

🤞

TNT · 2020-07-13 11:05:48

zenman wrote #324466:

Very good idea!

Let’s say a site has about, blog, contact articles, the site administrator or publisher does not need to see an empty custom field “price” when editing article from blog section. In theory, would it be possible to hide size, price, colour custom fields in sections other than shop section?

I use the plugin bot_wtc to hide elements in the Write tab, based on the section in which to post. Or isn’t this what you meant?

Textpattern CMS

Textpattern CMS support forum

#1 2019-12-28 16:44:47