Евгений

Здесь нет никакого «правильного» подхода. Изучать фреймворк можно параллельно с изучением того, как работают «голые» сайты. Это совершенно не противоречащие друг-другу вещи и нет никакой необходимости делать это в определенном порядке. Фреймворк основан на тех же самых принципах, просто он позволяет не писать заново банальные и одинаковые вещи для каждого сайта.

У того же Django код достаточно простой в большинстве случаев, в PyCharm можно прыгать по методам и смотреть реализацию.

Вообще, рекомендую читать хорошую документацию и книги. Судя по вопросам на тостере, большинство сейчас изучает методом копипасты. Создают базовый проект, а потом добавляют в него функциональность копи-пастя нагугленные примеры, в случае ошибок бегут сюда задавать примитивные вопросы, ответы на которые есть даже в Django Tutorial.

Как минимум документацию по Django (Django Tutorial, затем все остальное) рекомендую прочитать от корки до корки. И не один раз, потому что с первого раза многое будет непонятно и забудется.

Во-первых, что у вас за serializers.serialize. Откуда этот метод или функция, и что она делает?
Во-вторых, workimage_set.all — это метод. Подозреваю, вы хотели его вызвать, для этого надо в конце написать скобки. Иначе конструкция не имеет смысла — это попытка сериализовать метод, а не результат его работы.
В-третьих, вам видимо пора переходить на использование Django Rest Framework. Это правильнее и удобнее, чем сериализовать все вручную.

Ошибка в миграциях где-то. Ответить на вопрос из озвученных исходных данных невозможно. Можно только видя весь код и базу, используя команды showmigrations, migrate --fake-initial, migrate, migrate --fake попытаться решить ситуацию.

Не надо делать один-к-одному уже лет 7-8. Django позволяет использовать свою модель пользователя черт знает с какого времени, откуда до сих пор берутся эти идеи о том, что надо делать профиили ерез один-к-одному в 2017 году?... Это надо было в первых версиях Django в 2006-2007, тогда другого способа не существовало.

Если вы нашли это на каком-то сайте в сети, пожалуйста, напишите автору, чтобы исправил информацию. Потому что регулярно здесь возникают подобные вопросы из-за того что люди не разобравшись начинают городить эти костыли и стреляют себе в ноги.

1. В модели django.contrib.auth.models.User уже есть поля first_name и last_name - дополнительные копии не принесут ясности, наоборот, рано или поздно в базе образуется бардак и будет непонятно, где настоящие имя и фамилия, и вообще неясен смысл такой денормализации
2. Непонятно, зачем вам метод save_user — он ничего не делает и абсолютно не нужен
3. Правильнее назвать поле user вместо username
4. Теоретически (зависит от ваших требований) правильнее создавать свою модель пользователя и ссылаться на нее как settings.AUTH_USER_MODEL
5. В определении полей с null=True, blank=True не нужен default — по умолчанию и так будет None
6. Странная модель, в которой все поля могут быть NULL - скорее это от непонимания
7. Для ваших целей правильнее использовать django.views.generic.edit.CreateView, django.views.generic.edit.UpdateView, и код будет короче, и даже форму можно не определять
8. В redirect написана какая-то дичь!
9. При использовании настроек по умолчанию, все view и так защищены от CSRF, нет необходимости явно писать декоратор csrf_protect

А в общем и целом, вам надо начать хотя бы с прочитения Django Tutorial. Вы явно пишете код не понимая, что пишете и зачем. Отсюда и проблемы.

Можно использовать django-treebeard или django-mptt
dajngopackages вам в помощь

Вместо

queryset.filter(brand__country__slug=request.GET.get('country'))

Надо писать:

queryset = queryset.filter(brand__country__slug=request.GET.get('country'))

Вот этого в коде быть не должно. Если вы прочитаете документацию, то увидите, что в режиме отладки эта строка не нужна.

urlpatterns += static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)

А вот эту строку желательно бы обернуть в if settings.DEBUG:, так как на production она не нужна.

urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

Вместо этого:

{% load static %}
{% load staticfiles %}

официальная документация говорит писать:
{% load static from staticfiles %}

Пользователь в шаблонах доступен как user, писать request.user необязательно, и это тоже описано в документации.

Вообще, не замечаю ошибки, проверьте, что файл у вас реально находится по заданному местоположению. И читайте документацию, более подробной документации, чем у Django нигде не видел. Там есть ответы на все вопросы, причем очень понятные и подробные.

На странице этого пакета прямо написано:

As for Dec 03 2016, this library is now deprecated

Там же написано, как мигрировать:
https://github.com/omab/python-social-auth/blob/ma...

Я бы взял django-allauth.

Я не раз видел попытки такого разделения пользователей по классам в проектах на Django. Не знаю, почему все сразу выбирают такое решение, которое в перспективе не приносит ничего, кроме боли.

Проще всего пойти стандартным путем: унаследовать пользователя от django.contrib.auth.models.AbstractUser, а различие между пользователями определять либо по группе/разрешениям, либо добавить поле в свою модель типа is_moderator. Это будет во много раз (на порядок точно) проще реализовать и поддерживать, будет совместимость со всем стандартным кодом Django и сторонними библиотеками, любому просто войти в проект и внести изменения.

Разделение на две разных модели никаких абсолютно преимуществ не дает, кроме тонны мусорного кода и головняков с поддержкой данной гидры.

TLDR:
1) Из вашего вопроса остается неясным, почему требуется разделение по разным классам. Это самый безумный вариант для разграничения полномочий, и в Django разделение полномочий пользователей уже предусмотрено по умолчанию
2) Поддерживал пару проектов с разными классами для разных классов пользователей. Поверьте, это просто ужас-ужас в поддержке, а самое главное, что он ничем не оправдан.