Django on HelioHost

About Django

Django is a web development framework designed specifically for Python. As Ruby on Rails does for Ruby, Django aims to provide an MVC (Model-View-Controller) architecture for web application development as well as a large set of prebuilt libraries to simplify the development of common web app features. Django's modularity also allows easy scalability and enables the reuse of various code blocks, aligning to the DRY ("Don't Repeat Yourself") software development principle.

Django Versions Available

To check if a module is already installed, use the View link for the server and Python version of your choice, and then press Ctrl + F to search the page for a module name. If there is a result, this means the module is already installed on the server.

Server	Django Version	Python Version	Python Modules Installed	Python Path	Loader
Morty	5.0.7	3.12	View	/usr/bin/python3.12	WSGI
Tommy	5.0.7	3.12	View	/usr/bin/python3.12	WSGI
Johnny	5.0.7	3.12	View	/usr/bin/python3.12	WSGI

Running Django on a Different Python Version

If you need to run Django on another version of Python, you'll need to get a VPS. We offer a range of VPS plans starting at only $4 a month, with storage options from 50 GB to 300 GB, and a 10% discount when you pay for six months upfront.

WSGI

Using the WSGI loader for a shared hosting environment is ideal because it conserves memory and enhances security.

Django changes can take up to 2 hours to appear consistently on your site because WSGI uses server side caching.

If you want site changes to take effect immediately, we offer a few options to work around caching.

Complete Django

We offer the complete, unadulterated Django package, including extensions to interface with MySQL, PostgreSQL, and SQLite database engines.

Additional Libraries

Before requesting additional modules, make sure you check the list of modules already installed.

When viewing the list of Python modules already installed, press Ctrl + F to search the page for a module name. If there is a result, this means the module is already installed on the server and you do not need to request it.

Please do not request modules that are already installed.

Server	Python Modules Installed
Morty	View
Tommy	View
Johnny	View

After you have checked the list of modules already installed, if you need to request additional libraries, please raise a request in the Customer Service forum. Make sure you provide:

1. Your account username.
2. Your server.
3. The version of Python you're using.
4. The module(s) you need, including any specific version numbers.

Shell Access

We don't offer shell (command line) access to our users. Many Django tutorials and installation instructions assume that users have command line access, which may make working with Python & Django more difficult. Most people tend to develop on their home computer and then upload to their web server, which almost negates the need for this feature. Furthermore, most configuration done through the command line can be done through other methods, such as FTP and manual file editing.

WSGI Daemon Mode

There are two ways to configure Django to work with the mod_wsgi loader in Apache. You can either create a separate daemon for each Django process (daemon mode) or embed Django into the Apache daemon (embedded mode). While daemon mode tends to be the standard among Django admins because of the increased control it offers, we use embedded mode because it can be set up on a per-user basis without very much root-level configuration. Embedded mode is slightly harder to get working (see directions below), and might break compatibility with some Django tutorials. In most cases, it should not be a problem.

Getting started with Django on HelioHost

This brief tutorial will guide you through setting up a Django test app without using the command line on your development system.

If you already have an existing Django app or prefer to use the command line, our tutorial on Converting an Existing Django App may better suit your needs.

Create a directory on your main domain called 'djangotest'.

If you were transferred from the old cPanel, your main domain will be parked on the 'public_html' directory.

If you created a new account on Plesk, your directory will be 'httpdocs'.

Create an '.htaccess' file inside the 'djangotest' directory with these contents:

Options +ExecCGI
RewriteEngine On
RewriteBase /
RewriteRule ^(media/.*)$ - [L]
RewriteRule ^(admin_media/.*)$ - [L]
RewriteRule ^(djangotest/dispatch\.wsgi/.*)$ - [L]
RewriteRule ^(.*)$ djangotest/djangotest/dispatch.wsgi/$1 [QSA,PT,L]

Create another 'djangotest' directory within the first 'djangotest' directory

This directory structure is standard for a Django project. Please note that you cannot name the project folder 'django', it will not work. This is why the name 'djangotest' is being used in this example.

Create a 'dispatch.wsgi' file inside the second 'djangotest' directory with these contents:

Update the code example, beneath where it says "edit your path below", and type in the path to your actual website address, instead of the placeholder 'domain.helioho.st' part.

On Plesk, your path is "/home/domain.helioho.st/httpdocs/djangotest"

If you were transferred from cPanel, your path is "/home/domain.helioho.st/public_html/djangotest"

import os, sys
# edit your path below
sys.path.append("/home/domain.helioho.st/httpdocs/djangotest")
from django.core.wsgi import get_wsgi_application
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'djangotest.settings')
application = get_wsgi_application()

Create a '__init__.py' file inside the second 'djangotest' directory

This file should remain empty.

Create a 'urls.py' file inside the second 'djangotest' directory with these contents:

from django.contrib import admin
from django.urls import path
urlpatterns = [
#    path('admin/', admin.site.urls),
]

Create a 'settings.py' file inside the second 'djangotest' directory with these contents:

from pathlib import Path
# Build paths inside the project like this: BASE_DIR / 'subdir'.
BASE_DIR = Path(__file__).resolve().parent.parent
# Quick-start development settings - unsuitable for production
# See https://docs.djangoproject.com/en/4.1/howto/deployment/checklist/
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = 'django-makeyoursecretbetterthanthis'
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
ALLOWED_HOSTS = ['*']
# Application definition
INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]
MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
ROOT_URLCONF = 'djangotest.urls'
TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]
WSGI_APPLICATION = 'djangotest.wsgi.application'
# Database
# https://docs.djangoproject.com/en/4.1/ref/settings/#databases
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}
# Password validation
# https://docs.djangoproject.com/en/4.1/ref/settings/#auth-password-validators
AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]
# Internationalization
# https://docs.djangoproject.com/en/4.1/topics/i18n/
LANGUAGE_CODE = 'en-us'
TIME_ZONE = 'UTC'
USE_I18N = True
USE_TZ = True
# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/4.1/howto/static-files/
STATIC_URL = 'static/'
# Default primary key field type
# https://docs.djangoproject.com/en/4.1/ref/settings/#default-auto-field
DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'

Make sure your directory structure and files look like this:

djangotest/
├── djangotest
│   ├── dispatch.wsgi
│   ├── __init__.py
│   ├── settings.py
│   └── urls.py
└── .htaccess
1 directory, 5 files

Visit Your Site

In your web browser, navigate to 'domain.helioho.st/djangotest'

If you did everything right it should look like this:

What WSGI Server Side Caching Does

Multiple Apache processes are running on the server, and each time you refresh your site you are randomly assigned to one of these processes. If that particular process has already displayed your site, it shows the cached version of your code; otherwise, it shows the new code changes. This means that during the first 2 hours after a site change, you may intermittently see old or new content, depending on which process you get assigned to. This situation will resolve when Apache is restarted, which happens every 2 hours.

Request WSGI Control Access

A new feature currently in beta on the Morty server only is the ability for users to restart their Django app themselves. Please note that this feature takes at a minimum 260 GB memory per day, which will result in a bill of $1.91 or more.

WSGI Control Access is no longer available on the Tommy and Johnny servers. Users who need WSGI Control Access can move their account to Morty using our Dashboard page for account moves.

To try to keep the cost as low as possible, users on Morty also have the option to request that WSGI Control Access be temporarily enabled it to allow for debugging. Once they have completed troubleshooting, they can request for WSGI Control Access to be disabled.

Once you have created a Django app that has a 'dispatch.wsgi' file, create a new post in the Customer Service forum. Make sure to provide:

1. Your username.
2. Confirmation that you are on the Morty server.
3. Confirmation that you have already created a 'dispatch.wsgi' file.
4. Confirmation that you understand that WSGI Control Access uses at a minimum 260 GB memory per day and your bill will probably be about $1.91 or more per month.
5. The domain name(s) for which you want WSGI Control Access. Note: If you have 2 Django apps on 2 different domains, you need to request WSGI Control Access for each domain.

Once you have confirmed your understanding of the charges involved, and been given WSGI Control Access on Morty, you can edit your 'dispatch.wsgi' to reload your Django app so new code changes load immediately. The edits to the file can be as simple as adding or removing a space or a blank line. As long as the file's 'last modified date' changes, it will discard the cache and reload your Django app.

Please let us know if you experience unexpected results with this new feature.

Account Resets Remove WSGI Control Access

If you request an account reset you will need to re-request WSGI Control Access after the reset has been completed. By default, account resets will disable WSGI Control Access.

Use Local Development Environment

Another option to see code changes reflected immediately is to develop your Django app on your home computer and then host the production copy on the server. This is a useful approach for users on the Tommy and Johnny servers, where WSGI Control Access is no longer offered.

VPS

You may prefer to upgrade to a VPS, depending on your requirements. We offer a range of VPS plans starting at only $4 a month, with storage options from 50 GB to 300 GB, and a 10% discount when you pay for six months upfront. The main advantage of the VPS over Morty is you get root SSH access, which makes Flask development even easier.

Troubleshooting

ImportError: Interpreter change detected - this module can only be loaded into one interpreter per process

If you receive an error of 'ImportError: Interpreter change detected - this module can only be loaded into one interpreter per process', this happens because we use WSGI in embedded mode to reduce load on Tommy and Johnny.

On Morty you have the option to use WSGI in daemon mode, but it uses 260 GB memory per day so you would get overage charges every day and pay about $1.91 per month.

You can also upgrade to a VPS to get rid of the error. We offer a range of VPS plans starting at only $4 a month, with storage options from 50 GB to 300 GB, and a 10% discount when you pay for six months upfront.

Further Support

If this tutorial has not worked for you, please go back and check all of your steps again to make sure you didn't miss anything. If you can't figure out what is wrong, please check your account error logs, since these will often provide information that can help you resolve the problem. If you're still stuck, please post in the Customer Service forum, making sure to provide your username and any error message(s) received.

References

This tutorial is adapted from this post.