Adamos

/vendor/{your_company}/{project}?

Глупо молиться на SOLID, KISS и прочие часто цитируемые вещи. Они - не катехизис и единственно правильный путь, они - всего лишь идеи, помогающие взглянуть на код не с той стороны, с которой на него смотрит разработчик, и уменьшить связность, например.
Это все равно, как если бы вы занимались изобретениями и проверяли не успешность решения ими поставленной задачи, а соответствие этого решения высосанным когда-то из пальца в попытке систематизировать накопленный опыт принципам ТРИЗ.

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

А во-вторых, код, который никто никогда не правил - никому не нужный код. А тот, кто правит, может не знать, что тут везде раскиданы грабли и надо быть осторожным. Даже если это будете вы сами через год-два.

С Екселем работал человек, которому было удобнее работать с одной простыней. С базой будет работать код, которому нужна логика, а не наглядность. Корячиться с одной таблицей - дурость. Делайте нормальные формы и забудьте уже этот каменный век.

1. Это GET-запросы.
2. В настройках nginx есть инструкция rewrite, позволяющая прогнать url через регулярку.
3. Но, поскольку домены разные, не исключаю, что вам на самом деле нужен вызов cUrl в обработчике этой ссылки.

Нет кодировок, кроме UTF-8, и json_decode - распознает ее! ;)

При отправке формы обращаетесь по ajax к вашему сайту за получением подписи, подставляете ее и только потом отправляете форму. При этом проверяете валидность того, что ввел пользователь (чтобы он не подставил в оплату заказа ценой 100 рублей плату 1 рубль, например).
Подпись, собственно, для этого и используется.

1. Проверить, когда начислялся бонус последний раз
2. Если больше дня назад, то начислить бонус и обновить дату получения

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

Пишешь на PHP обобщенный вывод данных из запроса в HTML-таблицу.
Если нужен xls - добавляешь HTML-заголовок с кодировкой, отдаешь этот файл с заголовком, в котором сказано, что это xls-файл, любой офис это спокойно воспринимает.
Если нужен pdf - скармливаешь ту же таблицу mPDF. Десяток строчек кода.
Вот и асе.
Главная трудность в том, чтобы выдавать корректные заголовки столбцов таблицы.
Но это за вас никакая сторонняя библиотека все равно не сделает - откуда ей знать, что у вас за данные?

https://secure.php.net/manual/ru/ref.array.php

Во-первых, трудно поверить, что нет кучи готовых решений, разбирающих лог Апача.
Так что задание, очевидно, учебное, на использование языка и понимание, что такое ООП.
Так вот, ООП в РНР - это чтобы один раз сделать грязную работу, и больше в нее не заглядывать, используя готовый и по возможности очевидный интерфейс класса.
У вас же одноразовая портянка, в которой даже имена файлов жестко прописаны в коде, убогие комментарии вместо PHPDoc и вообще ощущение, что ООП вы начали заниматься вчера и считаете его просто возможностью загнать побольше функций в один класс.
Ну, и результат соответствующий. Вам нужно не исправить это решение, вам нужно позаниматься ООП в РНР некоторое время и прийти к соответствующей парадигме в мышлении. А этот класс можете просто выкинуть.

В PHP можно не плодить функции на каждый чих просто из-за того, что у них разные аргументы. Например, так:

$input = SmartInput::parsePost([
  'id' => SmartInput::INPUT_INT,
  'sex' => ['type' => SmartInput::INPUT_ENUM, 'enum' => ['male', 'female', 'none'], 'default' => 'none'],
  'birthday' => SmartInput::INPUT_DATE_OPTIONAL,
  'phone' => ['type' => SmartInput::TYPE_PHONE, 'multiple' => true]
]);

Внутри функции - цикл и case.

На моей памяти ВОМ был действительно нужен только в одном случае: для компиляции UTF-8 исходников в ВижуалСтудии, криворукие программисты которой не справились с автоматическим распознанием кодировки и не осилили сделать настройку, которая позволила бы пользователю задать кодировку принудительно.
В вебе про этот костыль лучше просто сразу забыть. Если проблемы с ним - значит, вы что-то неправильно делаете.

HTML-портянка со вставками %ПОД_ЗАМЕНУ%. Любой офис ее откроет, как родную.
А прогиб именно под M$-офисный формат в данном случае - первый шаг на Темную сторону.

Не претендуя на правильность - личный опыт.
Сайт представляет собой внутренний продукт для работы. Есть куча данных, с ними нужно работать определенным образом.
Типичная страница - это фильтры выборки и таблица с данными. Да, для их обработки могут применяться какие-то иные интерфейсные решения. Да, страница какого-то конкретного клиента или графики для руководства - это отдельная тема. Однако большая часть рабочих страниц строится именно по схеме "выборка - таблица - работа с ее строками".
Для типовой страницы потрудился написать мини-фреймворк, который строит форму фильтров и таблицу результатов по описанию в форме объекта с известными полями. Большая часть полей приходит с бэкенда - начальные значения фильтров, заголовки столбцов, данные пагинации. Здорово уменьшает работу руками... и дает пользователю единообразный интерфейс. А также позволяет централизованно добавлять плюшки вроде сортировки по столбцам, итоговой строчки и т.п.
Для запросов, ответов и прочего здорово подходит встроенный AJAX framework OctoberCMS. Данные удобно представляются моделями, к которым тот же Октябрь позволяет буквально одной строчкой добавить еще и подгруженные файлы. Если нужно дать админу возможность поковыряться в данных - добавляем описание к таблицам БД, и они отображаются на страницах админки.

Если кто-то хочет попинать велосипед - не стесняйтесь ;)

Адрес file:// открывается браузером только в двух случаях.
1. Если это адрес открываемой страницы (непосредственно пользователем открываемой, через меню "открыть" или вбиванием адреса в адресную строку).
2. Если этот адрес - ссылка на странице, имеющей адрес file://
Любые другие варианты считаются небезопасными по умолчанию, и без специально выполненной пользователем перенастройки браузера работать не будут.

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

Берите CMS с фреймворком под капотом и не пытайтесь создать вселенную за семь дней. Если, конечно, ваша цель - не обучение, болезненное и убыточное.

P.S. Оптимизация самопальной соцсети под высокую нагрузку (при статистике провалов таких проектов практически 100%) - это что-то вроде эргономики нижней стороны туалетного сиденья. Может быть очень увлекательно, но никогда не будет полезно.

$col_article      = intval( $col_article );
$col_name      = intval( $col_name );

if($col_article == 0) {
  $col_article = "";
}
if($col_name == 0) {
  $col_name = "";
}

foreach(['col_article', 'col_name'] as $field) {
  $$field = (int) $$field;
  if($$field === 0) $$field = '';
}

$sql = "SELECT searchArticle and brand from `dk_prices` where searchArticle = ?s and brand = ?s";
    $result = $db->query($sql, $articleSearch, $brand);
    if(mysqli_num_rows($result) > 0) {
      $sql = "UPDATE `dk_prices` SET ?u WHERE searchArticle = ?s and brand = ?s";

INSERT INTO dk_prices SET ?u ON DUPLICATE KEY UPDATE ...