Walt Disney

frond-end-разработчик отвечает за то что происходит на в браузере, back-end-разработчика который отвечает за то что происходит на сервере. При этом ключевое слово здесь разработчик, т.е. разработчик на js, вёрстка может и не входить в его обязанности, а может входить. Если frond-end-разработчик не умеет js, но умеет css/html то его называют верстальщик.

full-stack разработчик это тот кто может тянуть проект/задачи в одно лицо т.е. для закрытия задачи не нужна помощь других спецов. В данном случае чаще понимается, что разработчик владеет всем используется в конкретном проекте. Т.е. это может быть как photoshop+js+html+css, а может быть python+android/java+ios/objC

$servers[] = array(...);

вы видимо, что то такое хотите

foreach($a as $v){
 echo $v['id'], ':', $v['name'], ' ';
}

Видимо у вас отличается кодировка базы или таблицы или колонки в таблице - у них у всех может быть разная кодировка, от кодировке на сайте. Нужно сделать везде utf8.

p.s. не забудьте снять копию базы до экспериментов с кодировками

найдите функцию glob в мануале

Общее для всех mysql:
Проверить какой запрос отрабатывает система если replace то плохо если update или insert on duplicate key update - то ок.
Если в action_history есть индексы кроме примари кей то их скорее всего стоит убрать т.к. вероятно запросы ( сортировки или агрегации) по этим полям будут приводить в любом случае к фулскану и индекс не будет иметь смысла, а при апдейте перестройка будет постоянно всё класть.

Для Maria: убедиться, что в Maria XtraDB не сломана построчная блокировка (всё таки опыт продакшена у марии неё вялый ). Потом вызывает опасение реализация внешнего индекса в таблицах разного типа, возможно это как то может ломать построчную блокировку. Если у вас лок всей таблицы разберитесь откуда, так не должно быть

В общем и целом, поразмышлять что INSERT DELAYED VALUES (1,2,3),(..,..,..),(N,N,N) для записи всех действий будет работать заметно веселее особенно без индексов и в одном потоке, а после некоторых шаманств с агрегацией по крону ещё не будет деградировать от распухания. Что можно про крону парсить access.log (понимать что он не рилтайм), в этом случае будет одна пачка апдейтов допустим раз в минуту и user_id будет заапдейчен только один раз, это будет пожалуй самой простой реализацией задачи упорядочивания и фильтрации потока апдейтов к mysql. Парсинг лога можно заменить на RabbitMQ, или написать своего демона который будет висеть на соке и рулить.

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

Искать как сделать escape в mysql.
INSERT .. SET text_field = "plan text" - у вас всё ок
INSERT .. SET text_field = "html text" - ломает кавычки

Отдельно разберитесь где потеряли ошибки, где то они должны быть.

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

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

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

Соответственно ответ на сам вопрос: начните решать задачи где написание такого кода жизненно необходимо.

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

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

P.S. на продакшене все ошибки и предупреждения надо логировать и разбирать потом.

$d = new DateTime('2015-01-07');
$d2 = new DateTime('2015-24-07');
do{
   echo $d->format('Y-m-d');   
   $d->modify('+1 day');
   

}while($d <= $d2 );

@tamtakoe вам @Masterme всё верно сказал, если джойны не подходят идеологически сделайте три простых селекта подряд, вас никто не заставляет делать один запрос. И база их отлично закеширует, чего скорее всего не будет с джойнами.

А ещё лучше будет если вы расширите исходный набор данных клиента, так что бы он мог сразу сделать api.site.ru/museums?city=123&categories=456&type=best

curl_setopt($curl, CURLOPT_POSTFIELDS, $data); не должно быть строкой, вы же не стороне node.js ожидаете данные от формы.
Пишите что то вроде:

curl_setopt($curl, CURLOPT_POSTFIELDS, array('jsonData'=>$data));

Или парсите на стороне ноды сырые данные, но это более замороченный путь.

Так и делайте,
пропишите нужный рут в location

То, что элементы первого массива фиксированы, а элементы второго массива задаются пользователем.
SQL в PDO записывается так: SELECT * FROM table `name`=:name AND pass=:pass
Далее мы даём на обработку массив array(':name'=>$name,':pass'=>$pass)
В PDO отлично заменяет.

$name = 'test';
$pass = 'name:qwe';
$query = 'SELECT * FROM table `name`=:name AND pass=:pass';
$arg = array(':name'=>$name,':pass'=>$pass);

$query = str_replace(array_keys($arg),array_values($arg),$query);

var_dump($query);

Вам это было нужно?

Противоречие:
root /srv/example.ltd/www;
fastcgi_param SCRIPT_NAME /www$fastcgi_script_name;

у вас должно быть типа:
fastcgi_param SCRIPT_NAME /srv/example.ltd/www$fastcgi_script_name;