Дмитрий Свиридов

Попробуйте python manage.py shell

def product_list(request, category_slug=None):
    category = None
    categories = Category.objects.all()
    products = Product.objects.filter(available=True)
    page = request.GET.get('page')
    
    if category_slug:
        category = get_object_or_404(Category, slug=category_slug)
        products = products.filter(category=category)
    
    paginator = Paginator(products, 3)


    try:
        products = paginator.page(page)
    except PageNotAnInteger:
        products = paginator.page(1)
    except EmptyPage:
        products = paginator.page(paginator.num_pages)

    return render(request,
                'products/list.html',
                {'category': category,
                'categories': categories,
                'page': page,
                'products': products})

Я бы сделал приложение common, в котором хранил всякие общие шаблоны и логику. В нем "главная страница", "контакты", "о нас" и все в том духе. Там же общие модели (например, модель для изображений). Под новости и товары тоже сделал отдельные приложения, потому что по смыслу это не связанные вещи.

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

Если Вы считаете, что из базы в данном случае вытаскиваются все записи, а потом на уровне кода часть из них обрезается, то это не так. all() не делает запрос к базе. Запрос вместе с LIMIT выполняется уже внутри пагинатора.

Это я к тому, что, скорее всего, Вы увидели, что страница с пагинатором грузится безумно долго и предположили, что из базы выгребаются все записи, но это совсем не так. Долго это выполняется потому, что на таком количестве строк стандартные решения пагинации будут в принципе работать плохо, потому что на "дальних" страницах курсор базы данных будет перебирать все записи, идущие до этой страницы. Кроме того, пагинатор выполняет count-запрос, который выполняется долго, потому что это фулскан всей таблицы, где миллионы записей.

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

Для создания блога или сайта новостей на Django тебе при любом раскладе потребуется, как минимум, virtualenv и pip. Потому что у любого проекта есть зависимости. Тот же фреймворк Django - это тоже зависимость. По ходу разработки ты только одним Django, кстати, тоже не обойдешься - придется некоторые библиотеки использовать в зависимости от твоих задач. Например, очень пригодится django-debug-toolbar. Так что то, что тебе пишут, что для простого блога, кроме Django, ничего совсем уж не нужно - не совсем правда.

Зачем Django когда есть Wordpress - ответ: потому что Python!

Кстати, если тебе хочется что-то среднее между фреймворком и Вордпрессом, но при этом чтобы был питон, а не php, то погляди в сторону Wagtail CMS. Это CMS, написанная с использованием Django, но она, в отличие от Вордпресса, больше с уклоном в самостоятельное программирование на ее основе.

Самый простой способ - это не считать количество для каждого юзера каждый раз, а при создании/удалении юзером своей записи один раз считать количество его записей и обновлять его значение в поле в таблице пользователей. То есть в таблице с пользователями у тебя будет поле posts_count, в котором будет храниться количество постов юзера) - и просто по нему делай сортировку. Это и проще, и быстрее работать будет.

А если делать через метод get_posts_count, то для отображения списка пользователей с количеством их постов на странице, у тебя к базе будет сделано N запросов для подсчета количества, где N - это число пользователей которые будут отображены на странице, что совсем не оптимально.

Но если уж хочется не делать отдельное поле и считать количество одним запросом вместе с выборкой юзеров, то можно через annotate (взял из доки):

>>> from django.db.models import Count
>>> q = Book.objects.annotate(Count('authors'))
# Interrogate the first object in the queryset
>>> q[0]
<Book: The Definitive Guide to Django>
>>> q[0].authors__count
2

Можно, но если тебе потребуется реализовать связь m2m (например, принадлежность постов нескольким группам), то тебе придется в таблице-связке этот слаг дублировать. Не знаю, насколько это удобно, ведь слаг может меняться вообще - и придется его менять в нескольких таблицах. Или, скажем, тебе потребуется хранить в отдельной таблице "лайки" постов. В одном случае там у тебя будет post_id, на которое будет повешен внешний ключ на поле id (pk) в таблице с постами, а в другом тебе придется опять slug прописывать. По памяти, если что, varchar больше места занимает, чем int, индексы для таких столбцов, соответственно, тоже.

Тем более, если ты в этой же таблице будешь хранить историю изменений, то тебе придется slug дублировать. Так что primay_key=True внезапно уже бы не годилось на этом поле.

Варианты такие:

1. Привязаться по IP, а с помощью cron или celery очищать записи, дата создания которых превышает 24 часа
   
2. После успешного лайка делать запись в COOKIE с id сущности, которую лайкнули. Время жизни COOKIE - 24 часа. При попытке лайкнуть делать проверку.
   
3. После успешного лайка делать запись в localStoreage с id сущности, которую лайкнули, и время. При попытке лайкнуть делать проверку.
   

Последние 2 пункта делать удобней средствами JS. Как ты понимаешь, они вообще не надежные, потому что куки и localStorage хранятся в браузере юзера и ничего не мешает их удалять.

% block aside_news_sections%}

А скобка где?