Dmitry Bay

Убрать пробелы и переводы строк между тегами изображения и ссылки:

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

Но я предлагаю не мучаться, а просто сделать singleton-обертку над PDO
И вызывать её там где нужно нафигачить запросы к БД

class Data 
{
    public function __construct($param1, $param2)
    {
         // Получаем PDO напрямую
        $this->db = DB::getInstance();
    }

    public function example()
    {
        // $query = $this->db->query("SELECT * FROM table");
        // $query->execute();

        // $stmt = $this->db->prepare("...");
    }
}

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

Если это будет именно "форум", с разделами, темами итд, то нет, WP не очень подходит для этого. У него и дизайн не такой, и структура базы, так что допиливать придётся много. И прямо на php, не такой знакоый js-код на фронте. До кучи, допиливать придётся и плагины. Богатство WP и одновременно его ахиллесова пята - это именно плагины - без них его практически никто не использует, но их регулярно приходится доделывать под многочисленные нюансы конкретной инсталляции. А использование "не по назначению" это очень даже большой нюанс.

Если же нужно "коллективный блог", как хабр, с "хабами", они же по сути тэги постов, то WP под это допилить всяко проще. чем под форум. Но так как WP изначально индивидуальный блог, то тоже не всё так просто.

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

Что нужно сделать ДО переезда в обяательном порядке:
Разобраться с кабельным хозяйством в новом офисе.
Заманчиво, конечно, ВСЁ сделать до переезда, но вопрос с проводами решать в работающем офисе - совсем печально. А при переезде (который подобен половинке пожара :) и освоении нового офиса - ещё и менять/перенастраивать серверные решения - боюсь просто разрваться придётся.

Выяснить - что есть в новом офисе. Планируется ли там ремонт или переезжаете в существующий.
Если ремонт - требуйте в рамках ремонта новкю СКС. Из расчёта "1 раб.место о 2х порта СКС (RJ-45) на 4 кв.м офисной площади (кабинетов)" Не ведитесь на существующее количество сотрудников и "утверждённые рассадки". Сколько я их перевидел на 30 лет - все расползались за пол-года после въезда в новый офис :)

WiFi в новом офисе - планируется ли? Тогда - Плюс порты скс в коридорах, за фальш-пгтолком.
Для видеонаблюдения порты СКС и ЛВС...

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

Место для серверной выбить. На пару 19" шкафов. С возможностью поставить ещё пару. Плюс шкаф ИБП. Т.е. - квадратов от 20. Мощности электрические выбить. Про дублировнные кондеи в серверной с зимним пакетом до -30 не забыть
Помимо кабнета для сисадмина - нужна отдельная кладовка

Будет ли ВЭРС для бесперебойного питания всех компв в здании?

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

Я с трудом представляю, как документ такого объёма в рамках этого сайта обсуждать, хотя понаписал их в жизни не мало...

Никто ниче не банит. Оплачиваю через icloud

Имеет смысл делать обновление, если все работает нормально?

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

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

Всё именно так, как сказал товарищ rPman в комментарии: по умолчанию мак во время стандартного сна просыпается периодически, гонит сетевой трафик и считает что-то по мелочи. Проверьте настройки энергосбережения и сна - вроде где-то там эта фича отключается и можно включить полноценный сон.