Ściągasz paczkę, rozpakowujesz, wypełniasz formularz w przeglądarce. Klasyczna instalacja WordPressa, jak to opisane w większości takich tutoriali.

Problem zaczyna się później. Aktualizacja pluginów? Klikanie. Zmiana hasła admina? Klikanie. Nowy motyw? Zgadnij. A jeśli stron na serwerze masz kilka, to tego klikania robi się naprawdę sporo.

wp-cli pozwala zrobić to wszystko z terminala, zwykle jedną komendą. Kto raz spróbował, rzadko wraca do panelu.

Na Mikrusie#

W NOOBS-ie jest gotowy skrypt, który stawia cały stos LAMP (Apache, MySQL/MariaDB, PHP), instaluje wp-cli i od razu zakłada bazę danych oraz konfigurację WordPressa:

curl -s https://noobs.mikr.us | bash
sudo /opt/noobs/scripts/chce_wordpress.sh

Uzbrój się w cierpliwość. Jeśli nie masz jeszcze LAMP-a, skrypt najpierw go postawi, a to oznacza całkiem sporo pakietów, w tym PHP z dodatkowego repozytorium. Kilka minut to normalka. Nie przerywaj w połowie.

Skrypt kończy pracę na etapie gotowej konfiguracji. WordPress czeka pod /var/www/html/wp, a instalację dokończysz albo w przeglądarce (pod adresem swojego serwera), albo przez wp-cli, tak jak w następnej sekcji.

Na dowolnym serwerze (Ubuntu/Debian)#

Wersja ręczna. Zakładam, że masz już postawiony Apache albo nginx, PHP i MySQL/MariaDB. Działa tak samo na Mikrusie i na każdym innym VPS-ie:

sudo curl -o /usr/local/bin/wp https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
sudo chmod +x /usr/local/bin/wp

Szybki test:

wp --version

Idziesz do katalogu, w którym ma zamieszkać WordPress (np. /var/www/html/wp), i ściągasz go:

cd /var/www/html/wp
wp core download --locale=pl_PL

Baza danych. wp_baza, wp_user i haslo123 podmień na własne wartości - i proszę, niech to hasło nie będzie haslo123:

mysql -uroot -e "CREATE DATABASE wp_baza; GRANT ALL ON wp_baza.* TO 'wp_user'@'localhost' IDENTIFIED BY 'haslo123'; FLUSH PRIVILEGES;"

wp-config.php wygenerujesz na podstawie tych danych:

wp config create --dbname=wp_baza --dbuser=wp_user --dbpass=haslo123 --locale=pl_PL

I kończysz instalację, bez żadnego formularza w przeglądarce. Adres, tytuł i dane admina zmień na swoje:

wp core install --url=https://twoja-domena.pl --title="Moja strona" --admin_user=admin --admin_password=zmien-to-haslo --admin_email=[email protected]

Jedna rzecz, na którą nadziewa się prawie każdy. Jeśli odpalasz wp jako root (a na Mikrusie po zalogowaniu zwykle nim jesteś), każda z tych komend potrzebuje dodatkowo --allow-root. wp-cli domyślnie odmawia pracy na roocie, żeby pliki WordPressa nie wylądowały z właścicielem root zamiast www-data.

Zarządzanie pluginami z linii poleceń#

Lista pluginów i informacja, które mają czekające aktualizacje:

wp plugin list

Instalacja i od razu aktywacja nowego pluginu, np. Akismeta:

wp plugin install akismet --activate

Aktualizacja jednego pluginu:

wp plugin update akismet

A teraz gwóźdź programu. Wszystkie pluginy naraz, jedną komendą, zamiast klikania “Aktualizuj” przy każdym po kolei:

wp plugin update --all

Wyłączenie pluginu bez usuwania. Bezcenne, gdy strona się sypie i podejrzewasz, że to jego sprawka:

wp plugin deactivate akismet

Aktualizacja samego WordPressa#

Czy jest nowsza wersja?

wp core check-update

Aktualizacja do najnowszej:

wp core update

Czasem po aktualizacji trzeba jeszcze podnieść strukturę bazy danych:

wp core update-db

Automatyzacja aktualizacji przez cron#

Kto pamięta o aktualizacjach? No właśnie. Dlatego niech pamięta cron. Poniżej cotygodniowa aktualizacja pluginów, w niedzielę o 4:00.

Zadanie wrzucamy do crontaba użytkownika www-data, nie roota. Z --allow-root nowe pliki pluginów dostałyby właściciela root i WordPress nie mógłby ich potem sam aktualizować ani usuwać. www-data nie ma też prawa pisać do /var/log, więc plik na logi zakładamy wcześniej:

sudo touch /var/log/wp-update.log
sudo chown www-data:www-data /var/log/wp-update.log
sudo crontab -u www-data -e

0 4 * * 0 /usr/local/bin/wp plugin update --all --path=/var/www/html/wp >> /var/log/wp-update.log 2>&1

Tylko nie popadaj w hurraoptymizm. Aktualizacje pluginów bez nadzoru mają swoją ciemną stronę: raz na jakiś czas któraś coś na stronie rozwali. Jeśli strona jest dla Ciebie naprawdę ważna i przestój boli, rób to ręcznie, a wcześniej zrób backup bazy i plików.

Najczęstsze błędy#

Error: YIKES! It looks like you're running this as root. wp-cli nie lubi roota. Dodaj --allow-root albo, co jest lepszym pomysłem, odpalaj komendy jako www-data: sudo -u www-data wp plugin list --path=/var/www/html/wp.

Error: Could not connect to database. Porównaj dane w wp-config.php (nazwa bazy, użytkownik, hasło) z tym, co naprawdę założyłeś w MySQL/MariaDB. I sprawdź, czy baza w ogóle działa: systemctl status mariadb.

Po wp core update strona wygląda na zepsutą. Niemal zawsze brakuje wp core update-db. Patrz wyżej.

Automatyczna aktualizacja pluginu położyła stronę. Dlatego cron z aktualizacjami zawsze warto łączyć z regularnym backupem. Założenie, że nic się nigdy nie zepsuje, jest bardzo optymistyczne.

Od teraz WordPressem zarządzasz równie szybko, jak go postawiłeś. Bez przeklikiwania się przez panel przy każdej drobnostce.