alexalexes

Перевести в массив объект -> если есть элементы, то ... отмапать элементы с нужным дополнением li -> объединить массив с пустым разделителем.

`<div class="store__text">` + (Object.entries(item.desc[0]).length > 0 ? `<ul>` +Object.entries(item.desc[0]).map((desc_item) => `<li>` + desc_item[1] + `</li>`).join(``) + `</ul>` : ``)
      + `</div>`

Если СУБД поддерживает тип данных JSON, а вы хотите сравнивать JSON тело как строку, то приведите содержимое из JSON в строку.

SELECT * FROM tavle
 WHERE JSON_EXTRACT(json, '$') = jsons; -- атрибут json относится к таблице tavle, а jsons - плейсхолдер, куда вы подставляете строку, по которой будете искать тело?
-- JSON_EXTRACT(атрибут_типа_JSON, '$') - это выражение конвертирует JSON в строку, аналогично как в JS будет JSON.stringify(объект_с_данными).

Это норма. Нет никаких требований, чтобы url обязательно повторял какие-то части пути к реальным файлам на сервере.
Часть url, который отвечает за некий путь, - это всего лишь набор параметров. Как их интерпретировать - решается на уровне конфигурации apache/nginx, или непосредственно в скрипте CMS (роутинг).

Вы выделили в системе два класса сущностей. Одна - Пользователь, вторая - Роль.
Под каждый класс нужна отдельная таблица.
Как определить какие взаимоотношения между этими классами?
Нужно примерить следующие коммутативные гипотезы:
Первая пара гипотез:
"Один пользователь должен (может) иметь только одну роль."
"Одна роль должна (может) быть назначена многим пользователям."
Вторая пара гипотез:
"Один пользователь должен (может) иметь несколько ролей."
"Одна роль должна (может) быть назначена многим пользователям."
Если в вашей архитектуре системы справедлива первая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "один ко многим". Это значит, что у таблицы Пользователь будет внешний ключ в виде идентификатора роли, тем самым вы каждому пользователю сможете назначить только одну роль. Но сами роли могут повторятся у разных пользователей.
Если в вашей архитектуре системы справедлива вторая пара гипотез, то вы строите взаимоотношение между классами Роль и Пользователь как "многим ко многим". Для этого нужно создать промежуточную таблицу, например Пользователь_и_роль, в которой будут два внешних ключа - идентификатор пользователя и идентификатор роли пользователя (можно, но технически нужно еще создать еще идентификатор первичного ключа, чтобы можно было корректно обращаться к записям этой таблицы, не путая их). В этом случае каждому пользователю можно выделить целый набор ролей, не ограничиваясь одной ролью.

Запустить AIDA64 и посмотреть, что есть в разделе устройств Мультимедиа -> Аудио PCI / PnP. Если вы аппаратно звуковую карту никак не отключали, значит она неисправна совсем, и в этом разделе вы ее не увидите. Если там есть альтернативное устройство от материнской платы, значит, что-то с драйверами в операционной системе.

При использовании bootstrap вы не можете мыслить фиксированными шириной.
У вас есть 12 колонок - 12 долей единиц ширины экрана, и есть с полдюжины разных размеров экранов.
Самый маленький, малый, средний, большой и очень большой.
И логика расстановки классов такая:
"На большом экране и больше у меня слайдер будет шириной 6 из 12 колонок,
на среднем 8 из 12 колонок,
от малого и меньше 12 из 12 колонок".
С этой логикой и навешиваете нужный набор классов на контейнер слайдера.
JS код не должен фиксировать размер контейнера в пикселях, нужно ему позволить расширяться по bootstrap сетке.

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

.header-dropdown-item {
...
  height: 4rem;
...

.header-dropdown-item:hover {
...
  height: fit-content;
...

Эти значения высот в вычисленном состоянии имеют разный результат в пиксельном выражении?
Как вы думаете?