Ставить 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 gitgit clone https://github.com/perov4265-web/wp.gitcd wp
Если git ставить не хочется — можно архивом, тоже без авторизации:
curl -fsSL https://github.com/perov4265-web/wp/archive/refs/heads/main.tar.gz | tar -xzcd 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
Скопируйте его содержимое в свой менеджер паролей и удалите(!!!!!!!!) файл с сервера — он больше не нужен.
Теперь стоит проверить три вещи:
-
Сайт открывается из адресной строки. Если ставили с сертификатом — в адресной строке https и замок.
-
Админка пускает по логину и паролю из файла.
-
Загрузка файлов работает. «Медиафайлы → Добавить новый» — под полем загрузки написан максимальный размер. Там должно быть то значение, которое вы выбрали на шаге 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 и с какой конфигурацией запускали. Самые интересные ошибки всегда находятся на чужих серверах.
ссылка на оригинал статьи https://habr.com/ru/articles/1074686/