Алексей Уколов

Возможно. Но будет:

1) Высокая нагрузка в простое
2) Характерный свист дросселей
3) Не работать Wi-Fi

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

1. Вы можете вообще взять под контроль весь рендеринг DOM при помощи React, Vue и т.д. Но это вам надо будет серьёзно погрузиться в изучение этих фреймворков, и в классическом варианте вы потеряете поисковую оптимизацию.

2. Воспользоваться библиотеками, которые как раз для этого предназначены.

- Для Symfony есть прекраснейший компонент Live Components. Вы пишете всё в Twig, вставляя там особые атрибуты, и компонент возьмёт на себя всю работу по замене частей страницы нужными компонентами.

- Либо, если вам не понравится почему-то Live Components, можете воспользоваться Htmx

В результате вам даже не нужно будет особо знать JavaScript, всё будет автоматом работать

P.S. Если вы уже пользуетесь фреймворком, то пользуйтесь его плюшками, сильно упрощающими жизнь. Я имею ввиду, что не стоит использовать голый curl с простынёй настроек, когда в наличии имеется превосходный HTTP Client https://symfony.com/doc/current/http_client.html
А для сериализации/десериализации из JSON в PHP и обратно, лучше всего использовать Serializer component https://symfony.com/doc/current/components/seriali...

Ну так измените ваш диалект SQL. Phpstorm просто не знает, каким именно SQL вы пользуетесь (PostgreSQL, MySQL, SQLite).

На скрине во всплывашке прямо внизу слева есть синяя ссылка "Change dialect to"

К тому же, по-моему, если в проекте подключить базу в окне с базами данных, то он должен сам подхватить диалект оттуда

Лицензией на кодек владеет множество компаний, и каждая из них выдвигает собственные требования к лицензированию, в т.ч. с разделением по регионам.
Из-за этого HEVC-видео воспроизводится только при определённых условиях. В браузерах оно обычно требует поддержки аппаратного ускорения (т.к. производитель железа уже заплатил за возможность поставки декодера в железе). Если аппаратного ускорения нет, в Windows можно купить декодер в магазине приложений за $0.99, с ним будет работать видео в Edge (не уверен про другие браузеры)

https://caniuse.com/hevc

Картинка находится той же директории, что HTML страница.

Если бы речь шла про сайт без бекэнда (т.е. просто набор html/css/js файликов, которые раздавал бы сервер), то такое решение могло бы сработать. В случае с Django (ну или любым другим фреймворком) сервер ни про html, ни про директорию, в которой он находится не знает. Его задача сводиться к:

• передаче запроса фреймворку и возвращении получившегося ответа;
  
• работе со статикой/медиафайлами;
  

Поэтому картинку нужно поместить в папку со статикой и обращаться соответствующе. Т.Е. как минимум так-же как и с файлом стилей. А как максимум - придерживаться официальных (django/flask) механизмов подключения статических файлов.

var res = pm.response.json();
pm.environment.set('token', res.token);

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

В качестве примера: пользователь послал на сервер через веб-страницу запрос и ждет результата. Представим, что запрос - сложный, результат так сразу не получить, запрос выполняется, а пользователь ждет, потому что всё это понимает. Потом пользователю внезапно надоедает ждать и он посылает команду Отменить. Или - закрывает страницу. Так вот, по-хорошему, в этом случае надо отменить задачу, которая выполняет запрос, чтобы она не тратила впустую ресурсы сервера.

А ещё отмена полезна для прерывания процессов потенциально бесконечных, типа смотреть, как горит огонь, как течет вода, как люди работают... :-)

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

Вангую - на бэке PHP и сессии. Причём, открываются сессии в начале скрипта, а закрываются никогда, то есть по завершении скрипта.
Тогда пока работает скрипт, файл сессии держится открытым и второй скрипт в той же сессии будет ждать освобождения файла. Файл сессии надо освобождать как можно раньше. session_start, считали нужные данные и сразу же session_write_close. Если надо что-то изменить в сессионных данных в процессе работы скрипта, то снова открыть сессию, записать изменения, закрыть.

Если хотите идеал, то он должен соответствовать следующим пунктам:

1. Сериализация/десериализация - это дорогостоящее мероприятие, поэтому оно должно делаться только в двух местах: прямо на входе и прямо на выходе. Вход - это ваш контроллер, Выход - это другой сервис, куда вы передаёте данные, или база данных (тут тоже происходит сериализация, либо явно, либо в ORM). Во всех остальных слоях инфообмен должен совершаться уже при помощи объектов PHP либо нативных типов. Это экономит ресурсы. При передаче между слоями приложения объектов вместо значений либо ассоциативных массивов вы сразу будете видеть очепятки, IDE вам прекрасно поможет при помощи автодополнения, объекты могут иметь какие-то полезные методы.

2. Очень желательно в каждом из слоёв иметь собственный класс, отвечающий за данные. Например, нам в слой API приходит JSON-чик с новым пользователем.
- Сериализуем JSON в DTO UserInAPI, сразу валидируем всё то, что мы можем валидировать без слоя бизнес-логики, и либо отдаём клиенту ошибку, либо передаём сам объект UserInAPI в следующий слой: слой бизнес-логики
- В слое бизнес логики, получаем DTO UserInAPI на входе, преобразуем его в свой бизнес-объект UserInBusiness, валидируем его уже с точки зрения бизнеса, и либо возвращаем ошибку в слой API, либо совершаем над ним действия, и передаём объект класса UserInBusiness в слой работы с базой
- В слое работы с базой данных получаем на входе объект UserInBusiness, преобразуем его уже в сущность базы данных UserInDB, валидируем всё на предмет корректности данных для базы, и либо возвращаем ошибку в бизнес, либо сохраняем сущность класса UserInDB в базу.

Зачем такие сложности, вы спросите? А просто обратите внимание на то, что скорость изменения кода в разных слоях разная.
- API вообще должен меняться раз в сто лет, чтобы не злить клиентов. Поэтому DTO класс UserInAPI будет стабильным и редко будет меняться.
- Бизнес-логика меняется очень часто. У класса UserInBusiness постоянно будут добавляться поля и методы, тут жизнь будет кипеть.
- Слой базы данных будет меняться реже, чем слой бизнеса, но чаще, чем слой API, потому что нам нужны будут новые поля в базе, новые таблицы и связанные таблицы.
- И если мы один тип сущности протащим во все слои, то эта сущность обрастёт таким количеством различной хрени, что нам плохо станет, когда будем на неё смотреть. Либо она обрастёт кучей декораторов в каждом из слоёв. Поэтому лучше всё разделить.

3. Теперь внимание, казалось бы, что мы слишком сильно связываем наши слои, и нижестоящие слои знают что-то о вышестоящих, а это неправильно. Ведь мы передаём объект UserInAPI в слой бизнеса, т.е. слой бизнеса должен уметь работать с этим объектом. И так же слой базы должен уметь работать с объектом бизнеса UserInBusiness. Как же быть? А очень просто. На входе слоёв использовать интерфейсы. Т.е. в слое бизнеса мы будем принимать не сам класс UserInAPI, а объект, имплементирующий интерфейс UserIncoming, который объявим в бизнес слое, и заставим слой API сделать так, чтобы его класс UserInAPI имплементировал этот интерфейс. Таким образом слой бизнеса ничего не будет знать о слое API, а будет ждать на входе данные по контракту, описанному в интерфейсе. Бизнесу плевать на конкретную реализацию, ему нужны только методы getUsername, getEmail из интерфейса. А какой класс ему их предоставит - пофигу. Таким образом мы практически полностью разделяем слои и в два счёта сможем поменять слой API, где у нас HTTP контроллеры, на слой RabbitMQ, SOAP, Grpc и т.д.

Если вы просто откроете настройки шторма и в поиске (слева вверху) просто напишите три буквы "git", то легко найдете настройку "Explicitly check for incoming commits remote", которую следует выставить в Always

Так же можете изменить "Check for conflicts with the server every"