Sanovskiy

$select = 'select * from watches where 1=1';
$binds = [];
if(!empty($from)) {
    $select .= ' and from>=?';
    $binds[] = $from;
}
if(!empty($before)) {
    $select .= ' and before<=?';
    $binds[] = $before;
}
$stmt = $this->_instance->prepare($sql);
$stmt->execute($binds);
$items = $stmt->fetchAll(PDO::FETCH_ASSOC);

Я, честно, не понимаю таких вопросов.

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

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

То есть вместо стандартного подхода мы усложняем код, чтобы в итоге получить проблему. Я искренне не понимаю, какой в этом смысл

просто сначала у всех удалить, и тут же добавить нужному active)

$('li').removeClass('active');

$(this).addClass('active')

Если подумать за автора, то ему надо это

$result= mysqli_query($conn, "SELECT value FROM _main WHERE variable = 'logo'");
$row = mysqli_fetch_assoc($result);
$logo = $row['value'];

В ПДО действительно будет проще

$logo = $pdo->query("SELECT value FROM _main WHERE variable = 'logo'")->fetchColumn();

Если нужен, как выясняется, словарь, где ключами являются значения колонки variable, то PDO без вариантов.

$settings = $pdo->query("SELECT variable, value FROM _main")->fetchAll(PDO::FETCH_KEY_PAIR);
echo $settings['logo'];

даст нам вожделенную картинку, поскольку метод fetchAll() с модификатором PDO::FETCH_KEY_PAIR
как раз и дает нам двумерный массив, где ключи - это содержимое перво....

Принцип KISS не означает что надо использовать самые примитивные инструменты.
Он означает, что не надо переусложнять систему без нужды.
Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

Для того, чтобы упростить управление системой, её надо усложнить.
Этот принцип относится к любой области человеческой деятельности, от постройки ракет до управления государствами.
Чем сложнее система, тем больше накладные расходы на ее управление. Хоумпейдж с котиками можно и нужно делать примитивными средствами. В большом проекте надо сразу закладываться на будущую расширяемость. То есть, заранее делить ответственность между "леерами".

И кстати. Код, в котором "всё друг на друге завязано" - это очень плохой код. Собственно, предназначение всех этих "лееров, провайдеров и репозиториев" как раз в том, чтобы компоненты были как можно более независимы друг от друга.

Вы забыли добавить второй обработчик. Вот тут ваш пример, только с добавлением всех событий

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

clone.querySelector('.btn-add').addEventListener('click', addHandler);
clone.querySelector('.btn-delete').addEventListener('click', addHand);

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

Это действительно может быть удобно. Например, чтобы выделить четвёртый проект из ваших трёх — содержащий скажем библиотеку компонентов и сторибук. Я нашёл для себя кейс при работе с реакт нейтив и реакт нейтив веб.

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

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

Для начала query() меняем на это

public function query($sql, $params = []) {
    $stmt = $this->db->prepare($sql);
    $stmt->execute($params);
    return $stmt;
}

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

А для получения ответа на вопрос надо научиться правильно соединяться с PDO.
Для этого там, где создается инстанс класса $this->db, пишем вот такой код, в котором самой главной является строчка

PDO::ATTR_ERRMODE            => PDO::ERRMODE_EXCEPTION,

После этого запускаем свой код, и PHP сам, человеческим голосом, сообщает нам, в чем проблема этого кода.
Таким образом мы сразу убиваем двух зайцев:

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

На будущее. Сидеть тупить в код совершенно бессмысленно. проблема может быть где угодно - в другом коде, в настройках БД, в свойствах таблицы, в опечатках, которые в реальном коде есть, а в подредактированном варианте для тостера нету. И еще примерно в миллиарде причин. Все равно все перебрать нереально.

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

у вас 2 инсерта в коде.
один вставляет ИД, другой имена. Все правильно в базе. Ровно по вашему алгоритму)

Для начала почитайте что такое SAPI. Затем представьте что apache + mod_php разделили на web-сервер, который проксирует запросы на php-fpm и отдает статику, и собственно отдельный web-сервер который имплементит SAPI и выполняет запросы связанные только с php. То есть статику отдавать мы можем только через php. Суть примерно та же что и у apache2 + prefork + mod_php но оптимизированный только для работы с php. Так же можно поставить на фронт более быстрый и легковесный сервер который умеет проксировать запросы.

То есть php-fpm это эдакий fast-cgi сервер который постоянно держит готовые для работы пул-процессов (сколько в пуле процессов настраивается, так же как и от какого пользователя их запускать и все такое прочее). Каждый новый запрос уходит в какой-либо процесс из пула, запрос отрабатывает, возвращаем результат тому кто попросил (web-серверу обычно). Если процесс падает (fatal допустим) - поднимаем новый.

Принципиальной разницы между apache2+mod_php нету, просто упрощается инфраструктура. Наш web-сервер должен только уметь проксировать запросы и отдавать статику, а php-frpm вообще может быть на разных машинах (балансировщиком можно раскидывать запросы). Ну и сами понимаете, nginx + php-fpm будет быстрее обрабатывать запросы чем apache2+mod_php какой бы мы менеджер процессов не использовали в апаче. Минусов по сравнению с apache+mod_php я даже не могу предложить.

А php-runtime не зависит от этого. Он один на всех, CLI, FPM, mod_php...

1:
.item.active
<div class="item active"></div>

.item .active

<div class="item">
  <div class="active"></div>
</div>

2:
#ul
<div id="ul"></div>

.ul
<div class="ul"></div>

ul
<ul></ul>

В действительности вы описали связь "многие ко многим".

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

Вам нужно реализовать подобную структуру в БД


А дальше нужны грамотные индексы по таблицам.
В таблице связей первичный ключ делаете составным из 2х полей