1. Plugins

Django SHOP defines 3 types of different plugins for the time being:

  1. Cart modifiers
  2. Shipping modules
  3. Payment modules

1.1. Cart modifiers

Cart modifiers are plugins that modify the cart’s contents.

Rough categories could be discount modules or tax modules: rules for these modules are invariant, and should be “stacked”.

Example: “CDs are buy two get one free this month”, “orders over $500 get a 10% discount”

1.1.1. How they work

Cart modifiers should extend the shop.cart.cart_modifiers_base.BaseCartModifier class.

Users must register these filters in the settings.SHOP_PRICE_MODIFIERS settings entry. Modifiers will be iterated and function in the same fashion as django middleware classes.

BaseCartModifier defines a set of methods that implementations should override, and that are called for each cart item/cart when the cart’s update() method is called.

1.1.2. Example implementations

You can refer to the shop.cart.modifiers package to see some example implementations

1.2. Shipping backends

Shipping backends differ from price modifiers in that there must be only one shipping backend selected per order (the shopper must choose which delivery method to use)

Shipping costs should be calculated on an Order object, not on a Cart object (Order instances are fully serialized in the database for archiving purposes).

1.2.1. How they work

Shipping backends need to be registered in the SHOP_SHIPPING_BACKENDS Django setting. They do not need to extend any particular class, but need to expose a specific interface, as defined in Backend interface.

The core functionality the shop exposes is the ability to retrieve the current Order object (and all it’s related bits and pieces such as extra price fields, line items etc...) via a convenient self.shop.get_order() call. This allows for your module to be reused relatively easily should another shop system implement this interface.

On their part, shipping backends should expose at least a get_urls() method, returning a urlpattern-style list or urls. This allows backend writers to have almost full control of the shipping process (they can create views and make them available to the URL resolver).

Please note that module URLs should be namespaced, and will be added to the ship/ URL namespace. This is a hard limitation to avoid URL name clashes.

1.3. Payment backends

Payment backends must also be selected by the end user (the shopper). Theses modules take care of the actual payment processing.

1.3.1. How they work

Similar to shipping backends, payment backends do not need to extend any particular class, but need to expose a specific interface, as defined in Backend interface.

They also obtain a reference to the shop, with some convenient methods defined such as self.shop.get_order().

They must also define a get_urls() method, and all defined URLs will be namespaced to pay/.