Powered by Cookiecutter, cookiecutter-django-shop is a set of templates for jumpstarting a django-SHOP project quickly.

Use these Cookiecutter Templates to run one of the demo merchant implementations.

• To get a first impression on its features.
• Select the configuration example which is the most similar to your own requirements. Then replace the product models and templates with your own implementations.

Install Cookiecutter, pipenv and npm onto your operating system, for instance

on Ubuntu

Check that your default Python is version 3.5 or later. In Ubuntu-18.04, Python version 2.7 is the default, therefore activate Python-3.6 using:

sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.6 1

Before installing django-SHOP, a few additional packages must be added:

sudo apt install nodejs npm python3-pip
pip install --user pipenv cookiecutter autopep8

on MacOS

sudo brew install node
pip install --user pipenv cookiecutter autopep8

then change into your projects directory and invoke

cookiecutter https://github.com/awesto/cookiecutter-django-shop

You will be asked a few question. If unsure, just use the defaults. This creates a directory named my-shop, or whatever you have choosen. This generated directory is named the merchant implementation. For simplicity let's refer to it as my-shop in the following documentation. This directory is where the merchant keeps its configurations, adds his own Django models and overrides the templates.

Running the django-SHOP demo locally is probably the best choice, when you want to experiment with alternative product models, and hence want to edit the code generated by the Cookiecutter template.

When asked by Cookiecutter: Select dockerize, choose 1 - n.

cd my-shop
pipenv install --sequential
npm install
pipenv run ./manage.py initialize_shop_demo
export DJANGO_DEBUG=1
pipenv run ./manage.py runserver

After the above job has finished, point a browser onto http://localhost:8000/ and login with user admin and password secret.

This demo uses SQLite as its database. It neither supports caching, nor full text searches, nor an asyncrounous worker.

Please be patient during the first page loads, because media files have to be downloaded and thumbnailed andthe latter is a time-consuming task.

Running the django-SHOP demo inside a Docker container, allows you to test all features such as full text search using Elasticsearch, Redis caching, running asynchronous tasks and it uses Postgres instead of SQLite as the database. All these services run in a separate Docker containers, all managed by docker-compose.

There are three different options to run the merchant implementation of django-SHOP inside a Docker container:

• runserver: is intended for local development, for those who do not want to setup their own virtual Python environment.
• uwsgi: is intended for testing a productive or staging system, without having set up NGiNX (see below).
• nginx: is intended for productive environments, where the application server runs behind NGiNX.

After generating the project using Cookiecutter, all of them can be build using these commands:

cd my-shop
docker-compose up --build -d

When asked by Cookiecutter: Select dockerize, choose 2 - runserver and debug="y", to build the merchant implementation using Django's built-in runserver. This will start a webserver, listening on the IP-address of the docker-machine and on port 9009 (if unsure invoke docker-machine ip). Here the working directory is mountet inside your local file system. After editing a file, the webserver is restarted, so this setup is well suited during development.

Point a browser onto http://<docker-machine-ip>:9009/ and start surfing. To access the Django admin interface, log in as admin with password secret.

In environments, accesible from the Internet, we shall never run the application server using Django's runserver. By chosing 3 - uwsgi for dockerize, Django runs as a uWSGI application runner. This configuration can be used to run an unencrypted demo shop, for instance in a staging environment.

Point a browser onto http://<docker-machine-ip>:9009/ and start surfing. To access the Django admin interface, log in as admin with password secret.

In the previous configuration, the uWSGI application runner is configured to listen on port 9009 for HTTP requests. In a productive environment, we usually want to use NGiNX as a reverse proxy in front of our Django application server. This allows us to dispatch our services on multiple domains. In addition, NGiNX also supports https via Let's Encrypt.

First we must create two separate Docker containers. This step must be done only once per host. Behind this setup, we can connect as many application servers as our machine can handle. In a separte folder, named for instance NGiNX-Proxy, create a file named docker-compose.yml adding this content:

version: '2.0'  # or later

services:
  nginx-proxy:
    restart: always
    image: jwilder/nginx-proxy:latest
    ports:
      - '80:80'
      - '443:443'
    volumes:
      - nginxcerts:/etc/nginx/certs:ro
      - nginxvhostd:/etc/nginx/vhost.d
      - /usr/share/nginx/html
      - /var/run/docker.sock:/tmp/docker.sock:ro
    networks:
      - nginx-proxy

  letsencrypt-nginx-proxy-companion:
    restart: always
    image: jrcs/letsencrypt-nginx-proxy-companion
    # environment:  # remove this fake certificate in production
    # - ACME_CA_URI=https://acme-staging.api.letsencrypt.org/directory
    volumes:
      - nginxcerts:/etc/nginx/certs:rw
      - /var/run/docker.sock:/var/run/docker.sock:ro
    volumes_from:
      - nginx-proxy

networks:
  nginx-proxy:
    external: true

volumes:
  nginxcerts:
  nginxvhostd:

Start both containers, the proxy together with its companion:

docker-compose up -d

If both containers are running, switch back to your the directory and recreate the project answering Cookiecutter on Select dockerize with 4 - nginx. This creates a template which again can be built into a composition of Docker containers with our usual build command (see above).

Here it is important to note that the webserver is listening on the IP address referenced by the answer given on the Cookiecutter question virtual_host. Then point a browser onto http://<virtual_host>/ and start surfing. After a few minutes, the SSL-certificate shall be ready, then you can even browse using https.

Now that you have a simple working project, it usually is much easier to evolve into a real project for the merchant's needs. Remember that there are 3 different ways to arrange your product models:

• commodity: If you want to use a freeform CMS page to describe your products. It is usually the best solution if you only have a handful of products, or if the kind of product differs a lot.
• smartcard: If you have one concrete product model for all products in your shop.
• polymorphic: If you have different kinds of products, each requiring their own concrete product model.

By answering the Cookiecutter builder with YES to use_i18n, multilingual support is added to the project. Currently only English and German are configured, but this can easily be changed by adopting the LANGUAGE parameters in the project's settings.py.

By answering the Cookiecutter builder with YES to use_paypal, PayPal support is added to the project. You have to apply for PayPal credentials and add them to your environment or into the project's settings.py or through the environment variables PAYPAL_CLIENT_ID and PAYPAL_CLIENT_SECRET.

By answering the Cookiecutter builder with YES to use_stripe, Stripe support is added to the project. Currently you may use the sandbox credentials provided with the demo, but feel free to apply for your own ones and add them to the appropriate parameters in your settings.py or through the environment variables STRIPE_PUBKEY and STRIPE_APIKEY.

By answering the Cookiecutter builder with YES to use_sendcloud, SendCloud support is added to the project. You have to apply for your own ones credentials, as SendCloud does not offer any sandboxing.