Custom Checkout Module Pt 2 - Server Connect Action

Welcome to Part 2 of the Custom Basket Series.

The basket (empty) and product tables (few sample items) are attached as zipped .sql files at the end of this page as is the server action as a .zip file. There is no need to manually create it yourself
Note: this action is heavily commented for your guidance
This can be used as a “blackbox” All files required are attached to use this solution can be used with only minor modification (database connection settings)

The Session

This module deals with the server action to handle the shopping basket
The checkout is database table based and uses the current session ID to manage the basket item ownership
This requires a small piece of PHP code in the calling page’s code to get the session ID

So the app connect page will have the following code inserted at the top of the page and by top i mean the FIRST thing on the page, even before the <!doctype definition

The code is:

<?php session_start(); if(!isset($_SESSION['cart_session'])) { $_SESSION['cart_session'] = session_id(); } ?>

Just like this:

This session variable will be critical to manage the basket.

Before i start i need to make explain my methodology
Firstly i needed to keep this simple as i needed it to be able to be used as a “black box” solution for non programmers
Secondly i have written it in a way where it is optimised for understanding, not efficiency, it has to be as simple as possible to amend the server action for those with limited coding experience

So lets start with the globals, POST and SESSION

POST Variables

These are the data items send from your calling APP connect page


productid is self explanatory, this is the unique product code which can be numeric or alphanumeric. This is mandatory in all actions other than delete

quantity is the quantity of those items required (numeric)
In addition i have added the ability to add up to 3 “descriptors”, this could be things like size, colour etc
They are optional and called
descriptor2 and

baction is the basket action and can have the values ‘add’, ‘update’ and ‘delete’ (more about this later)
If not sent then this server action will simply return the current basket contents
last rid is used to pass the basket record id for delete actions

SESSION Variables

Before explaining them i need to explain my methodology as it may seem strange and even possibly unnecessary. Where setting variable within Server Action repeats I prefer Set Session to Set Value. Why? I worry about scope of variables and by using SESSIONS i can be sure that there are not multiple variables created with the same name but in different variable scopes. SESSIONS can be considered PUBLIC in all cases


cart_session is the SESSION variable set in the custom PHP code
pq holds the ProductQuantity
baction is a session copy of $_POST.baction (you will see why later)
basketTotal is not currently used
NOTE, as i am using stripe integration in this series i store prices in base currency units so £1.50 would be stored as 150. This is not mandatory however to use decimal units i.e. 1.5 then the attached database structure will need to be amended as it is currently set to int

Setting up the connection

Next we define our connection a number of variables.

Note: this action is heavily commented for your guidance

First stage is easy, simple define your server connection of create a new one. I wont go into details, this is well documented elsewhere


Defining Variables

Variables are used to improve clarity for readers

Next we go to Core Actions => Set Value and create a variable cartsessionid

and set it to out SESSION variable declared in the custom PHP above

Session cartsessionid


This will identify the owner of the basket items

Variable productid

next we define the productid variable using Core Actions=> Set Value


Variable bquantity

Next we define the basket quantity variable with Core Actions =>Set Value


descriptors 1,2 and 3

These are the items extended information fields such as size, colour

Use Core Actions=> Set Value

Setting default values in descriptors

They have a default of an empty string set, this is VERY IMPORTANT or additional code would be needed to deal with null values in the data queries

The Basket Action

SESSION baction

The basket can receive 3 instructions, add, update and delete. However a fourth action is used internally called addto which adds the current item to an already existing basket entry. This is NEVER sent, it is computed

So we use core Actions => Set Session to set the basket action to $_POST.baction

SESSION variable pq

This variable is used within the computed ‘addto’ action and this SESSION variable is used to hold the quantity of the product already in the basket before the additional items are added
It is initialised to zero


variable rid

rid is the record id in delete events and is passed via $_POST.rid
so we go to Core Actions=> Set value and set variable rid to $_POST.rid


Checking the basket to see if this item is in the basket

Technically this would be better included inside the ‘add’ section but for clarity i do it here
We need to check the current basket and find is any item exists with the same product ID and identical descriptors (that why we forced nulls to empty a strings above, makes this easier)

We do that with a simple data query

We query the basket items and return the quantity if the entry found

adddate and userid

*NOTE adddate is auto entered from Current_timestamp at MySQl level. userid is for later use when saving a basket to a registered customer (later lesson)

We return the quantity


The basket is filtered on the current user (via session ID), the product id and descriptors (can’t add red shirts to blue shirts!)

Now we set up a repeat via Core Actions=> Repeat and set it to expression {{qry_check_qty}} our previous query


If not data returned this repeat will not happen, if there is data returned we need to deal with this as an addto event.

We set SESSION variable pq to the current quantity returned by the action {{quantity}} and redefine the session variable baction to to ‘addto’

Processing Stage

Now we have everything set up and can process the basket based on $_SESSION.baction

Basket Add (baction == add)

Firstly we deal with the basic ‘add’ action

NOTE: for some reason Wappler sometimes reverses the then and else statements, it don’t know why but is it purely cosmetic, everything works perfectly. it just looks a little strange

checking a quantity has been sent

So we firstly check that a quantity has been sent by checking the variable bquantity using as Core Actions => Condition and checking for quantity being more than zero

If so in the then part of the condition we can move on to checking for a product id

If no quantity is sent the in the else section we respond with an error using Core Actions => Response

I have user error 442 (unprocessable_entity) and respond with an error message “no item sent” which can be liked with the form validator stage

If quantity is set we next check for the product ID, if omitted we again respond with an error code 422 as above

If we have a product code we can now add the item to the basket

Add more of an item already in basket (baction==“addto”

In this case we already know a product id has been sent so we can just go ahead. If no quantity is set, the quantity will just remain the same


So we set the quantity to the quantity sent vai $_POST. quantity (now stored in variable bquantity) and add it to the amount already in the basket, currently stored in $_SESSION.pq.
Notice both entries are set .toNumber()

And our conditions are that the session, productid and all descriptors match

Delete Item (baction == “delete”


This is a simple delete action based on the record id sent from the checkout

Update basket (baction==“update”

This would traditionally be available in a checkout to allow the user to change the quantity of times in a basket directly by changing the quantity field like this:


This simply updates the quantity field based on the record id and quantity of the basket item being sent.


Returning the basket contents

Finally we retrieve the contents of the basket


This simple query joins the basket table and the products table on productid and returns the basket items, item name and item cost to the checkout. Ensure Output is checked!

Totals are calculated at APP connect level

Next we will deal with the APP Connect side of the basket.

I hope i have explained everything enough, any questions please ask

Sample Files (3.5 KB) (539 Bytes) (528 Bytes)


Love the detail of this. Thanks for your work in putting this together. I’m sure it will be very useful to a lot of users. Great job.

@Hyperbytes - Thanks for all your good guide you are putting together for Wappler.

Do you know when you will be putting up the APP Connect side of the basket?


Really sorry about that, it’s all ready, just got side tracked with webinars and things. I will make an effort to do it asap.