776166

Вариант только один — определение страны по ip, оно же geoip. Плагинов много, смотрите сами по ключевым словам.

Разобрался.

В settings.py

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTOCOL', 'https')

В nginx

proxy_set_header        X-Forwarded-Protocol  $scheme;

Проблема была в том, что в интернете пишут неточно, а помимо копипасты ещё надо иногда думать.

Всё так.
Кроме

EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'

Который отправляет почту прямиком в консоль (https://docs.djangoproject.com/en/2.2/topics/email... а не пользователю.

0) В базовый, не в базовый (наследующий базовый), это не важно. Важно то, как именно передать в шаблон. В базовый шаблон никакой контекст не передаётся. Базовый шаблон просто расширяет ваш шаблон, а контект там один.

1) В вашем случае НЕОБХОДИМО использовать штатный request.user и не парить себе мозг (https://docs.djangoproject.com/en/2.2/ref/request-...
Будет что-то типа {{ request.user.profile.get_absolute_url }}

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, или брать из контекста, куда его надо будет помещать одним из вышеописанных способов, или как-то его нечеловеческим образом откуда-то доставать, чего делать уже совсем не нужно.

Так статика не подключается идеологически и особенно так, как это сделали вы.
"./" означает, что вы отталкиваетесь от текущего расположения, что уже совсем вообще ну никак неправильно.

Нужно так:

{% load static %}
<script src="{% static "js/jquery-1.11.3.min.js" %}"></script>

https://docs.djangoproject.com/en/2.2/howto/static...

Возможно, дело в отсутствующем '/':
path('/', views.cart_detail, name='cart_detail'),
но это не точно

А

STATICFILES_DIRS = [
    os.path.join(BASE_DIR, "static"),
    '/что-тотам/vitalik/static/',

в settings.py есть и правильный?

https://docs.djangoproject.com/en/2.1/howto/static...

Лучшe не надо. Попробуйте websockets.

1) Рабочий пример чатика https://github.com/sushma-goutam/ws-chat
2) Поднимаете в контексте проекта django и интегрируете его туда, получая всё, что хотите в любых формах и количествах. (https://toster.ru/q/618375)
3) Profit.

В общем, сверху ответили. Можно пользоваться командами. Это классно и удобно. Есть батарейка для cron.
А если это совсем внешний скрипт или что-то проектно-сайтовое, но связанное, например, какой-нибудь чат или бот, то надо импортировать окружение django и лучше, что бы он крутился в виртуальном окружении проекта.

Сам импорт выглядит как-то так:

import sys, os
import django
sys.path.append('/path/to/settings/py/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
django.setup()

https://docs.djangoproject.com/en/2.1/topics/setti...

Решено. Надо было переспать ночь, перечитать и осмыслить документацию, в которой всё есть.
Делается на основе плагина.

def render(self, context, instance, placeholder):
    context.update({'instance': instance})
    return context

Вот в этот context.update({'instance': instance}) и можно засунуть, что угодно.