Ставить WordPress руками — занятие на полтора часа: веб‑сервер, PHP с десятком расширений, база данных, конфиг Nginx, права на файлы, лимиты загрузки, сертификат. Я устал повторять этот ритуал и собрал скрипт, который делает всё сам и спрашивает только то, что действительно зависит от меня.

Итог, к которому мы придём: работающий сайт с настроенной админкой, ЧПУ‑ссылками, русской локализацией, при желании — с сертификатом Let’s Encrypt, phpMyAdmin и защитой от подбора паролей. Все доступы будут лежать в одном файле на сервере.

Начальные требования

Сервер. VPS с Ubuntu 20.04, 22.04, 24.04 или новее. Debian 11/12 тоже подойдёт. Памяти — от 1 ГБ; на 512 МБ WordPress запустится, но MariaDB будет тесно.

Доступ root. Или пользователь с sudo. Скрипт ставит пакеты и правит системные конфиги, без этого никак.

Желательно чистый сервер. Скрипт аккуратен: если Nginx, PHP или MariaDB уже стоят, он их использует, а не переустанавливает. Но если там уже крутится сайт на 80-м порту, конфликты возможны.

Домен — по желанию. Можно поставить сайт на IP‑адрес и привязать домен потом. Но если хотите сертификат Let’s Encrypt сразу, домен уже должен быть направлен на этот сервер A‑записью: центр сертификации проверяет это по HTTP, и на IP‑адрес сертификаты не выдаются в принципе.

Шаг 1. Скачиваем скрипт

Подключаемся к серверу по SSH и забираем проект:

apt update && apt install -y git
git clone https://github.com/perov4265-web/wp.git
cd wp

Если git ставить не хочется — можно архивом, тоже без авторизации:

curl -fsSL https://github.com/perov4265-web/wp/archive/refs/heads/main.tar.gz | tar -xz
cd wp-main

Небольшая, но частая мелочь: если вы скачали проект zip‑архивом и распаковали его в Windows, а потом залили на сервер, бит выполнения теряется, и запуск отвечает «Permission denied». Лечится одной командой — chmod +x install.sh — или запуском через интерпретатор: sudo bash install.sh.

Шаг 2. Запуск скрипта

Доступ root:

./install.sh

Пользователь с sudo

sudo ./install.sh

Скрипт проверит систему и покажет, что собирается делать.

Дальше идут вопросы в диалоговых окнах. Управление привычное для консольных установщиков: Tab — переход между полем и кнопками, стрелки — выбор пункта меню, пробел — отметить галочку, Enter — подтвердить. Мышь не нужна.

Если в системе нет whiptail, скрипт поставит его сам. А если поставить не выйдет — те же вопросы будут заданы обычным текстом, ничего не сломается.

Шаг 3. Домен или IP сайта

Домен или IP — По умолчанию подставляется IP‑адрес сервера, если домена пока нет, просто соглашайтесь. Указанное здесь значение станет и адресом сайта, и именем каталога в /var/www/.

Название сайта — то, что увидят посетители в заголовке вкладки и в шапке темы. Русские буквы и пробелы можно. Потом меняется в админке в два клика, так что не мучайтесь с формулировкой.

Язык интерфейса WordPress — Языковой пакет скрипт скачает и включит сам, отдельно ничего доустанавливать не нужно.

Шаг 4. Данные администратора CMS

Логин. По умолчанию admin. Если сайт будет смотреть в интернет, лучше поменять на что‑то менее очевидное: половина ботов перебирает пароли именно к admin.

Пароль. Вводится скрыто, повторяется для проверки. Если нажать Enter, не вводя ничего, скрипт сгенерирует пароль из 20 символов сам, покажет его на экране и сохранит в файл с доступами. Я обычно так и делаю — придуманные вручную пароли всё равно хуже.

Email. Настоящий адрес. Через него WordPress восстанавливает пароль, и этот же адрес используется при выпуске сертификата — Let’s Encrypt шлёт на него предупреждения, если продление вдруг перестанет работать.

Шаг 5. База данных

Здесь можно ничего не менять: скрипт подставляет имя базы и пользователя со случайным суффиксом, а пароль генерирует. Пустой ввод на пароле — снова автогенерация.

Пара пояснений, если хочется понимать, что происходит:

Имя базы и пользователь — разные вещи. База — хранилище, пользователь — учётная запись, которой выдаются права только на эту базу. Скрипт не даёт WordPress доступ к другим базам сервера, и это правильно.

Префикс таблиц — приставка к именам таблиц, по умолчанию wp_. Смена префикса не заменяет защиту, но чуть усложняет жизнь автоматическим эксплойтам, которые бьют по известным именам таблиц. Менять его после установки — заметная морока, так что решайте сейчас.

Отдельно про важное: если база с таким именем уже существует, скрипт не станет молча её удалять. Он остановится, сообщит об этом и спросит — а перед удалением снимет дамп в /root/.

Шаг 6. Веб‑сервер, база и версия PHP

Nginx или Apache. По умолчанию Nginx: на небольшом сервере он ест меньше памяти. Apache стоит выбирать, если вы переносите сайт со старого хостинга и у вас есть свой .htaccess, который не хочется переписывать.

MariaDB, MySQL или «автоматически». Оставляйте «автоматически» — скрипт возьмёт то, что доступно в репозитории системы, а если СУБД уже установлена, подключится к ней.

Версия PHP. Пункт auto означает «версия из репозитория вашей Ubuntu»: 7.4 на 20.04, 8.1 на 22.04, 8.3 на 24.04. Это самый безопасный вариант — такие пакеты получают обновления безопасности вместе с системой. Конкретную версию стоит выбирать, только если её требует ваша тема или плагин; если её нет в репозитории, скрипт предложит подключить сторонний PPA и спросит разрешения.

Шаг 7. Лимиты PHP

Два параметра, из‑за которых WordPress ломается чаще всего.

upload_max_filesize — максимальный размер файла, который можно загрузить через админку. По умолчанию в PHP стоит 2 МБ, и именно поэтому не устанавливается купленная тема на 40 МБ. Для обычного сайта хватает 128 МБ, для сайта с видео — берите больше.

Про то, что размер запроса должен быть больше размера файла, можно не думать: скрипт сам ставит post_max_size вдвое больше выбранного значения и подтягивает лимит памяти, чтобы он не оказался меньше. Заодно тот же лимит прописывается в конфиг Nginx — иначе веб‑сервер отрезал бы загрузку раньше, чем её увидит PHP, и вы получили бы ошибку 413.

max_input_vars — максимальное число полей в одной форме. Значение по умолчанию, 1000, приводит к очень неприятному эффекту: если полей больше, лишние отбрасываются молча. Ни ошибки, ни записи в логе. На практике это выглядит так: вы настроили меню на 60 пунктов, нажали «Сохранить», а половина пунктов пропала. Или конструктор страниц потерял настройки блока. Или у товара в WooCommerce исчезли характеристики. Для WordPress берите 3000, для магазина или тяжёлого конструктора — 5000 и выше.

memory_limit — сколько памяти может съесть один запрос PHP. 256 МБ хватает большинству сайтов, 512 МБ стоит взять для магазина или Elementor. max_execution_time — сколько секунд отводится скрипту; 300 секунд с запасом покрывают импорт демо‑контента и обновление плагинов.

Шаг 8. Дополнительные компоненты

Отмечаются пробелом, к кнопкам — Tab.

phpMyAdmin — веб‑интерфейс к базе данных по адресу ваш-сайт/phpmyadmin/. Входить в него нужно логином и паролем пользователя базы из шага 5. Удобно, но помните: это ещё одна публично доступная точка входа. Если она вам не нужна постоянно, лучше не ставить.

SSL Let’s Encrypt — бесплатный сертификат, выпускается сразу и продлевается автоматически. Требования: домен (не IP), A‑запись уже указывает на этот сервер, порт 80 открыт. Если не получится — установка не прервётся, скрипт просто предупредит и оставит сайт на HTTP.

Брандмауэр — UFW оставляет открытыми только 22, 80 и 443 порты, а fail2ban блокирует тех, кто перебирает пароли к wp-login.php. Осторожно, если вы ходите на сервер по нестандартному порту SSH: правило открывает стандартный 22-й, и стоит добавить свой порт вручную до включения.

Шаг 9. Проверяем и запускаем

Последний экран перед работой. Это единственная точка, где можно передумать без последствий: до этого момента в системе ничего не менялось.

Шаг 10. Установка

Установка занимает всё это от двух до семи минут — в основном зависит от скорости, с которой сервер качает пакеты. Дольше всего идут первый этап (apt ставит Nginx, PHP и MariaDB) и загрузка самого WordPress.

Подробности никуда не деваются — весь вывод команд пишется в журнал /var/log/wp-autoinstall.log. Если что‑то пойдёт не так, скрипт остановится и сам покажет последние строки оттуда.

После установки

В конце скрипт показывает адрес сайта, адрес админки, логин и пароль. Те же данные, плюс доступы к базе и список путей, он кладёт в файл в домашнем каталоге root с правами 600:

sudo cat /root/wp-shop.example.com-credentials.txt

Скопируйте его содержимое в свой менеджер паролей и удалите(!!!!!!!!) файл с сервера — он больше не нужен.

Теперь стоит проверить три вещи:

1. Сайт открывается из адресной строки. Если ставили с сертификатом — в адресной строке https и замок.

2. Админка пускает по логину и паролю из файла.

3. Загрузка файлов работает. «Медиафайлы → Добавить новый» — под полем загрузки написан максимальный размер. Там должно быть то значение, которое вы выбрали на шаге 7.

Где что лежит, если понадобится:

/var/www/ДОМЕН/                        файлы сайта
/etc/nginx/sites-available/ДОМЕН.conf  конфиг веб-сервера
/etc/php/ВЕРСИЯ/fpm/conf.d/99-wordpress.ini   лимиты PHP
/root/wp-ДОМЕН-credentials.txt         доступы
/var/log/wp-autoinstall.log            журнал установки

FAQ по ошибкам

«Permission denied» при запуске. Потерян бит выполнения: sudo bash install.sh или chmod +x install.sh.

Сертификат не выпустился. Скрипт предупредит и продолжит установку. Проверьте, что A‑запись домена указывает на этот сервер (dig +short ваш-домен) и что порт 80 не закрыт хостером. Потом повторите вручную: sudo certbot --nginx -d ваш-домен.

Скрипт говорит, что база уже существует. Значит, вы ставите второй сайт с тем же именем базы или переустанавливаете поверх старого. Выберите другое имя (--db-name) или согласитесь на удаление — дамп старой базы всё равно сохранится в /root/.

Nginx не запускается: порт занят. На сервере уже что‑то слушает 80-й порт — чаще всего Apache. Скрипт предупреждает об этом и останавливает конкурента, но если там работает чужой сайт, разбирайтесь до установки.

Окна не рисуются, вопросы идут текстом. Это не поломка: значит, whiptail не установился. Вопросы те же, ответы вводятся с клавиатуры, пункты меню выбираются по номеру.

Что‑то упало без объяснений. Смотрите журнал — там весь вывод команд:

sudo tail -n 50 /var/log/wp-autoinstall.log

Удаление сайта

Если это была проба и сайт больше не нужен:

sudo ./uninstall.sh --domain shop.example.com --db-name wp_shop --db-user wpuser_a4f1

Скрипт заархивирует каталог сайта, снимет дамп базы, положит обе копии в /root/ и уберёт конфиги веб‑сервера. Пакеты — Nginx, PHP, MariaDB — он не трогает: они могут быть нужны другим сайтам.

P/s

Полтора часа ручной работы превращаются в десяток вопросов и несколько минут ожидания. Скрипт открытый, лежит на GitHub под MIT.

Если будете пробовать — напишите, на какой Ubuntu и с какой конфигурацией запускали. Самые интересные ошибки всегда находятся на чужих серверах.