0) В базовый, не в базовый (наследующий базовый), это не важно. Важно то, как именно передать в шаблон. В базовый шаблон никакой контекст не передаётся. Базовый шаблон просто расширяет ваш шаблон, а контект там один.
UPD: Я не сразу углядел. У вас отедльная моделька для профиля, привязанная к пользователю.
Надо сделать в модели свойство, которое будет отдавать профиль для этого пользователя. Если сможете, то вопрос решен и будет работать как в примере выше. Если нет, то проще всего добавить context processor и отдавать переменную profile. Работать будет как-то так: {{ profile.get_absolute_url }}. Но лучше всего, конечно, определить в модели User свойство profile.
2) Если штатный request.user не подходит (почему!?), или вы хотите понять принцип на будущее, то есть два похожих варианта:
2.1) Передавать ваш объект в контекст конкретного шаблона из вьюхи. Будет работать только в этой вьюхе. Банально, да?
2.2) Написать context processor и добавить его в settings.TEMPLATES.OPTIONS.context_processors (см то, как это сделано в базовом settings.py и гугли примеры). Будет работать вообще везде в рамках рендера шаблонов. Мы не ищем лёгких путей для request.user!
Вадим Шаталов предлагает использовать фильтры/тэги. Это не совсем то (не совсем об этом), потому что в них всё равно надо будет или передавать request.user, или брать из контекста, куда его надо будет помещать одним из вышеописанных способов, или как-то его нечеловеческим образом откуда-то доставать, чего делать уже совсем не нужно.
Блок в блоке работать, конечно, должен.
Если у вас эта форма site-wide, то не надо её переопределять на уровне подшаблона. Её место на уровне base.html.
Пойдём последовательно: сам по себе {% include "partials/footer.html" %} импортируется?
1) Тип скрипта, который будет отправлять на сервер не очень важен, можно хоть через curl это делать.
2) Можно обрабатывать форму, да. Там могут быть проблемы с CSRF и с этим надо будет что-то делать. Можно подключить DRF, есть всё что нужно, но само освоение DRF нетривиально. DRF для подобных операций — самый правильный вариант. Может, найдёте готовый пример. Там надо создать endpoint, назначить переменные для принимания файлов и, собственно, принимать и обрабатывать. Проблема в том, что DRF сломает вам мозг раньше, чем сервер ответит 200 OK.
3) При помощи закачивающего скрипта сделать непосредственную запись в БД можно только имея доступ к БД. Но это такие костыли, шо пипец.
4) Если скрипт и django-проект находятся на одной машине, то можно запускать этот скрипт в контексте django прямо через manage.py и делать всё прямо в нём (https://docs.djangoproject.com/en/2.2/howto/custom... В этом случае этот скрипт будет частью проекта. Файло никуда не надо будет передавать, а сохранять локально, предварительно разобравшись в том, как это работает в рамках MEDIA https://docs.djangoproject.com/en/2.2/topics/files/ и далее по пунктам со всеми остановками). Это хороший вариант.
Артем Шишков, ImageFeild работает как? У него есть параметр upload_to, который определяется относительно MEDIA_URL на урлах и MEDIA_ROOT на файловой системе. Т.е. файлик положится на диск и через /media/ будет доступен. В шаблоне нужно сказать что-то типа {{ instance.img.url }} и получится готовый путь до файла.
В поисковиках есть куча примеров.
Отладка в два этапа.
1) Проверяем, что на диске файл кладётся туда, куда предполагается.
2) Файлик доступен через url.
Артем Шишков, плохо так делать. Слишком сложно. Где-то в логике проектирования ошибка.
Загружать файло лучше в media и раздавать оттуда же. static не для этого.
MisterN, это только в вашей фантазии я прыгаю на грабли. Холивары меня не интересуют, я в них участвовать не буду. В рамках этого сайта их быть не может. Да и в целом мне плевать. Это только в вашей фантазии те, кто не хочет холивара будет или не будет что-то делать. Всё проще. Пришел, высказался. По необходимости обосновал, понимая, что единой истины нет, да и не нужна она никому. Если у вас от этого пригорает, то я Вам сочувствую. Это вам надо спокойнее относиться к этим вопросам. Особенно, с высоты Вашего опыта.
Проблема может быть в чём угодно. Мало информации.
1) Закачивается ли картинка на диск? Вы проверяли?
2) Каким образом вы её показываете? <img src="тут что?"/>
3) Настроен ли у вас показ /media/ и если да, то правильно ли? Вы проверяли?
joli, это риторический вопрос. :) Вы сами проектируете этот функционал. Настройки (обычно) лежат в одном месте, так удобнее. Но в этом случае, возможно, удобнее, чтобы эта настройка была ближе к приложению, которое его использует.
Поэтому условный выбор между from django.conf import settings
и from myshop.settings import CART_SESSION_ID
за вами.
joli, судя по всему, это просто глобальная переменная, обозначающая единое для всех пользователей наименование сессии, в которой у вас хранятся данные.
Видимо, переменная устанавливается в settings.py и импортируется во вьюху. Не более того. Для удобства.
1) Если корзина по прямой ссылке доступна, значит дело в перенаправлении или раньше.
2) Возможно, дело в отсутствующем '/': path('/', views.cart_detail, name='cart_detail'),
но это не точно
Mike, нуууу… Если бы я был питоном, то я бы страшно ругался и нихрена не понимал. :)
— created = … Шта? вы передаёте created в create_user_profil и переопределяете его?!
— Оступ
— level_id=id —что за id?
— defaults= — это что?! В модели UserLevel такого нет
level не может быть пустым и ему какое значение присвоится? Но это детали. Как создать экземпляр UserLevel, думаю, вы разберётесь.
