Игорь Воротнёв

Храните где удобнее, здесь нет каких-то жестких ограничений. Конфиг конкретного проекта может лежать в папке проекта, в вашем домашнем каталоге, в /etc/nginx/conf.d или /etc/nginx/sites-available - где вам больше нравится. И это абсолютно нормально подключать их из основного конфига - собственно, стандартная конфигурация по умолчанию именно это и делает - подключает все конфиги из папки conf.d.

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

Если есть желание оставаться в нише WordPress и развиваться дальше c возможным ростом и по деньгам - vanilla JavaScript и современные практики в нем, React (потому что Gutenberg). Ну и, конечно же, больше правильного PHP.

Если совсем по полочкам раскладывать, то:

- Ваша строчка 9 проверяет не равны ли captcha в $_POST и rand_code в $_SESSION.
- Ваша строчка никак не проверяет, чтобы эти переменные существовали / были определены, поэтому когда их нет - PHP информирует вас об этом (Notice) - прямым текстом говорит, что в упомянутых массивах нет таких индексов (элементов).
- Чтобы устранить PHP Notice, необходимо всегда проверять, заданы ли необходимые переменные:

1. В самом простом случае:

if ( 
    ( isset( $_POST['captcha'] ) && isset( $_SESSION['rand_code'] ) ) // переменные / индексы определены
    && $_POST['captcha'] != $_SESSION['rand_code'] // собственно, сравнение значений
) {
    // остальной код
}

2. В реальных условиях чаще всего это происходит в контексте функций / методов и когда идет ряд проверок, принято использовать подход "fail early" (вариации - quit early, bail out early) – проверки идут не вложенными, а одна за одной, наиболее ожидаемые - первыми. Пример аналогичного фрагмента кода с учетом этой практики:

function some_method_name() {

    // Если индексы не существуют или они приводятся к false - выходим из логики
    if ( empty( $_POST['captcha'] ) || empty( $_SESSION['rand_code'] ) ) {
        return; // может быть return false и тд - зависит от конкретной реализации
    }

    // Этот код выполнится только если предыдущая проверка прошла успешно и оба индекса имеют значения с которыми можно работать дальше
    if ( $_POST['captcha'] != $_SESSION['rand_code'] ) {
        // остальной код
    }
}

Теоретически конечно могут возникать ситуации, когда и бек, и фронт, лезут редактировать одно и то же место, в одном и том же файле, плюс-минус в одно и то же время. Что может приводить к merge conflicts.

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

Поэтому, лично я не вижу никакой проблемы в том, что работа идет в feature branches, каждый делает свою часть, а потом это все мерджится.

Есть вот такой шикарный сервис - https://apex.sh/ping/
Правда, сейчас там уже нет бесплатных аккаунтов, но если подходить к делу серьезно, то этот сервис стоит каждый доллар. Есть много аналогичных сервисов, гугл в помощь. У многих есть базовые бесплатные аккаунты.

Для более серьезного мониторинга и анализа на стороне бекенда есть https://newrelic.com

Базовые показатели скорости загрузки можно отслеживать и с помощью Google Analytics. Отдельно можно отслеживать только аптайм, например, с помощью https://uptimerobot.com

Вам нужна поддержка .env. Лично я активно использую Composer в разработке под WP, для этих целей есть package "vlucas/phpdotenv" (небольшой урок). Насколько мне известно, обычным wp-плагином это невозможно сделать, так как поддержка .env должна быть доступна на уровне конфига, задолго до события "plugins_loaded".