ThunderCat

xpath: //strong//strong

https://habr.com/ru/post/114772/
msdn.microsoft.com/ru-ru/library/ms256471%28v=VS.9...

Насколько я понял, вы храните список категорий в одном поле через запятую. Это изначально неверный подход, противоречащий 3 нормальной форме, кроме того больше приносящий вреда и гемора чем профита. Кажущаяся "простота" такого подхода (как видно из вашего примера) оборачивается проблемами как только нужно применить логику чуть сложнее "выбрал-показал". Скорее всего при такой структуре самым "хорошим" решением будут циклы с запросами, что само по себе уже кошмарный говнокод.

Как вариант решения конкретно этой задачи - можно так:

foreach ($posts as $post) {
    $postsCat[trim(explode(',', $post['category'])[0])][] = $post['alt_name'];
}
unset($posts);

1) Включите вывод ошибок и варнингов, будет хоть понятно что происходит
2) Выведите var_dump($qr_image);, вполне возможно что там нифига нет.
3) Вообще достаточно проверить есть ли файл который вы берете - file_exists($path_to_file);

1) $id видимо определен выше вызова функции, но как уже вам указали - область видимости внутри функции - локальная, все что не определено внутри тела функции для нее не существует, исключение - глобальные переменные.
2) Научитесь пользоваться дебаггером, например xdebug, или хотя бы используйте var_dump().
3) sql запросы СНАЧАЛА формируете в виде строки, затем передаете в вызов, тогда можно будет их вывести и посмотреть что с ними не так, подозреваю что в варианте который вы "поправили" проблема в отсутствии поля user_id которое скорее всего обязательное. Можно проверить напрямую введя этот запрос в консоль мускуля или через phpmyadmin.
4) Код кошмарный, во-первых зачем-то засунут в функцию, хотя этот код вряд ли будет использоваться дважды, во-вторых функция использует внутри себя глобальные переменные, что плохо. Почитайте про чистые функции. Про метод "проверки" переменных вообще нет слов, сплошь междометия...

Ахренеть, то есть если я, допустим, пользователя понизил в правах, то по вашей логике я должен лично к нему домой причапать и почистить куки/сторэйдж. Это гениальное решение, решающее несуществующую проблему! Браво!

JS: если не закрывать браузер в течении всего этого времени - достаточно по setInterval() декркментировать значение каждые 24 часа ( 24*60*60 секунд). Если браузер закрывается - соответственно хранить время начала отсчета в куках или локалстораже, и от него уже отнимать количество дней / секунд прошедших от старта.

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

это чисто примерный запрос, но т.к. я в sql полный профан, прошу объяснить что в нем неверного.

Подскажите как можно снизить нагрузку и увеличить скорость запросов при условии оптимизированного кода и запросов.

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

1) клиент копирует текст, он отображается в браузере с переносами строк

Откуда копирует?

Но если этот текст скопировать вручную из textarea, это будет всё как одна строка без переносов

Сомневаюсь, просто преобразование идет чуть сложнее чем просто скопировал-вставил. Скорее всего перенос строки сначала преобразуется из какого-то "вордовского" формата в \n, а потом вы переносите его обратно, где его уже "не видно".

1) $data = $_POST; - тупая трата памяти.
2)

header('Content-Type: application/json; charset=utf-8');

Вы еще ничего не сделали, и уже выводите заголовки. Зачем?
3) if ($data) { если дата что? Всегда давайте осмысленные кодовые описания, например !empty()
4) Проверяете переменные $_POST, но $_FILES не проверяете? Нааайс... Как то уже определитесь...
5) Вишенка на торте - в инпутах имена nameInput и newsText, однако на сервере мы упорно ищем поля name и email (????).

1) teamViewer
2) VPN + RDP или его аналог

1) Нет смысла руками рвать соединение, при завершении скрипта коннект закроется автоматически. В вашем же случае весьма вероятна ситуация что коннект порвали зря и скрипт еще не отработал до конца.
2) Онлайн порядка 500-1000 чел.Для запаса я бы поднял количество соединений до 1/4 онлайна. Зависит конечно от специфики сайта, но иногда их реально не хватает если сервер с активным взаимодействием с бэкендом.
3) Для драйвера бд пишется враппер, не по тому что это модно или прям необходимо для работы, а как раз на такие случаи, в логику врапера пишется опциональное логирование запросов и сразу видно "кто где срал", сколько реально запросов бегает и что вообще происходит. Тогда можно что-то решать на уровне много/мало и куда что крутить. В частности, может оказаться что коннект происходит чаще чем вы думаете и вовсе не там где задумывалось...