How To Guides
Deferred / Provisional Baskets
3. Provisional Basket Behavior
Overview
This feature will defer the creation of basket entries in database until a shopper performs some sort of action that requires an entry to be created, such as add to cart. This prevents bots, crawlers and other automated scripts (including shoppers just browsing the site) from creating unneeded baskets in the database which will eventually get deleted anyway when they expire.
For backwards compatibility when this feature is enabled, a "provisional" basket is created behind the scenes, which will be used to trigger the creation of an actual basket without losing client-side stored session information. This allows if a real shopper does in fact take an action such as adding a product to the cart, the session data associated with their provisional basket is copied over to the real basket entry.
Note: Even with deferred baskets enabled, its still required for expired baskets deleted via the scheduled task. Defered baskets instead allows the store owner to safely extend the basket timeout longer than the default 60 minutes since non-human traffic will never create new baskets, keeping the basket table size reasonable.
Enabling Deferred Baskets
Note: This setting is enabled by default in all new stores set up post 9.13. However, for existing stores it will need to be enabled manually.
To enable deferred baskets there is a new store level checkbox under Store Settings:
Provisional Basket Behavior
When a shopper has a provisional basket, the basket cookie will still be set as usual however it changes on every page load. This is intentional and normal behavior with how provisional baskets work. Because there is no "real" basket to associate the shopper with, the provisional basket and the cookie associated with it get reset on every page hit. Once a provisional basket gets converted into a real basket, the basket session and cookie stay consistent and work exactly as they always have.
Template Level Functions
Via the template language there is a function you can call to test whether a basket is provisional basket:
This will return a 1 if it is a provisional basket and a 0 if it is not.
Custom Basket Fields
Basket Field Read
If a shopper has a provisional basket, and you have code to attempt to read a custom basket field, it will behave as if they custom basket field does not exist (ie no data will be returned)
Basket Field Write
When you write a custom basket field and the basket is provisional, Miva will automatically convert the provisional basket into a real basket so that the custom basket write function will continue to work as expected
If you have global basket custom field writes such as collecting the IP address, to avoid converting all provisional baskets to real baskets you can instead wrap the write_basket function in a conditional:
Considerations Before Enabling
While all native functionality has been tested and will work with deferred baskets enabled its also important to verify any 3rd party modules or custom template code continue to work with deferred baskets enabled.
Here are some areas to look out for:
- Template code that directly accesses basket tables using toolkit or toolbelt
- Third-party modules that directly access basket tables
The potential problem in either of these use cases is that while the basket is in a provisional state, the session_id will change for that user on every page hit. If template code or a module is using that session_id, it will assume that the hits are from different users.
XML Provisioning Tags
The following provisioning tags are available: