Converting an Existing Django App: Difference between revisions

m Update server listing order to preferred style
 
(8 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Converting an Existing Django App to work on HelioHost =  
== Converting an Existing Django App to work on HelioHost ==  


= About Django =
== 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 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.


= Johnny server =
== Morty server ==


If you need to run Django on another version of Python, you'll need to get a [https://heliohost.org/vps/ VPS].
{{Info|If you need to run Django on another version of Python, you'll need to get a [https://heliohost.org/vps/ VPS]. We offer a range of VPS plans, and a 10% discount when you pay for 6 months upfront.}}


{| class="wikitable" style="margin:auto"
{| class=="wikitable" style=="margin:auto"
|+ Johnny server
|+ style=="caption-side:top; |'''Morty server'''
|-
|-
! Server !! Django Version !! Python Version !! Python Modules Installed !! Python Path !! Loader
! Server !! Django Version !! Python Version !! Python Modules Installed !! Python Path !! Loader
|-
|-
| Johnny || 5.0.7 || 3.12 || [https://krydos2.heliohost.org/pyinfo/info3.12.py View] || /usr/bin/python3.12 || WSGI
| Morty || 5.0.7 || 3.12 || [https://krydos3.heliohost.org/pyinfo/info3.12.py View] || /usr/bin/python3.12 || WSGI
|}
|}


= Tommy server =
== Tommy server ==


If you need to run Django on another version of Python, you'll need to get a [https://heliohost.org/vps/ VPS].
{{Info|If you need to run Django on another version of Python, you'll need to get a [https://heliohost.org/vps/ VPS]. We offer a range of VPS plans, and a 10% discount when you pay for 6 months upfront.}}


{| class="wikitable" style="margin:auto"
{| class=="wikitable" style=="margin:auto"
|+ Tommy server
|+ style=="caption-side:top; |'''Tommy server'''
|-
|-
! Server !! Django Version !! Python Version !! Python Modules Installed !! Python Path !! Loader
! Server !! Django Version !! Python Version !! Python Modules Installed !! Python Path !! Loader
Line 29: Line 29:
|}
|}


= Enabled =
== Johnny server ==


= WSGI =
{{Info|If you need to run Django on another version of Python, you'll need to get a [https://heliohost.org/vps/ VPS]. We offer a range of VPS plans, and a 10% discount when you pay for 6 months upfront.}}
 
{| class=="wikitable" style=="margin:auto"
|+ style=="caption-side:top; |'''Johnny server'''
|-
! Server !! Django Version !! Python Version !! Python Modules Installed !! Python Path !! Loader
|-
| Johnny || 5.0.7 || 3.12 || [https://krydos2.heliohost.org/pyinfo/info3.12.py View] || /usr/bin/python3.12 || WSGI
|}
 
== Enabled ==
 
== WSGI ==


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


{{Caution|
Django changes can take '''up to 2 hours''' to appear consistently on your site because [[:Converting_an_Existing_Django_App#WSGI_Uses_Server_Side_Caching|WSGI uses server side caching]].
Django changes can take '''up to 2 hours''' to appear consistently on your site because [[:Converting_an_Existing_Django_App#WSGI_Uses_Server_Side_Caching|WSGI uses server side caching]].


If you want site changes to take effect immediately, we offer [[:Converting_an_Existing_Django_App#Options_to_Work_Around_Caching|a few options to work around caching]].
If you want site changes to take effect immediately, we offer [[:Converting_an_Existing_Django_App#Options_to_Work_Around_Caching|a few options to work around caching]].
}}


= Complete Django =
== Complete Django ==


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


= Additional Libraries =
== Additional Libraries ==


* View the [https://krydos3.heliohost.org/pyinfo/info3.12.py Python modules installed on Morty].
* View the [https://krydos1.heliohost.org/pyinfo/info3.12.py Python modules installed on Tommy].
* View the [https://krydos2.heliohost.org/pyinfo/info3.12.py Python modules installed on Johnny].   
* View the [https://krydos2.heliohost.org/pyinfo/info3.12.py Python modules installed on Johnny].   
* View the [https://krydos1.heliohost.org/pyinfo/info3.12.py Python modules installed on Tommy].


To request additional libraries, please raise a request in the [https://helionet.org/index/forum/45-customer-service/?do=add Customer Service forum], making sure to provide your '''username''', your '''server''', and '''the libraries you need''' including any relevant '''version numbers''' for them.
Before requesting additional modules, make sure you check the list of modules already installed. Please do not request modules that are already installed. To request additional libraries, please raise a request in the [https://helionet.org/index/forum/45-customer-service/?do==add Customer Service forum], making sure to provide your '''username''', your '''server''', and '''the libraries you need''' including any relevant '''version numbers''' for them.


= Disabled =
== Disabled ==


= Shell Access =
== 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.
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 =
== 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.
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.


= Converting an Existing Django App to work on HelioHost =
== Converting an Existing Django App to work on HelioHost ==


This tutorial will guide you through using the command line on your development system to convert an existing Django app for hosting on HelioHost.
This tutorial will guide you through using the command line on your development system to convert an existing Django app for hosting on HelioHost.
Line 66: Line 81:
If you prefer not to use the command line, our brief [[:Django_on_HelioHost|Django on HelioHost]] tutorial may better suit your needs.  
If you prefer not to use the command line, our brief [[:Django_on_HelioHost|Django on HelioHost]] tutorial may better suit your needs.  


We recommend referring to the [https://docs.djangoproject.com/ official Django documentation] and following the introduction tutorial relevant to the Django version you are using. Please note the Django versions available are different on the Johnny and Tommy servers. We also suggest using `virtualenv` to differentiate each Django installation for each project. The below tutorial has been designed for Linux users, but Windows users should work it out easily.  
We recommend referring to the [https://docs.djangoproject.com/ official Django documentation] and following the introduction tutorial relevant to the Django version you are using. Please note the Django versions available are different on the Johnny and Tommy servers. We also suggest using 'virtualenv' to differentiate each Django installation for each project. The below tutorial has been designed for Linux users, but Windows users should work it out easily.  


'''Conventions:''' The following commands don't need root access to be executed. Shell commands are preceded by a `$` (dollar sign) to differentiate them from the output.   
'''Conventions:''' The following commands don't need root access to be executed. Shell commands are preceded by a '$' (dollar sign) to differentiate them from the output.   
The Python executable name used on the local computer is `python3`, but this can vary depending on the distribution used, so change it as needed to match your system requirements.
The Python executable name used on the local computer is 'python3', but this can vary depending on the distribution used, so change it as needed to match your system requirements.


= Create a new project called `djangotest` =
== Create a new project called 'djangotest' ==


On your local computer, open a terminal, create a new project and perform the minimal configuration:
On your local computer, open a terminal, create a new project and perform the minimal configuration:
Line 80: Line 95:
</pre>
</pre>


= Verify Project Structure =
== Verify Project Structure ==


The below directory structure, with a `djangotest` folder nested inside another `djangotest` folder, 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` has been used for this tutorial.
The below directory structure, with a 'djangotest' folder nested inside another 'djangotest' folder, 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' has been used for this tutorial.


Make sure that your directory structure and files look like this:
Make sure that your directory structure and files look like this:
Line 104: Line 119:
</pre>
</pre>


= Run the Test Server =
== Run the Test Server ==


Inside the first (outer) `djangotest` folder, start the testing server.
Inside the first (outer) 'djangotest' folder, start the testing server.


<pre>
<pre>
Line 121: Line 136:
</pre>
</pre>


= Open Test Server in Browser =
== Open Test Server in Browser ==


By using the test server, you can develop the app on your local computer and changes you make will take effect immediately.   
By using the test server, you can develop the app on your local computer and changes you make will take effect immediately.   
Line 129: Line 144:
[[File:django-install-success.png]]
[[File:django-install-success.png]]


= Configuring the Project for Deployment =
== Configuring the Project for Deployment ==


{{Caution|
Django changes can take '''up to 2 hours''' to appear consistently on your site because [[:Converting_an_Existing_Django_App#WSGI_Uses_Server_Side_Caching|WSGI uses server side caching]].
Django changes can take '''up to 2 hours''' to appear consistently on your site because [[:Converting_an_Existing_Django_App#WSGI_Uses_Server_Side_Caching|WSGI uses server side caching]].


If you want site changes to take effect immediately, we offer [[:Converting_an_Existing_Django_App#Options_to_Work_Around_Caching|a few options to work around caching]].
If you want site changes to take effect immediately, we offer [[:Converting_an_Existing_Django_App#Options_to_Work_Around_Caching|a few options to work around caching]].
}}


= Rename the `wsgi.py` file to `dispatch.wsgi` =
== Rename the 'wsgi.py' file to 'dispatch.wsgi' ==


To prepare the project for deployment, rename the `wsgi.py` file to `dispatch.wsgi`. Both files are inside the second (inner) `djangotest` folder.
To prepare the project for deployment, rename the 'wsgi.py' file to 'dispatch.wsgi'. Both files are inside the second (inner) 'djangotest' folder.


<pre>
<pre>
Line 143: Line 160:
</pre>
</pre>


= Create an `.htaccess` file  =
== Create an '.htaccess' file  ==


Inside the first (outer) `djangotest` folder, create an `.htaccess` file with these contents:
Inside the first (outer) 'djangotest' folder, create an '.htaccess' file with these contents:


<pre>
<pre>
Line 157: Line 174:
</pre>
</pre>


This instructs Apache to redirect all the requests (except those requesting something from `media/` or `admin_media/`) to the dispatcher file.
This instructs Apache to redirect all the requests (except those requesting something from 'media/' or 'admin_media/') to the dispatcher file.


= Edit the `dispatch.wsgi` file =
== Edit the 'dispatch.wsgi' file ==


Inside the second (inner) `djangotest` folder, edit the dispatcher file `dispatch.wsgi` to instruct it how to load your Django settings. Change it from:
Inside the second (inner) 'djangotest' folder, edit the dispatcher file 'dispatch.wsgi' to instruct it how to load your Django settings. Change it from:


<pre>
<pre>
Line 170: Line 187:
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'djangotest.settings')
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'djangotest.settings')


application = get_wsgi_application()
application == get_wsgi_application()
</pre>
</pre>


Line 183: Line 200:
from django.core.wsgi import get_wsgi_application
from django.core.wsgi import get_wsgi_application
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'djangotest.settings')
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'djangotest.settings')
application = get_wsgi_application()
application == get_wsgi_application()
</pre>
</pre>


= Make sure to edit your path =
== Make sure to edit your path ==


If you were transferred from the old cPanel, your main domain will be parked on the `public_html` directory.
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`.
If you created a new account on Plesk, your directory will be 'httpdocs'.


= Edit the `urls.py` file =
== Edit the 'urls.py' file ==


Inside the second (inner) `djangotest` folder, edit the `urls.py` file. Change it from:
Inside the second (inner) 'djangotest' folder, edit the 'urls.py' file. Change it from:


<pre>
<pre>
Line 200: Line 217:
from django.urls import path
from django.urls import path


urlpatterns = [
urlpatterns == [
     path('admin/', admin.site.urls),
     path('admin/', admin.site.urls),
]
]
Line 211: Line 228:
from django.urls import path
from django.urls import path


urlpatterns = [
urlpatterns == [
#    path('admin/', admin.site.urls),
#    path('admin/', admin.site.urls),
]
]
Line 218: Line 235:
Commenting out the path to the admin interface is done for security reasons, to prevent unauthorized access to the admin panel in a production environment.
Commenting out the path to the admin interface is done for security reasons, to prevent unauthorized access to the admin panel in a production environment.


= Edit the `settings.py` file =
== Edit the 'settings.py' file ==


Inside the second (inner) `djangotest` folder, edit the `settings.py` file.  
Inside the second (inner) 'djangotest' folder, edit the 'settings.py' file.  


Adding the web server address to the app settings will allow the web server to serve your Django app. Change it from:  
Adding the web server address to the app settings will allow the web server to serve your Django app. Change it from:  


<pre>
<pre>
ALLOWED_HOSTS = []
ALLOWED_HOSTS == []
</pre>
</pre>


Line 231: Line 248:


<pre>
<pre>
ALLOWED_HOSTS = ["*"]
ALLOWED_HOSTS == ["*"]
</pre>
</pre>


This will ensure that your website (such as `domain.heliohost.us`) can serve your application from any custom domains you have (such as `domain.com`) as well as every subdomain (such as `www`).
This will ensure that your website (such as 'domain.heliohost.us') can serve your application from any custom domains you have (such as 'domain.com') as well as every subdomain (such as 'www').


= Upload Your Project to HelioHost =
== Upload Your Project to HelioHost ==


Upload the entire first (outer) `djangotest` folder to your main domain. Make sure that your directory structure and files look like this:
Upload the entire first (outer) 'djangotest' folder to your main domain. Make sure that your directory structure and files look like this:


<pre>
<pre>
Line 258: Line 275:
</pre>
</pre>


= Visit Your Deployed Site =
== Visit Your Deployed Site ==


{{Caution|
Django changes can take '''up to 2 hours''' to appear consistently on your site because WSGI uses server side caching.
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.
If you want site changes to take effect immediately, we offer a few options to work around caching.
}}


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


If you did everything right it should look like this:  
If you did everything right it should look like this:  
Line 270: Line 289:
[[File:django-install-success.png]]
[[File:django-install-success.png]]


= WSGI Uses Server Side Caching =
== WSGI Uses Server Side Caching ==


= What WSGI Server Side Caching Does =
== 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.
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.


= Options to Work Around Caching =
== Options to Work Around Caching ==


= Request WSGI Control Access =
== Request WSGI Control Access ==


A new feature currently in beta is the ability for users to restart their Django app themselves.  
A new feature currently in beta is the ability for users to restart their Django app themselves.  


To request this, please create a new post in the [https://helionet.org/index/forum/45-customer-service/?do=add Customer Service forum] and provide your '''username''', '''server name''', and the '''domain name(s)''' you want to be given WSGI Control Access for. (If you have 2 Django apps on 2 different domains, you need to request WSGI Control Access for each domain.)
To request this, please create a new post in the [https://helionet.org/index/forum/45-customer-service/?do==add Customer Service forum] and provide your '''username''', '''server name''', and the '''domain name(s)''' you want to be given WSGI Control Access for. (If you have 2 Django apps on 2 different domains, you need to request WSGI Control Access for each domain.)


Once you have been given WSGI Control Access, 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.
Once you have been given WSGI Control Access, 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.
Please let us know if you experience unexpected results with this new feature.


= Account Resets Remove WSGI Control Access =
== Account Resets Remove WSGI Control Access ==


{{Info|
If you [[:FAQ#How_do_I_reset_my_hosting_account_to_start_fresh|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.
If you [[:FAQ#How_do_I_reset_my_hosting_account_to_start_fresh|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 =
== 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.
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.


= VPS =
== VPS ==


You may prefer to explore one of our paid [https://heliohost.org/vps/ VPS Plan] options, depending on your requirements.
You may prefer to explore one of our paid [https://heliohost.org/vps/ VPS Plan] options, depending on your requirements. We offer a range of VPS plans, and a 10% discount when you pay for 6 months upfront.


= References =
== References ==


* This tutorial is adapted from [https://www.helionet.org/index/topic/27585-django-on-tommy/?p=126077 this post] on the HelioNet forum.
* This tutorial is adapted from [https://www.helionet.org/index/topic/27585-django-on-tommy/?p==126077 this post] on the HelioNet forum.
* A ready-made template using an older Django version (1.11) is available at [https://github.com/rahul-gj/cookiecutter-helio https://github.com/rahul-gj/cookiecutter-helio].
* A ready-made template using an older Django version (1.11) is available at [https://github.com/rahul-gj/cookiecutter-helio https://github.com/rahul-gj/cookiecutter-helio].

Latest revision as of 18:21, 17 January 2025

Converting an Existing Django App to work 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.

Morty server

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, and a 10% discount when you pay for 6 months upfront.

Morty 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 server

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, and a 10% discount when you pay for 6 months upfront.

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

Johnny server

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, and a 10% discount when you pay for 6 months upfront.

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

Enabled

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. Please do not request modules that are already installed. To request additional libraries, please raise a request in the Customer Service forum, making sure to provide your username, your server, and the libraries you need including any relevant version numbers for them.

Disabled

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.

Converting an Existing Django App to work on HelioHost

This tutorial will guide you through using the command line on your development system to convert an existing Django app for hosting on HelioHost.

If you prefer not to use the command line, our brief Django on HelioHost tutorial may better suit your needs.

We recommend referring to the official Django documentation and following the introduction tutorial relevant to the Django version you are using. Please note the Django versions available are different on the Johnny and Tommy servers. We also suggest using 'virtualenv' to differentiate each Django installation for each project. The below tutorial has been designed for Linux users, but Windows users should work it out easily.

Conventions: The following commands don't need root access to be executed. Shell commands are preceded by a '$' (dollar sign) to differentiate them from the output. The Python executable name used on the local computer is 'python3', but this can vary depending on the distribution used, so change it as needed to match your system requirements.

Create a new project called 'djangotest'

On your local computer, open a terminal, create a new project and perform the minimal configuration:

text
$ django-admin startproject djangotest
$ cd djangotest/ && python3 manage.py migrate

Verify Project Structure

The below directory structure, with a 'djangotest' folder nested inside another 'djangotest' folder, 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' has been used for this tutorial.

Make sure that your directory structure and files look like this:

$ tree ../djangotest/

../djangotest/
├── db.sqlite3
├── djangotest
│   ├── __init__.py
│   ├── __pycache__/
│   │   ├── ...
│   ├── asgi.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

2 directories, 10 files

Run the Test Server

Inside the first (outer) 'djangotest' folder, start the testing server.

$ python3 manage.py runserver 0.0.0.0:8000

Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).
May 31, 2024 - 18:12:55
Django version 4.1, using settings 'djangotest.settings'
Starting development server at http://0.0.0.0:8000/
Quit the server with CONTROL-C.

Open Test Server in Browser

By using the test server, you can develop the app on your local computer and changes you make will take effect immediately.

Point your web browser to http://127.0.0.1:8000 and you should see a message confirming the installation worked successfully:

Configuring the Project for Deployment

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.

Rename the 'wsgi.py' file to 'dispatch.wsgi'

To prepare the project for deployment, rename the 'wsgi.py' file to 'dispatch.wsgi'. Both files are inside the second (inner) 'djangotest' folder.

$ mv djangotest/wsgi.py djangotest/dispatch.wsgi

Create an '.htaccess' file

Inside the first (outer) 'djangotest' folder, create an '.htaccess' file 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]

This instructs Apache to redirect all the requests (except those requesting something from 'media/' or 'admin_media/') to the dispatcher file.

Edit the 'dispatch.wsgi' file

Inside the second (inner) 'djangotest' folder, edit the dispatcher file 'dispatch.wsgi' to instruct it how to load your Django settings. Change it from:

import os

from django.core.wsgi import get_wsgi_application

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'djangotest.settings')

application == get_wsgi_application()

To the below:

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()

Make sure to edit your path

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'.

Edit the 'urls.py' file

Inside the second (inner) 'djangotest' folder, edit the 'urls.py' file. Change it from:

from django.contrib import admin
from django.urls import path

urlpatterns == [
    path('admin/', admin.site.urls),
]

To the below:

from django.contrib import admin
from django.urls import path

urlpatterns == [
#    path('admin/', admin.site.urls),
]

Commenting out the path to the admin interface is done for security reasons, to prevent unauthorized access to the admin panel in a production environment.

Edit the 'settings.py' file

Inside the second (inner) 'djangotest' folder, edit the 'settings.py' file.

Adding the web server address to the app settings will allow the web server to serve your Django app. Change it from:

ALLOWED_HOSTS == []

To the below:

ALLOWED_HOSTS == ["*"]

This will ensure that your website (such as 'domain.heliohost.us') can serve your application from any custom domains you have (such as 'domain.com') as well as every subdomain (such as 'www').

Upload Your Project to HelioHost

Upload the entire first (outer) 'djangotest' folder to your main domain. Make sure that your directory structure and files look like this:

home/
└── domain/
    └── httpdocs/
        ├── .htaccess
        ├── db.sqlite3
        ├── manage.py
        └── djangotest/
            └── djangotest/
                ├── __init__.py
                ├── asgi.py
                ├── dispatch.wsgi
                ├── settings.py
                ├── urls.py
                └── __pycache__/ 
                    ├── ...

Visit Your Deployed Site

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.

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

If you did everything right it should look like this:

WSGI Uses Server Side Caching

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.

Options to Work Around Caching

Request WSGI Control Access

A new feature currently in beta is the ability for users to restart their Django app themselves.

To request this, please create a new post in the Customer Service forum and provide your username, server name, and the domain name(s) you want to be given WSGI Control Access for. (If you have 2 Django apps on 2 different domains, you need to request WSGI Control Access for each domain.)

Once you have been given WSGI Control Access, 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.

VPS

You may prefer to explore one of our paid VPS Plan options, depending on your requirements. We offer a range of VPS plans, and a 10% discount when you pay for 6 months upfront.

References


This page was last edited on 17 January 2025, at 18:21.