Василий Банников

Доход приносит не сайт, а бизнес. Сайт - один из активов этого бизнеса.
Покупать соответственно нужно не "сайт", а юридическое лицо с конкретными активами.
(условно, если это какой-то сайт, который продаёт ключи от игр - надо сразу получать контакты на поставщика этих ключей и инструкции, как разгребать сбои и спорные ситуации, ибо без всего этого ты на тот же самый доход не выйдешь)
Далее уже смотреть на бухгалтерию и отчёты.

У сервиса оплаты, кроме гайдов, таки должна быть документация на api, через который его придётся интегрировать с сайтом.
Если она отсутствует - стоит посмотреть ещё раз внимательно, а потом, если реально нет, спросить в поддержке.

event calendar это называется. Есть разные библиотеки.

Домен - это просто записи в DNS.

как мне сделать на нём продукт через wordpress

Тебе ещё нужно тогда купить анонимный сервер)

Вопрос только в том, где достать и то и другое

1. С чего нам начинать разработку сайта, если большая часть контента создается через cms? С бэкенда или фронтенда?

Это пусть уже разработчики решают.
Вообще, если провести адекватную аналитику, то можно одновременно вести разработку.

2. Какой стек технологий лучше использовать под нашу ситуацию для фронтенда?

Никаких уникальных особенностей я не увидел=> каких-то особых требований для фронта нет, можно любой стек использовать.

3. Какой стек технологий лучше использовать под нашу ситуацию для бэкенда?

Аналогично п2. Это вопрос экономики, а не техники.

Сейчас мы ищем компетентных разработчиков на фронт и бэк (или одного фулстека), очень не хотим попасть в руки начинающего разраба и потом все переделывать заново.

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

Иначе вам придется научиться аналитике и менеджменту разработчиков-фрилансеров.

1. так как это не законно, тогда как они работают и их не блокируют?

Во многих странах законно. Там, где это не законно - сайты не хостят.

2. откуда берется контент для этих сайтов?

Есть очень много студий, которые профессионально снимают фильмы.
Они часто демо-версии своих "полнометражных" фильмов загружают в бесплатные разделы бесплатных сайтов.
Есть всякие любители, которые зарабатывают от партнёрки (практически как на youtube)
Есть и пиратство, когда с одного сайта на другой тырят видео.

3. как выбрать хостинг?

Нужно смотреть в политику хостинга. Многие хостинги запрещают всякие adult-проекты на их базе создавать, но есть хостинги, которые это разрешают.
+ Всегда можно купить собственные сервера, что более чем оправдано с таким количеством данных и трафика.

4. окупаемо ли это, так как есть сотни подобных сайтов?

Реклама + платная подписка.
Раз они существуют - видимо окупаемо.

1. Раз дипломная работа, а не продакшен, то совершенно не важно, что лучше/хуже.
Отказ от DRF в рамках дипломки просто из-за того что в нём нет async/await - это странное решение.

1) Нужна ли асинхронность, исходя из функций приложения?

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

Асинхронность в вебе - это большой плюс, но точно не решающий фактор.

2) Что лучше выбрать из перечисленного стека, если необходимо представить приложение в короткие сроки?

То что лучше знаешь, либо обладаешь собственной внутренней мотивацией изучить в эти самые кратчайшие сроки.

3) Исходя из функций приложения, это будет SPA (одностраничное приложение) или PWA (многостраничное приложение)?

1. PWA - Это не "многостраничное приложение". Иди гугли и снова читай, но уже внимательнее.
2. SPA и PWA ортогональны и выбирать между ними - это как выбирать между тёплым и мягким.

Исходя из функций - совершенно не важно, как вообще будет работать это приложение, SPA/PWA/SSR или вообще по классике с полной перезагрузкой.
Исходя из функций - это может быть даже полностью консольное приложение. Других требований я не вижу.

4) В случае выбора Blazor, то что лучше Blazor WebAssembly или Blazor Server?

"лучше" по какому параметру? В рамках дипломной работы - совершенно разницы нет. В рамках продакшена - надо смотреть на конкретные требования. В продакшене, скорее всего, будет использоваться гибрид с первым рендером на сервере и рантаймом уже на wasm.

5) Если возвращаться на DRF, то возможно ли создание веб приложения только на нем + фреймворк на фронте (Vue/React)?

Можно, разрешаю.

Вроде как привык, ничего критичного, но не хватает нормального терминала, например oh my zsh.

1. oh my zsh - это не терминал, а расширение для zsh, которое добавляет всякие красивости.
На Windows это есть. Если для powershell, то это oh-my-posh либо starship.rs, либо можно установить альтернативный шелл - nushell, например.

2. zsh не терминал. zsh - это шелл. На windows основным шеллом лично я бы назвал powershell core - он достаточно мощный и имеет нормальный синтаксис, в отличие от старого cmd.exe и он кроссплатформенный (если вдруг захочешь его использовать где-то ещё), в отличие от старого windows powershell.

3. А в качестве терминала на Windows сейчас используется windows terminal, который, имхо, один из лучших терминалов в принципе, а не только на винде.

Поделитесь опытом, как на windows создать удобное окружение для разработки? Что используете вы? WSL? Docker? Или еще может что можете посоветовать?

В моём случае:
1. Jetbrains-овская IDE
2. Docker или podman на твой вкус и применимость в организации. (docker desktop нельзя бесплатно в крупных организациях использовать)
3. WSL2 для докера и всего того что должно на линуксе крутиться (туда же и zsh можешь впихнуть)
4. Windows Terminal + powershell core + PSReadLine + starship для красивого и удобного терминала (вместо starship можно взять oh-my-posh)
5. Powertoys и Devtoys - просто набор всяких мелких полезных утилит, типа caffeine, полоски для запуска приложений и прочего. А devtoys - это чтобы в интернет или в консоль не лезть, чтобы что-нибудь в-из base64 переложить и всякого такого.

PS: wamp я бы не стал использовать вообще, как бы не советовали другие отвечающие.
1. apache давно надо выкинуть в помойку. Вместо него php-fpm+nginx
2. как и mysql
3. php требует доустановки целой кучи пакетов, так что пусть живёт в отдельном docker-контейнере
4. w отсюда тоже следует убрать, так как очень врядли у тебя на проде тоже будет винда.

Есть паттерн такой "backend for frontend" - вот тебе нужно сделать как раз его.
Отдели ту часть, которая делает SSR в отдельный проект, а те места, где идёт обращение к бизнес-логике замени на вызовы твоего web api.

Соответственно тебе нужно будет написать web api.

Есть база данных - в неё каким-то образом заносят данные (в данном случае о фильмах и актёрах). Потом из этой базы данных данные достаются тоже каким-то образом и вносятся в html.

В качестве базы данных может быть, например PostgreSQL - тогда мы можем достать информацию о фильмах и актёрах при помощи sql-запроса. Также нам нужен какой-то сервер, который будет с базой данных общаться. Написан он может быть в принципе на любом языке программирования (а сейчас есть даже всякие nocode платформы, где простые операции можно и без кода вообще сделать).

Более подробный ответ на этот вопрос будет уже по сути пересказом курса по разработке ПО.

Схема вполне рабочая и такой стек применяется во многих компаниях.
Никаких проблем в C#, применительно к этой задаче я не вижу.

но не будет ли возникать конфликтов в работе клиента и сервера,

Не должно. Просто разруливай по путям - что к бэку должно идти, а что на статику.

А чтобы "без порта" надо запускать на 80 и 443 порте.
Но если на этой же машине nginx стоит, то будет конфликт.