Александр Новиков

https://stackoverflow.com/questions/14451401/how-d...

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

Если вы пишете такие продукты, что уперлись в производительности в PHP - мое почтение. (хотя что-то мне не верится). Особенно с такими примерами кода.

Как правило логичным шагом при получении таких ограничений - переписывание узких мест на более производительных языках, как например поступают в Badoo. на C/go. А основная кодовая база ТАК выглядеть не должна ни при каких условиях.
Используется функциональный подход - так где функции высшего порядка? где отсутствие глобальных состояний? Ваш начальник не умеет ни функциональный подход готовить, ни объектно-ориентированный.
По факту - вашего начальника я бы не взял даже на должность джуниора - 15 лет писать вот такое, принципиально считать что твои велосипеды лучше всех сложившихся практик, и быть намертво уверенным в собственной правоте - это смерть для разработчика и для коллектива, в котором он работает, а если уж он еще и начальник в нем... Из-за таких как он и ходит в сообществе мнение о PHP как о плохом языке для обезьян.

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

Ну это как и у других - оффтоп с критикой твоего начальства.

Что касается именно кода - обрати внимание на PSR соглашения - по форматированию кода, именованию переменных, сделаешь код более читаемым (www.php-fig.org/psr/) , это стандарт в индустрии и на скорость никак не повлияет, можешь даже начальнику показать.
Дальше познакомься с PDO и понятиям SQL инъекций. Код приведенный в вопросе абсолютно небезопасен, и то, что параметр $settings задается разработчиком - не аргумент. Новый джун может запросто туда отправить просто $_POST при сабмите формы - и вы никак от этого не защититесь. Код должен быть защищенным изначально, а не дырявым и "но вы эти дыры не используйте".
Листинги кода такой длины - нечитаемые, бейте на логические куски, книга Мартина Фаулера "Рефакторинг" в помощь, чтобы понять, как оптимально и правильно это сделать.

Думаю, если

(без namespace'ов и прочего) для своей cms.

- то вам рано делать свою CMS. Лучше изучите качественные готовые решения.

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

Убедиться, что подключен Memcached (или подключить)
И в коде

$m = new Memcached();
$m->addServer('localhost', 11211);
if(($data = $m->get('someKey')) === false) {
// do some actions do get data from remote source
// place your code here, store result in $data variable
$m->set('someKey', $data, 60*60*2);
}
return $data;

Ну так у Curl namespace не vendor\Curl\ , a просто Curl; Заменить на
namespace vendor\Curl;
и попробовать снова

Хотя в 2017 году стыдно не использовать composer autoloader

Если правильно понял суть проблемы, то можно попробовать это

Такой способ запроса - прямой путь к sql injection
Правильнее использовать prepared statements ( php.net/manual/ru/pdo.prepared-statements.php )

$sql= $db->prepare("UPDATE vt SET rc = :value");
$sql->bindParam(':value',  $js['rc']);
$sql->execute();

Вероятно вместо <a href="?view=news?news_id=$news_id"> надо <a href="?view=news&news_id=<?=$news_id?>">
А дальше уже все зависит от роутинга. Пока что как минимум ссылка формировалась неправильно

php.net/manual/ru/function.preg-replace.php

Ну вообще вопрос довольно комплексный.

Если вопрос именно о запуске приложения в процессе разработки, в локальной среде, то хорошим вариантом будет Docker, либо Vagrant. Тогда php будет выполняться в родной для себя среде, и также будет один распространяемый на всю команду конфиг, чтобы среда выполнения была консистентна.
Т.е пишешь код в IDE, и проверяешь изменения на локально работающем сервере.

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

Ну и разумеется вести разработку через CVS (git, например), для начала даже git-a по ssh хватит для обновления кодовой базы приложений на рабочих серверах (даже на виртуальных хостингах он часто есть)

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