Gain insights into the Django Admin interface, learn about automatic generation, data management, custom functionalities, advanced UI customization, and explore admin rights permission management.

The Django Admin Ultimate Guide_Stripe API Integration copy.png

Django.tar.gz

django

django-lesson1

django-faker

django-rebranding

django-user-management

django-rebranding-changelist

django-migrations

django-add-view-index

empty

django-rebranding-old

In this course, you will learn the basics of the Django Admin interface, a great tool to build a powerful admin interface quickly for your Django project. 

First, you will learn how to automatically generate the admin interface for your Django models, how to populate fake data, and then search or filter data with some advice to improve performance. 

Next, you will see how to extend the functionalities of the admin interface such as adding custom fields, add intermediate pages, or creating custom actions like exporting data in CSV format.

After that, you will also explore basic and advanced UI customization such as adding charts or modifying the index page.Finally, you will have a look at the Django admin rights permission management.

The Django Admin for Web Developers

# Rebranding customization

This lesson will teach you how to rebrand the Django admin interface to attain something more modern.

To do this you need to understand how the rendering of Django Admin templates works . As you have already seen, all the default  Django templates are located on the following path:

```
<virtual_env_name>/lib/python<version_of_python>/site-packages/django/contrib/admin/templates/admin
```
The main root file is `base.html`. The second most important file is `base_site.html` which extends the `base.html` file. Any other templates will extend the `base_site.html`

Here is a summary of the main templates used based on URLs:

| **Django Url**  |  **Template used** | **Definition**  | 
|---|---|---|
|  / |  `index.html` |   Admin homepage|
|  /<app_name>/ | `app_index.html`  |  Page displayed when we click on the name of our app |
|  /<app_label>/<model_name>/ | `change_list.html`  | List of data for a model  |
|/<app_label>/<model_name>/ <pk>/change/|`change_form.html`|Page displayed when editing an instance of a model|
| <app_label>/<model_name>/ <pk>/history/ |  `object_history.html` |   Page displayed when clicking on history button in editing page (previous one)|
|<app_label>/<model_name>/|`delete_confirmation.html`|Page displayed when clicking on «delete selected» action in list page for one item only and then clicking on Go|
|<app_label>/<model_name>/|`delete_selected_confirmation.html`|Page displayed when clicking on «delete selected» action in list page for multiple items and then clicking on Go|
  

And inside the `change_list.html` template, these templates are used:

* `change_list_results.html` (to show the objects of this model)
* `actions.html` (to show the actions div which contains the default action. Delete and any other action that you may choose to define)
* `pagination.html` (for the pagination)
* `date_hierarchy.html` (only if the `date_hierarchy` is used)
* `filter.html` (only if the `list_filter` is used)
* `search_form.html` (only if the `search_fields` is used)

Inside the `change_form.html` template, these templates are used:

* `edit_inline/stacked.html` and `edit_inline/tabular.html`
* `related_widget_wrapper.html` (if an inline is used)
* `includes/fieldset.html` (if the `fieldsets` and/or `inlines` are used)
* `submit_line.html` (in order to show the bottom or top div of the Delete, Save and add another, Save and continue editing, and Save buttons)
* `prepopulated_fields_js.html` (if the `prepopulated_fields` is used)

Inside the `delete_confirmation.html` and
`delete_selected_confirmation.html` templates, the following template is used:

* `includes/object_delete_summary.html`

You will have to copy all the files from `/contrib/admin/templates/admin/` and transfer them to the `sample_app/templates/admin` folder.

```cmd
cp <virtual_env_name>/lib/python<version_of_python>/site-packages/django/contrib/admin/templates/admin/* sample_app/templates/admin
```

One important  step that needs to be taken involves modifying your `settings.py` to have your app name `sample_app` before the default `django.contrib.admin` module.

```python
INSTALLED_APPS = [
	'sample_app',
	'django.contrib.admin',
	'django.contrib.auth',
...
```
You also need to verify that you are loading the templates in your `DIRS` first.

```python
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [
	BASE_DIR,
		os.path.join(BASE_DIR, 'templates')
	],
'APP_DIRS': True,
```

Now that you have a basic understanding of how rebranding works in Django, you will be next instructed on the process of rebranding.  This will not be an easy task since you will have to modify each file to obtain our new design. You will have to copy each file you want to override in your project.



Learn the basics of admin branding customization.

Getting Started

Design Customization

Advanced Customization

Access and Rights Management

Conclusion

Admin Branding Customization

Rebranding customization