Alexander

Моё виденье.
Структуру можно сделать двух типов
1. Всё в одну модель, кроме списков(списки через связи ForeignKey/ManyToManyField/OneToOneField подгружать из других моделей или choices, они задаются администратором сайта и всегда статичны). Пускай даже будет 40 полей у модели.
2. Одна базовая, где общие данные. И куча типовых, относящихся связями к базовой модели, но имеющие свои уникальные поля. Списки так же как и в первом варианте, выносил в отдельные модели или choices.
Я бы выбрал второй вариант.

Поиск. Тут два варианта.
1. Сфинск или другие независимые поисковые программы работающие с джангой (Solr, Elasticsearch, Whoosh, Xapian).
2. Делать самой джангой и воевать за логику и ресурсы. То есть весь поиск прописывать руками, всю логику возможных вариантов.
Но я бы выбрал первый вариант, слишком много будет условий и по сути написание велосипеда. А второй вариант подходит под более "простой" тип поиска.

Есть стандартная библиотека calendar
Посмотрите в её сторону. Делал с помощью её календарь событий, куда пользователи добавляют свои объявления по дате. А в календаре отображается всё это.

import calendar
c = calendar.Calendar()

У вас related_name одноимённое. Сделайте два разных имени. Ибо на это должно тоже ругаться.
Вообще, по мимо Bad Request 400, в логе ошибки пишется ещё что-то, там должен быть ответ.

Программно, можно считать количество символов или слов. И резать по ним [:1000], [1001:2000], ...
Но тут палка двух концов. Если в базе текст хранится с html тегами, то может быть косяк. Когда тег открылся на первой странице, а закрывается на второй.

В идеале, добавить маркер или спец тег, который вы будите сами, руками вставлять в текст и по нему будет разбитие на страницы. Тогда не будет заморочек с html тегами.

В любом случае писать свой пагинатор или искать готовое решение.

1 тыкс

{% autoescape off %}{{ Post.body }}{% endautoescape %}

2 тыкс
{{ Post.body|safe }}

Но на "внедрились" мозг до сих пор ломаю. Какой смысл скрыт за этим словом? Сейчас понимаю как:
- Мне нужно чтобы выводило строку, оно её и выводит. Но хочу чтобы внедрилась.

STATIC_ROOT - дирректория где хранятся не изменяемые файлы. Как правило это вёрстка дизайна, ключи верификации и так далее. То что разработчик сайта сохранил на всегда.
MEDIA_ROOT - Дирректория пользовательских файлов. То что заливают пользователи (аватарки, текстовики/архивы), то что движок может генерировать сам (к примеру скрипт тырит картинки с другого сайта и складирует тут).

Я не понимаю откуда Django собирает эти файлы.

Есть папка, куда предварительно скидывает статичные файлы разработчик. Пути пишутся в STATICFILES_DIRS. После применения collectstatic, файлы переносятся (клонируются) в папку путь к которой указан в STATIC_ROOT.

Мой вариант (1.6.)

import os
PROJECT_PATH = os.path.abspath(os.path.dirname(__file__))
MEDIA_ROOT = os.path.join(PROJECT_PATH, "media")
MEDIA_URL = '/media/'
STATIC_ROOT = os.path.join(PROJECT_PATH, "static")
STATIC_URL = '/static/'
STATICFILES_DIRS = (
    os.path.join(PROJECT_PATH, "dev_static"),
)

И да, самое главное. Да! Складывать сразу можно, джанго не обидится. А вот в обратку, сложить в STATICFILES_DIRS и не выполнить collectstatic, а потом надеяться увидеть файлы в STATIC_ROOT, нельзя.