Django boilerplate


Bootstrap + HTML5 Boilerplate + Common Packages, Tomita Style.

My plot for world domination is stagnating due to wasted time loading the same plugins, configuring comically similar projects, and feeling utterly lazy about adding jQuery easing just because I'd have to go google it.

World domination can't wait.


  • Hell yes we'll use the admin, are you freakin kidding me?
  • Use SQLITE by default. If you need to change it, you'd have to change it anyways.
  • set to defaults
  • Uses relative settings directory with and . How many times have I written that?
  • Global templates dir in project root.
  • Why don't we call the so it can be fuzzy differentiated vs 1000 other mmkay?
  • No, we don't need to add anything in the user uploads directory to git.
  • Serve files from @ when in . Runserver now serves automagically, why the hell not ?
  • Start with app for static pages and it even comes with an , imagine that!

###Forcibly installed django apps

Yeah that's right... there are some apps that are unquestionably useful.

  • Django Extensions: I know how much you like importing apps in the shell, but seriously, get over it.
  • South: Without database migrations, you are nothing.
  • Pillow: Python Imaging Library with a better success rate. We like don't we?
  • Django Debug Tolbar: The method you wrote that eats 100 queries per object listing doesn't want you to know about this.
  • Fabric: Something that I only install when I've already repeated at least 100,000 times. Save yourself the trouble.

###Questionably forcibly installed django apps

I feel like these apps are used enough to warrant auto inclusion and explicit removal.

  • Mailer. Don't we need to send emails?
  • Sorl Thumbnails. Sometimes I don't use it, but only because it's not installed already and I am lazy.
  • Gunicorn. Yeah, you might not be using it. You'll thank me later.
  • The only reason not to include this is because it requires a non python dependency (memcached itself.)


  • Bootstrap
  • Media queryies are WTF confusing. I conceptually simplified , , , to , , , etc. so my feeble brain can grasp this nonsense.
  • Responsive design debugging snippet at top that displays current bootstrap media range.
  • No crazy scripts at the bottom causing issues with inline scripts that need jQuery. F' that! If you want to be that cool, please spent .2 seconds moving the script.
  • Less is awesome. Never leave home without it.

Common Packages

Common packages are included with commented out script tags in the base theme for easy awesomeness.

Responsive design helpers

Media query helpers

Bootstraps default descriptions are a little confusing. The variable names do not have enough common in the variable names.

Am I on tablet portrait or phone horizontal right now?

I find it much easier to deal with responsive design by using media query tags which simply indexes smallest-to-largest designs.

  • @media-1
  • @media-1-max
  • @media-2
  • @media-2-max
  • @media-3
  • @media-3-max
  • @media-4
  • @media-4-max

Use the variables for min-width queries.
Use the for max-width queries.

To target browsers between media-1 and media-3 (what bootstrap would call "portrait phones" to "default"):

Media query debugger

The base theme.html template comes with a simple debug div which displays the current media query range.

For example: .

Installation and Usage

Either clone the repository and take the contents, or use it as a template provided to the command.

Folder Structure

Note: I've set this up to build the project container folder as well as the django project root, so you will get a triple nested structure if you don't change the name of the root project folder after running .


Will result in a structure like so:

So rename the top-level my_project to something generic. It's not required, but something just feels off about that idea.

The reason I do this is because I want my django project to be in a folder in my virtualenv simply called "django_project". It needs to be consistent across sites so I can easily crawl directories for and auto register supervisor scripts, nginx configurations, etc for multiple sites on one server.

Recommended setup

I'd recommend the following setup:

  1. create a virtualenv
  2. cd into it
  3. Create the django project
  4. cd into the django project container
  5. install the dependencies:
  6. cd into the django project itself:
  7. syncdb:
  8. migrate:
  9. run your dev server:

Fabfile Auto Generation

  • Some clever fabric script auto generation would be great.
  • We can access django's settings file and thus lots of the raw fabric file!


Boilerplate to create Django project.

This boilerplate creates a simple Django project with a core app and some pre-defined settings.

The project contains:

  • Settings config
  • App Accounts

  • App CORE
  • App CRM
  • App Expense
    • CRUD
    • Templates
    • Modal
    • htmx

CRM Model


Packages used in conjunction with Django.


This script run in Unix.

Update USERNAME to your username.

Type the following command. You can change the project name.


If yout want to use a alias.


CRM example.

App Expense

Example of a simple expense.

Exploring Boostrap modal and htmx.

New app

If create new app edit .

# accounts/ core/ crm/ expense/apps.pyname='PROJECT.<app name>'# examplename='myproject.accounts'name='myproject.core'name='myproject.crm'name='myproject.expense'


To populate database with fake data, use django-seed and type

Base Models

The app core contains abstract models to use in other models.

management commands

The app core contains a management commands example.

Graphic model Django with PyGraphViz

The next command generate the graphic of model.









  1. Magnetic silver board
  2. Ps4 hdd upgrade problems
  3. 2020 audi b8 s4
  4. Cigarette gifs
  5. Hummer h2 battery replacement

Django React Boilerplate

Contributor CovenantLicense: MIT


A Django project boilerplate/template with lots of state of the art libraries and tools like:

For continuous integration, a CircleCI configuration is included.

Also, includes a Heroku and a working Django settings, enabling easy deployments with 'Deploy to Heroku' button. Those Heroku plugins are included in :

  • PostgreSQL, for DB
  • Redis, for Celery
  • Sendgrid, for e-mail sending
  • Papertrail, for logs and platform errors alerts (must set them manually)

This is a good starting point for modern Python/JavaScript web projects.

Project bootstrap CircleCIGreenkeeper badge

  • Make sure you have Python 3.8 installed
  • Install Django with , to have the command available.
  • Open the command line and go to the directory you want to start your project in.
  • Start your project using: Alternatively, you may start the project in the current directory by placing a right after the project name, using the following command:

In the next steps, always remember to replace theprojectname with your project's name

After completing ALL of the above, remove this section from the project README. Then follow below.




  • Inside the folder, do the following:
    • Create a copy of :
    • Create a copy of :

If you are using Docker:

  • Open the file on a text editor and uncomment the line
  • Open a new command line window and go to the project's directory
  • Run the initial setup:
  • Create the migrations for app:
  • Run the migrations:
  • Run the project:
  • Access on your browser and the project should be running there
    • When you run , some containers are spinned up (frontend, backend, database, etc) and each one will be running on a different port
    • The container with the React app uses port 3000. However, if you try accessing it on your browser, the app won't appear there and you'll probably see a blank page with the "Cannot GET /" error
    • This happens because the container responsible for displaying the whole application is the Django app one (running on port 8000). The frontend container is responsible for providing a bundle with its assets for django-webpack-loader to consume and render them on a Django template
  • To access the logs for each service, run: (either , , etc)
  • To stop the project, run:

Adding new dependencies

  • Open a new command line window and go to the project's directory
  • Update the dependencies management files by performing any number of the following steps:
    • To add a new frontend dependency, run

      The above command will update your , but won't make the change effective inside the container yet

    • To add a new backend dependency, update or with the newest requirements
  • After updating the desired file(s), run to update the containers with the new dependencies

    The above command will stop and re-build the containers in order to make the new dependencies effective

If you are not using Docker:

Setup and run the frontend app

  • Open a new command line window and go to the project's directory
    • This is used to serve the frontend assets to be consumed by django-webpack-loader and not to run the React application as usual, so don't worry if you try to check what's running on port 3000 and see an error on your browser

Setup the backend app

  • Open the file on a text editor and do one of the following:

    • If you wish to use SQLite locally, uncomment the line
    • If you wish to use PostgreSQL locally, uncomment and edit the line in order to make it correctly point to your database URL
      • The url format is the following:
    • If you wish to use another database engine locally, add a new setting for the database you wish to use
      • Please refer to dj-database-url on how to configure for commonly used engines
  • Open a new command line window and go to the project's directory

  • Create a new virtualenv with either virtualenvwrapper or only virtualenv: or

    If you're using Python's virtualenv (the latter option), make sure to create the environment with the suggested name, otherwise it will be added to version control.

  • Make sure the virtualenv is activated or

  • Run to install the requirements

    Please make sure you have already setup PostgreSQL on your environment before installing the requirements

    In case you wish to use a Conda virtual environment, please remove the line from

Run the backend app

  • With the virtualenv enabled, go to the directory
  • Create the migrations for app:
  • Run the migrations:
  • Run the project:
  • Open a browser and go to to see the project running

Setup Celery

  • Open a command line window and go to the project's directory
  • or depending on if you are using virtualenvwrapper or just virtualenv.


  • For development, we use Mailhog to test our e-mail workflows, since it allows us to inspect the messages to validate they're correctly built
    • Docker users already have it setup and running once they start the project
    • For non-Docker users, please have a look here for instructions on how to setup Mailhog on specific environments

The project expects Mailhog SMTP server to be running on port 1025, you may alter that by changing on settings


Will run django tests using and . You may pass a path to the desired test module in the make command. E.g.:

Adding new pypi libs

Add the libname to either or , then either upgrade the libs with or manually compile it and then, install. or



This project comes with an file, which can be used to create an app on Heroku from a GitHub repository.

Before deploying, please make sure you've generated an up-to-date file containing the Python dependencies. This is necessary even if you've used Docker for local runs. Do so by following these instructions.

After setting up the project, you can init a repository and push it on GitHub. If your repository is public, you can use the following button:


If you are in a private repository, access the following link replacing with your repository link.

    Remember to fill the with the URL of your app, the default on heroku is . Replace with your heroku app name.


    Sentry is already set up on the project. For production, add environment variable on Heroku, with your Sentry DSN as the value.

    You can test your Sentry configuration by deploying the boilerplate with the sample page and clicking on the corresponding button.

    Sentry source maps for JS files

    The script has a step to push Javascript source maps to Sentry, however some environment variables need to be set on Heroku.

    You need to enable Heroku dyno metadata on your Heroku App. Use the following command on Heroku CLI:

      The environment variables that need to be set are:


      Write Django as usual, and let help you with the usually painfull stuff.


      • Python 2.7 or greater
      • Django >= 1.11

      The latest version supporting Python 2.6 and Django < 1.8 is the 6.x.x branch.


      1. Install using pip:

        Alternatively, you can install download or clone this repo and call .

      2. Add to INSTALLED_APPS in your :

      3. In your templates, load the library and use the tags:

      This app will soon require Django 2.x, python 3. Thanks for understanding.


      You can use this under Apache 2.0. See LICENSE file for details.


      Developed and maintained by Cubo.

      Original author & Development lead: Irving Kcam.

      Thanks to everybody that has contributed pull requests, ideas, issues, comments and kind words.

      Please see AUTHORS.rst for a list of contributors.


      0.9.4 (2019-11-19)

      • Fix: Getting the name of a formset without model.

      0.9.2 (2019-06-11)

      • Enhace: Allow redirect to the next parameter

      0.9.1 (2019-05-29)

      • Enhace: Add deletion variables

      0.8.1 (2017-11-21)

      • Add: _addanother or _continue
      • Fix: Allow redirection
      • Fix: Python 2.7 compatibility

      0.7.5 (2017-11-06)

      • Add: Append custom headers

      0.7.0 (2017-08-05)

      • Change: Search buttons by parent app name

      0.6.9 (2017-07-31)

      • Add: Set current user if field is available
      • Add: Set email language
      • Bug: Display transaction error

      0.5.8 (2017-06-19)

      • Add: Send email without template, only with content

      0.5.6 (2017-04-25)

      • Fix: Django 1.11 compatibility

      0.5.4 (2017-03-31)

      • Add: ModelImageThumbs Python 3 support.
      • Add: six requirements.txt

      0.5.0 (2017-03-28)

      • Add: ExtraFormsAndFormsetsMixin trasactions are atomic now, if something fails nothings gets saved.

      0.4.9 (2017-03-27)

      • Fix: ExtraFormsAndFormsetsMixin parent response prevail.

      0.4.8 (2017-03-27)

      • Rename: to
      • Add: Documentation add_view_permissions
      • Add: More tests

      0.4.5 (2017-03-25)

      • Remove: templates folder, and no longer required, no longer required, Django cover this.
      • Add: Initial tests
      • Update: PEP8
      • Bug: add_view_permissions Python3 compatibility
      • Add: Allow email testing
      • Enhancement: Rename variables formsets to formset_list and extra_forms to extra_form_list

      0.3.6 (2016-11-26)

      • Fix: LoginForm username and password required fields

      0.3.6 (2016-11-9)

      • Fix: If doesn’t found model name get form name

      0.3.5 (2016-09-30)

      • Fix: Raise PermissionDenied on NoLoginRequiredMixin

      0.3.4 (2016-09-30)

      • Fix: ModelImageThumb super class

      0.3.0 (2016-08-29)

      • Change: Improove mail, now it’s a class not a function

      0.2.8 (2016-08-19)

      • Add: New model child action template tag

      0.2.7 (2016-07-21)

      • Fix: Mixin CreateModelMixin
      • Improvement: No loger convert template tags to titles

      0.2.5 (2016-06-26)

      • Fix: PIL as new requirement
      • Fix: Requirements
      • Fix: Python3 compatibility

      0.2.3 (2016-06-26)

      • Added: add_view_permissions: Create a post migrate signal to add a new view permission to all the model
      • Added: ModelImageThumbs, and automatically create thumbnails from the images that you upload.

      0.2.1 (2016-06-20)

      • Fix: Forgot to import translation at

      0.2.0 (2016-06-18)

      • Rename: to because is the propper name
      • Add: with the default settings, you can customize your error messages.
      • Add: Forms with validation to the following Views:
      • Add: LoginView
      • Add: RecoverAccountView
      • Add: RegistrationView
      • Add: LoginView

      0.1.3 (2016-06-16)

      • Fix: CRUD Messages Mixin conflict with Extra Forms and Formsets Mixin
      • Fix: ExtraFormsandFormsetsMixin validate if formset_list or extra_form_list exists
      • Fix: App template tags, didn’t got the model information intead of the app information

      0.1.0 (2016-06-12)

      • Fix: CRUD Messages Mixin
      • Bug: Variables reasigned ExtraFormsAndFormsetsMixin on the get_context_data
      • Convert spaces to tabs

      Boilerplate django

      Table of Contents


      Through this tutorial we will setup a django project boilerplate that we can use to develop and deploy django applications. Among other things, we will go beyond the default project layout structure that creates when we execute that command. The objective is to develop a layout that is ready for deployment, with security at the forefront, and a clear separation of configuration / settings for development and production environments.

      The source code and the files needed to complete the tutorial can be found on github.

      This tutorial follows the best practices laid out on the book two scoops of django, the django project's documentation, as well my own experience in dealing with the subject.

      What you will learn / concepts we will cover

      1. Using virtual environments.
      2. git.
      3. Tailoring django settings to match development or production needs.
      4. Setting environment variables - system-wide scope and virtual environment scope.
      5. Hiding django's SECRET_KEY.
      6. Programmatically telling django whether the environment is development or production.
      7. Segregating and keeping track of production-only, development-only, and common django packages.
      8. Installing django-bootstrap, django-livereload-server, django-fontawesome.
      9. Setting up and serving static and media files.
      10. Setting up django apps.
      11. Creating a base model from which models can inherit fields / properties.
      12. Setting up and extending django templates.
      13. Developing a project layout based on best practices.

      Conventions throughout this tutorial

      Please review the conventions page, which will help you understand how I communicate with you through this blog.


      This tutorial assumes that you have at least completed the django turorial, and are familiar with the following:

      1. Installing python.
      2. Setting up a virtual environment, and more spicifically, virtualenvwrapper.
      3. Running commands from the CLI (command line interface), or the terminal; more specifically, throughout this tutorial, when I ask you to execute on the terminal, please be aware that there are several ways to do that, depending on how your environment is setup; for example, in my system (Mac OS), I have it setup so I only have to type ; you may have to type on yours.
      4. Installing and working with the git distributed version control system (or similar).

      Let's dive in.

      Installing our virtual environment and django

      Let's install our virtual environment and call it : . Once it runs, make sure that your newly created environment is activated (if not already activated) by executing .

      Now, let's install django by running .

      Now go to the location where your boilerplate project will reside, and create a folder called . Going forward, we will refer to it as the . Open a terminal window within the root folder, activate the virtual environment, and execute . If successful, you would have a newly created folder called within your folder.

      Inside of it, you should see the following file structure:

      Let's run the django server to make sure that it is ready to roll by going into the top folder and executing . django will warn us about unapplied migrations (let's ignore that) but we should see the typical page on our browser of choice if we point it to .

      welcome to django page

      Let's go ahead and run to get rid of django's warning about unapplied migrations. When we migrate, django adds a file within the second tier folder, which is the file of the database that we will use on our boilerplate application.

      Let's go back into the root folder, and let's initialize a repository by executing . By now you probably have a file that you use on your projects. If not, feel free to grab mine from here. Go ahead and put a copy of the file under the root folder. Our file structure should now look like the below structure. Remember, per the conventions page, certain files (including git and python cache files, are omitted).

      Once we get the above we are ready to do our first commit, by executing the following:

      1. - always verify what's being committed. In my case, I get the following output:

      2. .

      Let's go ahead and add the following folders and files to the root folder:

      Let's edit the above markdown file add the following . We'll leave it at that.

      Now, on the command line go into the folder and execute . A new file will be created there, listing the packages that we have installed when we ran and commands. The packages are:

      We will come back to the later.

      Our layout should now look like the following:

      Let's commit the changes: + (reminder: verify!) + .

      Let's refactor the second tier folder and rename it as , which is a more fitting name for that folder.

      For the refactoring to work, we must search for the string within the files under the first tier folder, and replace the relevant instances with the word . PyCharm, my favorite python development IDE, has a very handy tool to do just that; a snippet of the instances that PyCharm finds is shown below. You could also use , for instance.

      PyCharm refactoring results

      Once we swap for , we run the server (i.e., execute ) to make sure that our refactoring works OK; we should get the typical page.

      Our layout at the moment should look as follows:

      No more duplicate folders. Good bye confusion.

      Let's commit and call the commitment .

      The settings module

      Next, let's create a folder called within the folder, and add the files shown below.

      As you may be aware, the flags the content of the folder as a module, and will be treated as such by python.

      will host the common denominator settings for both our development () and production () environments, with and extending settings to meet the needs of each. You may also consider having a file with settings specific to an environment where you do your staging / testing right before going live. We won't touch on that here.

      We can now go through the contents of the file generated by django and ask ourselves, for each line:

      Below are the listings of the , , and files resulting from following the logic I just described.




      Not many changes at the moment, but we have attained a degree of separation between development and production, which we will now expand. Note the line, which is not part of the original file. We need it to extend the settings into and .

      By keeping limited to our local environment, when we deploy we don't have to worry about editing django's settings file to turn off which, for security reasons, is very important to do.

      Now, how do we go about telling django which settings file to use? For that, we will need to set an environment variable that we can use to programmatically instruct django to use the proper settings file.

      We'll call our variable . On our local environment, its value will be and on our deployment environment, it will be .

      For Mac OS (my development OS of choice), I just simply run on the command line, and add the following line to my file:

      Once I save the changes, I run on the command line, and then test that it worked by running , the result of which, if successful, should be .

      If you use a system other than Mac OS, switch ASAP! :) Nah, just kidding. A relevant google search will point you in the right direction.

      We'll cover the deployment portion (i.e., how to set the environment variable in our production environment) when we get to it.

      Now, let's tell django which settings file to use. Let's change the contents of our file from:


      We added the function , which allows us to humanize the error message given by django if for some reason it can't read the environment variable. Thanks to the folks at two scoops press for this and other valuable tips. Buy their book if you haven't done that.

      The below code block tells django which settings file to use, depending on the value of the variable.

      We can safely move somewhere else (or delete) the file.

      Our layout now should look as follows:

      If you notice, you will see that there are two files. django automatically dropped a file as a result of our refactoring the file into . We can safely delete the bottom one.

      Let's run to make sure that django is working OK. We should see the typical page. We should also notice that django is telling us again that there are unapplied migrations. Let's execute to get rid of that warning.

      Let's commit and call the commitment .

      django's SECRET_KEY

      One of the main reasons we are doing all this refactoring / re-arranging is security. As an example, by storing our in a file being tracked by (and potentially being uploaded to a public repository like github, we may be exposing it. Refer to django's documentation as to why it is important to keep it secret.

      We now know how to store variables in our environment. This time around, though, we will use a different procedure to accomplish that. We'll see why in a bit.

      By now you should be using (highly recommended!). By now I assume also that for every application you setup a different virtual environment (highly recommended too!). We will store django's secret key in our virtual environment. Go to the bin folder of your . For me, the path to the bin folder looks like . Within it there is a file called ; edit it as follows:

      As the second line informs us, whatever is in that file will be sourced post activation of the virtual environment. Go ahead and copy the key that django generated for you when you executed .

      The reason I use the virtual environment to store django's is that I make it different for each django application. Hence, as I activate the app's virtual environment, I get the app's unique key. As for the variable, its value (i.e., ) is always the same regardless of the application, and as such I store it in my system's and make it available system-wide.

      Make sure that what you just did works by deactivating and reactivating your virtual environment, and then by running on your command line. It should output your secret key.

      Next, edit your file so it goes from


      Let's run to make sure that django is working OK. We should see the typical page.

      Let's commit and call the commitment .

      There you have it. Your django's secret key is indeed secret now, and not out for the world to see when, for instance, you decide to upload your code to github :)

      Distinguishing between django, local, and third party applications

      Within the file, let's refactor the block of codes as follows.



      We have gained clarity and degree of separation between the different apps making up our boilerplate application.

      As usual, let's test that django runs OK. If it runs smoothly, let's commit and call our commitment .

      Distinguishing between development and production requirements

      Similar to what we did with , we will refactor our in such a way that we keep track of and use the right packages for our development and production environments.

      Let's add the following files to the folder: , , and .

      Let's commit and call the commitment .

      As far as figuring out where packages belong, the logic that we applied to refactor the file will be similar too:

      Let's install to illustrate the workflow, which is as follows:

      1. Start with a fresh git commitment (i.e., no changes yet to be committed);
      2. Start with a baseline file , which resides under folder ; it's imperative that it's kept up to date (i.e., follow step 4 below every time that a new package is installed); at the moment, the contents of our haven't changed:

        The above are required for the local and production environments, so they go into our file.

      3. Install the new package (don't do bundle installation of packages [i.e., ]; I recommend doing it one by one so you can keep proper track of dependencies); let's activate our virtual environment (if not already activated) and execute ;

      4. In the command line, and under folder , execute ;
      5. If you are using an IDE that integrates with git, it's likely capable of telling you that there is a new line, and will highlight it for you; if you don't have an IDE, running a on the file will tell you what new lines were added. The listing is below, showing our brand new package listed there.

      6. We can go ahead and copy the line into our file, for the package will be required by both our production and local environments. File at the moment reads as follows:

        Notice how I leave a one line space between packages. Later on we will see how some of them will have dependencies, and having that separation is useful.

      Let's add at the top of the contents of both the and files, which will tell to extend the requirements found in the file. That's all we have in those two files, for now.

      We now have the backbone to distinguish between local, production, and common packages. We'll be adding packages later as we complete our boilerplate, and we will see the workflow in action again.

      As far as installing packages from a file, we would run in our development environment, or in our production environment.

      For now, let's commit and call the commitment .

      Setting up the app

      Every app has a part that functions as the main or core portion of the application that acts as the glue that keeps all apps together. We will call this app the app. Some developers call it the app. I have stuck with to avoid confusion with, for instance, the library during module import operations. One could argue that could be problematic too, given that, for instance, it could clash with the line found in django's . It looks like we are out of meaningful words for such an app.

      At any rate, while under the folder in the terminal, let's run . Once it's done, our structure should look as follows:

      Within the file, let's register our application with django by changing:


      We'll continue setting up our app at a later time.

      For now, let's commit and call our commitment (don't forget to run , and double checking what's being committed).

      Setting up our application system folders

      We will install to enhance our app's ability to interact with the system environment. More info on can be found here.

      Let's follow the workflow that we discussed in our _Distinguishing between development and production requirements_ section.

      First, this package will be needed for both development and production.

      We are starting with a fresh commitment (you can verify that by running , which should result in a statement on your terminal).

      So, from the command line, and assuming that your virtual environment is active, run . Once the installation process is over, let's go into the folder on the command line and run . A new line pops up in our file, which reads . Let's copy that line into the file, which now should look as follows:

      Note that there is no need to add to the list of third party apps within the file. We can import it directly where needed by invoking .

      Let's commit, and call our commitment .

      Setting up our templates, static, and media directories

      Let's add the following folders and files within our folder:

      Our layout should now look like the following:

      Let's commit and call our commitment .

      While at it, let's add a folder under the folder, and a folder under the root folder (i.e., the folder). is where we will store our html templates. We will use as the destination where we will tell django to collect static files to serve them to our users. If you go into the file, you will find toward the bottom a line, by which we tell to ignore the contents of that folder. That's by design as those files exist somewhere else and are collected there by django just for web serving purposes.

      By now our full blown layout should look like the following:

      Now, let's edit so it goes from:


      Most of the code above is self-explanatory. Basically, we are telling django where stuff will reside, including static files, media files (which is normally made up of files uploaded by users), as well as the full path (including the filename) of our database file (in our case, we are using SQLite).

      Worth noticing is line , by which we tell django to use the directory four levels above the file as the (or our directory), which becomes the basis of all subsequent directories.

      We can test all the above by executing the below python3+ script:

      When I execute the script, I get the following:

      Which is exactly what I need.

      We can now edit the , like so:



      If you run the django server now, you will notice that another file pops up under the folder, and that, again, we have unapplied migrations. What has happened is that, via the new , we told django to store the database under that folder, as opposed to under the folder, and django went ahead and created a brand new there -hence the unapplied migrations. It makes more sense to store it under the folder, and we will keep it there. We can safely remove the old one, and apply migrations to get rid of django's warning.

      Our layout should look as follows:

      It's time to commit our changes. Let's call this commitment .

      A home page

      It's time to set up our home page. Under the folder, let's add a folder called to host our app templates. Within the folder, let's add a file. For now, let's just add the following code to it:

      We need to add a file under the folder to hold the for our app. Let's add the following code to it:

      Let's edit the so it includes the urls in , like so:

      Finally, we need to create our view. Let's edit the as follows:

      If everything goes well, you should see the screen below on your browser once you run your django server.

      tumbling programmer's django project boilerplate home page

      You may have noticed that we have some classes in our file (like , or . They don't render properly at the moment because we haven't completely setup . We'll do that later.

      For now, let's commit and call our commitment .

      Our layout at the moment should look as follows:

      So far we have installed on our virtual environment, but we haven't told django about it. We will do so shortly, and while at it, we will also add other settings that will enable to work properly. Let's go ahead and edit the file as follows:

      I tend to put settings toward the end of the file. Note that you don't have to have all the above settings in the file.

      A couple of things worth noting about the above settings:

      1. Per the documentation, the default setting for is , which points to an old version of . points to a newer one, which is what we have used on our boilerplate.
      2. The setting points to the theme that will use. is the default. Bootswatch features quite a few, including readable, which is the one I use on

      You can find out more about here.

      should be good to go. To fully take advantage of it, let's add a base template that inherits from base template.

      The base template

      Let's add a file directly under the folder, and let's add the following code to it:

      Now let's edit the template so it reads as follows:

      If we run our django server and hit the home page, we should see the following:

      tumbling programmer's django project boilerplate bootstrapped home page

      As you can see, works properly.

      Let's commit and call our commitment .

      Linking our static files

      Let's edit as follows:

      If you examine the code in , we had a class called there. When django rendered the page, the text wasn't centered because the is not "seen" by , yet.

      Let's edit the file as follows:

      If we link the file properly, we should see an alert generated by javascript as soon as the page loads. The final step to link our static files is to introduce , the following block of code

      and to the code within , which should now read as follows:

      If we run our django server, we should get the following, which show that we have successfully linked and , and that they are ready to receive and serve code.

      tumbling programmer's django project boilerplate home page with javascript working

      Our class in now works.

      tumbling programmer's django project boilerplate home page with css working

      Let's go ahead and comment out line in our file (you can later use this line to further test your environment and to make sure that things are working properly, if in doubt).

      Let's commit and call our commitment .

      Getting up and running

      (more info here watches for changes on the files that make up your app, including , , , and django files. Once it catches the changes, it reloads your browser automatically so you don't have to constantly hit reload on it.

      First, let's install it. As usual, we will follow the workflow that we described under section _Distinguishing between django, local, and third party applications_. This will be a local only package, and we are starting with a fresh commitment.

      With our virtual environment activated, let's run .

      On the terminal, let's navigate into our folder and run . A on the file will tell us that the following lines were added to it:

      Let's add them to our file, which now should read as follows:

      Notice how I placed on top, by which I signify that the bottom two are required by . It's just a convention I use. When you install the requirements from a file, the order in which they are placed shouldn't really matter (unless there were conflicts between required packages).

      Let's edit our file so it reads as follows:

      Stop your django server if it's running, run (leave it running), and on another terminal tab, run your django server. Open your home page on your browser. Keep your browser visible.

      Let's open our file and add the following block of code right below the :

      As soon as you save the changes on your file, you should automatically see the changes on your browser, which should look as follows:

      tumbling programmer's django project boilerplate home page livereload demo

      Let's commit and call the commitment .

      Getting up and running

      I usually find myself needing more icons than what twitter bootstrap's glyphicons offer. django-fontawesome comes to the rescue.

      This package will go into the requirements file.

      As usual, we activate our virtual environment (if not already activated), and run . will install it, along with , which is required by .

      Once we update it, our should read as follows:

      Let's edit our file, as follows:

      Now we need to add to our file, like so:

      In our file, let's add and some html to test that the installation works, like so:

      If everything goes well, our home page will show the following at the bottom of it:

      tumbling programmer's django project boilerplate home page with font awesome

      Let's commit and call our commitment .

      Creating our

      Let's add one handy model to our app models. Edit so it reads as follows:

      As the comment above explains, if we were to extend this model (as in ), the "extension" model (, in our example) will automatically have the fields and . Handy indeed. We could use the same approach if, for instance, we had models that had address fields in common. In general, we look for common denominators, throw those denominators into a base model, and extend that base model as needed.

      At this point, we don't need to make migrations or migrate because we have used the statement (more info on that here.

      Let's commit and call our commitment .

      Serving and files

      We still have homework to do to finish off serving of media and static files.

      Let's edit our file and add to our list of context processors in file, like so:

      Let's also edit our file from:


      Also, let's edit our file as follows:

      Adding to our list of context processors in our file is what makes possible to use the dynamic url to serve media files.

      If all goes well, you should see the below info at the bottom of your home page:

      tumbling programmer's django project boilerplate home page with static and media files

      Let's commit and call our commitment .

      and png files

      By default, my file includes (and other image extensions, for that matter) so they stay out of version control. I realized, though, that I need to include them in the repository, so readers get everything that is needed to follow the tutorial. So, I excluded the files from the git file, and committed the changes; I called the commitment . Below is what got committed:

      Adding error pages

      We need to add html templates to let users know that errors have occurred. Under the folder, add the following files; the respective code for each is listed following the file name.




      Let's commit and call our commitment .

      The resulting layout

      Below is what the resulting layout looks like:

      At a high level

      All the gory details

      Where to take it from here

      Although extensive, this tutorial covered only a fraction of all that is required to have a ready-to-be-deployed django project boilerplate. Issues like testing, cron jobs, python helpers / utilities, user registration, the django debug toolbar, further security considerations, as well as others that will come along the way, may be worth studying and implementing, depending on the application's needs.

      As far as deployment, that's the next article that I will write. Stay tuned.


      How to use it

      The open-source version, released under MIT license can be used wthout any constraints for hobby or comercial projects. The source code and documentation contain enough information to help anyone building the app.
      In case you want to build this Django Boilerplate, without leaving this page, just type:

      If all goes well, the Django Boilerplate can be tested with POSTMAN on port 3000.
      This product is actively supported via Email and 24/7 Live support on Discord (for paid plans)
      Thank you!


      You will also be interested:


      1167 1168 1169 1170 1171