Дмитрий Энтелис

Можно в режиме телепата гадать 100500 раз о том что происходит.
По факту вопрос слишком абстрактный, научитесь дебажить код.
Идеально было бы поставить xdebug и ide которая умеет с ним работать, но на крайний случай вас спасут print_r и var_dump.
Прямо с начала, берете, и для каждой строчки по очереди проверяете - те ли данные вам пришли, что вы ожидали, те ли строки сформировались что вы ожидали, итд.
это собственно и есть - работа программиста.

По теме вопроса: раз echo ничего не выводит - значит там ничего нет, магии не бывает.
(и кстати опять же в режиме телепата - у вас скорее всего выключен вывод нотисов)

Причин почему там ничего нет - может быть море:
- curl_exec($curl) может вернуть не строку, а false, и в функции curl_error($curl) будет текст ошибки.
- curl_exec может вернуть строку в которой нет json
- curl_exec может вернуть строку в которой есть json, но в нем структура какая-то не такая как вы ожидаете (например ошибка или еще что-то)

Повторюсь, магии не бывает. Если что-то не работает, нужно идти по шагам и дебажить дебажить дебажить.

Сам не пробовал, но может быть посмотреть в сторону php.net/manual/ru/book.phar.php ?
Там даже в комментах есть кусок кода который собирает phar из папки с исходниками.

Ладно, отвечу серьезно.

По поводу самой проблемы:
Можно в режиме телепата гадать 100500 раз о том что происходит.
По факту вопрос слишком абстрактный, научитесь дебажить код.

Конкретный пример: у вас есть ваш "код фильтрации".
Идеально было бы поставить xdebug и ide которая умеет с ним работать, но на крайний случай вас спасут print_r и var_dump.
Прямо с начала, берете, и для каждой строчки по очереди проверяете - те ли данные вам пришли, что вы ожидали, те ли строки сформировались что вы ожидали, итд.

Скорее всего вы поймете в чем проблема сами.
Даже если не поймете - сможете задать уже конкретный вопрос.
Ну и хорошо бы вывод всех ошибок и нотисов включать.

<?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);

Теперь в целом по коду:
1. Почитайте про MVC. mysqli функции вперемешку с html версткой - недопустимы.
2. Вынесите всю работу с базой в отдельную либу. есть 100500 готовых решений на гитхабе.
sql connect в filterTable - очень плохо.
3. В базу нельзя отправлять user input без обработки! Как минимум нужно делать mysqli_real_escape_string
4. За запрос where concat(`fullName`, `group_name`) = ... в реальном проекте, увольняют сразу. Запрос не использует индексы и должен для каждой строки таблицы выполнить объединение 2х полей, а потом еще и сравнить. Это дико медленно.
Нужна такая строка для поиска - собирайте её отдельным полем в базе.

Я считаю что нормально иметь такие вещи целиком в php, а в базе держать просто tinyint

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

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

ключевые слова для изучения:
система контроля версий (git)
автодеплой

Куки можно ставить только на домен и на его поддомены.

Соответственно глобально вариантов сделать cross-domain cookie ровно 2:
a) на домене example.com ставите обработчик который вешает куку на нужный домен dev.example.com или вообще на .example.com
b) на домене dev.example.com ставите обработчик который вешает куку на этот же домен.

Можно это делать на php, можно это (хоть и не секьюрно) делать через js (вот например либа ) - но в любом случае нужен доступ либо к целевому домену, либо к домену верхнего уровня.

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

Поскольку у Вас уже Монго - совет в целом запоздал, но все же применим и тут.

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

Никто кроме Вас - не может замерить это в живом проекте на живой задаче и не сравнит с затратами на обновление при сохранении.

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

Называется это CRM для интернет магазина.
Это если нет ничего и нужно с нуля.

Если база уже есть - то только на заказ писать.

html, css, javascript, немного php.

Любая схема с контролером домена AD вне собственной инфраструктуры ущербна по определению.

Я бы не хотел разводить тут политосрач, но вы новости читаете?
Вы реально верите что действия РКН имеют собой цель блокировку телеграмма?
На мой взгляд, схема с любыми ресурсами за пределами РФ в текущей ситуации ущербна в квадрате.

START TRANSACTION;
select * from users where id = 54 FOR UPDATE
//проверка бизнес логики на наличие денег
update `users` set `balance` = `balance` - 150 where `id` = 54;
COMMIT;

Запрос "where `id` = 54 and `balance` >= 150" - опасен.
Innodb лочит не конкретные записи, а диапазоны индексов - при таком запросе в блокировку будут попадать все записи с балансом >= 150, со всеми вытекающими.