Кеш не будет перестраиваться чаще чем раз в 5 минут, даже если будут изменения. Собственно там же написано прямо об этом.

Это строго говоря, не две отдельные альтернативы.
Лучше посылать через нормально настроенный почтовик, работающий в нужном домене по smtp.
В вашем случае, это должен быть, вероятно, почтовик вашего хостера, и аккаунт на нём с нужным email, тем же, что указан в from.

Надо проверить почтовик каким-нибудь https://www.mail-tester.com/ Может быть, он коряво настроен, или нет ptr/dkim/spf/dmarc.

Если используется https, всё ок - трафик зашифрован, и даже если будет перехвачен на vpn не важно, но это если это именно vpn, а не https прокси - там трафик можно подслушивать.

Основная проблема бесплатных VPN это отвратительная скорость.

Блокируются скорее всего не домены, а диапазоны ip. Хотя бы из-за постоянных взаимных атак.
На нашей стороне, как тут уже писали ограничений нет, и особо предпринять мы ничего не можем - тут не домен понадобится а зеркало где-то вовне держать постоянно.
Ну и проблема не "за пределами РФ", а фактически только на Украине должна проявляться. Например, из Голландии, Англии, Германии, никаких проблем с доступом у меня, например, нет.

В ~.composer/vendor/bin будет симлинк на ../drush/drush/drush так что композеры одинаковы, конечно.
Но делать алиас, разумнее на тот, что в vendor/bin.

Надо убедиться, чтобы директория куда делаются бекапы не была публично доступна извне и почитать о настройке в документации модуля.

PMA, как и какой-нибудь Аdminer, это не хорошие и удобные инструмены, а костыли, придуманные для шаред хостингов, где иначе было не дать доступ к базе. Хорошие и удобные инструменты, не запускаются в окружении веб сервера, а являются mysql клиентами, и соответственно не страдают проблемами с объёмом дампов или таймаутами веб интерфейса.

Почему не работает? Судя по ошибке, есть два варианта:

• не скачалось что-то.
• нет пути до /usr/local/bin в PATH.

Для начала, стоит проверить первое: ls -l /usr/local/bin

На drupal.ru, который тут кстати плохой пример, т.к. охват аудитории довольно широк, также на него не редко заходят и в рабочее время, и зависимость посещаемости от времени одна из наиболее ровных, из тех сайтов, по которым у меня есть информация, следующие данные по соотношению минимума/максимума запросов:
RPH (запросы по часам): 1/1.74
RPM (по минутам): 1/6.6
RPS (по секундам): 1/24 на самом деле от 0 до 24.

Данные напрямую из логов за вчера.

1. Это не совсем так. В реальном использовании так не будет. Точнее так будет только тогда, когда ресурсов выделено существенно больше чем надо или только в то время, когда посещаемость будет очень низкой. И на ceo будет влиять не эта идеальная величина, а скорость ответа средняя под параллельной нагрузкой, именно и за неё и нужно бороться.

Этот метод подходит для сравнения, а не как какой-то синтетически бенчмарк выдающий какую то цификру "производительность", которая обычно бесполезна чуть более чем полностью...
И в зависимости от того, что мы хотим сравнить надо выбирать нужную страницу, и отключать кеширование, если надо сравнивать полноценно генерацию страниц.
Ну и конечно не -c 1 - это не имеет смысла почти никогда. Кроме процессора есть ещё настройки - количество обработчиков, например. Есть хранилище где может быть ограничение iops.

С производительностью веб приложений всё концептуально намного сложнее.

Даже если подходить максимально просто, есть по меньшей мере две метрики:
- Время исполнения отдельного запроса, которое тут измеряется.
- Количество запросов в единицу времени, которое может обработать сервер.

batulin wrote: proxy_busy_buffers_size 512k;
proxy_buffers 4 512k;
proxy_buffer_size 256k;

Это не те буферы, которые вам нужны. Ну и слишком много.

batulin wrote: proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;

И это не те таймауты, кстати, которые нужно тут использовать. Ну и в целом это очень большие значения, так делать не стоит.

fastcgi_buffers суммарно должны быть больше fastcgi_buffer_size. Но там другая уже ошибка будет, если это не так.

Вот приложить конфиг идея очень хорошая.

Ещё раз. Выбор "редактирование в основной теме" или "редактирование в теме админки" это настройка её можно поменять. Сама по себе она не меняется. Находится тут: /admin/appearance внизу.

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

Какое именно значение в nginx 128к или 128? На всякий случай, без суффиксов оно в байтах.

Т.е. редактировалось раньше в основной теме, а после переключения на редактирование в теме админки появилась проблема? Если да, то это не "случилось". Есть такая настройка и её кто-то изменил.

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

Тема административная какая-то стандартная?

Ошибка та же? До какого размера увеличили? Перезагрузить nginx не забыли?

В отладчике браузера, например.

Надо увеличить fastcgi_buffer_size в настройках nginx. По умолчанию он равен 4kb, что вообще довольно не мало для того, чтобы вместить заголовки...

Так что стоит после решения задачи посмотреть, что же там за заголовки такие могучие...

Тут уже лучшее решение, скорее, выпускать не RSA ключи - там нет этой проблемы. А вот во внешних механизмах, может быть даже бОльшая.

Это если sftp с chroot, а если shell link, или без chroot, то всё же в корень.

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

И чем же, вдруг, хуже использовать встроенный механизм шифрования ключа, чем зашифрованный раздел или внешние средства какие-то? Кстати, ssh agent интегрируется с разными gnome-keyring, keepass и массой других решений. Пароли совсем не обязательно запоминать уж прямо пачками чтобы с этим работать.

Я думаю, что на вопрос в таком виде, вам никто не ответит, потому, что большая часть вопроса где-то у вас в голове, и не попала, судя по всему на страничку, а на телепатию надеяться не стоит.

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