alexalexes

Конечно. Переходник питания molex на sata называется.

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

Чешите валидацию не по всему документу, а по форме.
Параметр формы у вас передается внутрь функции.
Было:
let formReq = document.querySelectorAll('._req');
Должно:
let formReq = form.querySelectorAll('._req');

Перевести в массив объект -> если есть элементы, то ... отмапать элементы с нужным дополнением 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. Если вы аппаратно звуковую карту никак не отключали, значит она неисправна совсем, и в этом разделе вы ее не увидите. Если там есть альтернативное устройство от материнской платы, значит, что-то с драйверами в операционной системе.