Jak zautomatyzować WordPressa: cron, WP-CLI i własne skrypty krok po kroku

Od czego zacząć: czy w ogóle automatyzować WordPressa cronem i WP-CLI?

Kluczowe pytanie: czy Twój WordPress potrzebuje prawdziwej automatyzacji?

Pierwszy krok to decyzja, czy rzeczywiście warto inwestować czas w cron, WP-CLI i własne skrypty. Jeśli utrzymujesz małego bloga z kilkunastoma wpisami i logujesz się raz w tygodniu, by ręcznie zrobić aktualizacje i backup, rozbudowana automatyzacja może być przerostem formy nad treścią. Natomiast przy sklepie WooCommerce, serwisie z ruchem 24/7, czy przy kilku–kilkunastu stronach, ręczne klikanie szybko zamienia się w ryzyko i stratę czasu.

Najczęściej automatyzuje się:

• aktualizacje WordPressa, wtyczek i motywów,
• regularne backupy bazy i plików,
• czyszczenie cache, transientów i starych danych,
• zadania WooCommerce (eksport zamówień, synchronizacja stanów, generowanie raportów),
• zadania integracyjne (np. wysyłka danych do CRM, marketing automation).

Jeśli robisz coś z tej listy częściej niż raz w tygodniu, a każde zadanie można opisać jako powtarzalną sekwencję kroków, masz dobrego kandydata do automatyzacji cronem i WP-CLI.

Wp-cron vs systemowy cron – kiedy który wybrać?

WordPress ma własny mechanizm pseudo-crona: wp-cron. Działa on tylko wtedy, gdy ktoś wejdzie na stronę – podczas requestu PHP sprawdzane są zaplanowane zadania i ewentualnie odpalane w tle. To wygodne, ale ma ograniczenia. Gdy ruch jest mały, zadania odpalają się z opóźnieniem. Gdy ruch jest duży – nadmiar równoległych wywołań wp-cron potrafi obciążyć serwer.

Systemowy cron (crontab w Linuxie, Harmonogram zadań w Windows) działa niezależnie od ruchu. O ustalonej godzinie wywoła konkretny skrypt lub komendę, także nocą, gdy nikt nie korzysta z witryny. To daje stabilność i przewidywalność, ale wymaga dostępu do serwera i podstawowej znajomości konsoli.

Jeśli obsługujesz sklep, integracje zewnętrzne, generujesz raporty lub bazujesz na precyzyjnych godzinach (np. zamknięcie sprzedaży o 23:59), systemowy cron jest praktycznie obowiązkowy. Przy hobbystycznym blogu z kilkoma zadaniami raz dziennie spokojnie można zostać przy wp-cron, ale i tak warto wiedzieć, jakie ma ograniczenia.

Najczęstsze pytania i obawy przed automatyzacją

Wokół automatyzacji WordPressa krąży kilka powtarzających się pytań:

• Czy cron może „popsuć” stronę? – sam cron nie, ale źle napisany skrypt lub aktualizacja bez backupu jak najbardziej. Dlatego procedura musi mieć testy i kopie zapasowe.
• Czy WP-CLI jest bezpieczne? – tak, o ile masz ograniczony dostęp SSH, nie udostępniasz WP-CLI przez HTTP i nie wykonujesz komend jako root bez potrzeby.
• Co jeśli zmieni się hosting lub ścieżka do PHP? – linie w crontab mogą się zdezaktualizować. Po migracji zawsze weryfikuj ścieżki i wersje PHP.
• Skąd mam wiedzieć, że zadanie się wykonało? – każde poważniejsze zadanie powinno logować wynik do pliku i/lub wysyłać powiadomienie mailowe przy błędzie.

Automatyzacja WordPressa nie jest „magiczna”. To po prostu zestaw powtarzalnych poleceń odpalanych o konkretnych godzinach. Główne ryzyko leży w treści tych poleceń i braku nadzoru, a nie w samym cronie.

Krok 1: decyzja wp-cron czy systemowy cron – konkretne kryteria

Jak ocenić, czy wystarczy wbudowany wp-cron

Wp-cron w zupełności wystarczy, jeśli:

• masz małą lub średnią stronę informacyjną bez skomplikowanych integracji,
• zadania są mało krytyczne (np. publikacja wpisów zaplanowanych, czyszczenie starych wersji wpisów),
• opóźnienie rzędu godzin przy małym ruchu nie jest problemem,
• nie odpalasz przez cron ciężkich operacji na bazie lub plikach.

Typowy przykład: blog firmowy, do którego zagląda kilkadziesiąt osób dziennie. Wp-cron będzie się uruchamiał wystarczająco często, a ewentualne opóźnienia publikacji wpisu o kilkanaście minut nie mają znaczenia biznesowego.

Kiedy przejść na prawdziwy cron na serwerze

Systemowy cron jest praktycznie konieczny, gdy:

• masz sklep WooCommerce lub inny serwis transakcyjny,
• odpalasz zadania długie (eksporty, raporty, przetwarzanie plików),
• masz wymagania co do godzin wykonania zadań (np. codziennie o 2:00),
• masz narzędzia oparte na WP-CLI (masowe operacje na danych, optymalizacja bazy),
• strona ma bardzo duży ruch i wp-cron zaczyna obciążać serwer.

Jeśli jakiekolwiek zadanie powoduje timeouty HTTP albo wymaga zwiększania limitów wykonania PHP w przeglądarce, naturalnym krokiem jest przeniesienie go do trybu CLI i wywoływanie przez cron.

Typowe pułapki przy decyzji o przejściu na systemowy cron

Najczęstsze problemy pojawiają się wtedy, gdy:

• wyłączysz wp-cron i zapomnisz włączyć systemowy cron – zadania przestają się wykonywać, ale przez kilka dni nikt tego nie zauważa,
• przeniesiesz tylko część zadań – wtyczki wciąż bazują na wp-cron, a Ty zakładasz, że wszystko jest w cronie systemowym,
• nie uwzględnisz kilku instalacji WordPressa na jednym serwerze – każda może wymagać oddzielnej linii w crontab,
• hosting blokuje cron lub ogranicza częstotliwość – część tanich hostingów pozwala na zadania co 15 lub 30 minut, a nie co 5.

Bezpieczne podejście: najpierw konfigurujesz systemowy cron i testujesz, dopiero potem wyłączasz wp-cron w konfiguracji WordPressa.

Krok 2: konfiguracja systemowego cron dla WordPressa krok po kroku

Wyłączenie wp-cron w wp-config.php

Po decyzji o przejściu na systemowy cron, trzeba wyłączyć wp-cron, aby nie dublować zadań. Robi się to jedną stałą w pliku wp-config.php:

define( 'DISABLE_WP_CRON', true );

Najbezpieczniej:

1. Zrób kopię pliku wp-config.php.
2. Dodaj powyższą linię przed komentarzem „That’s all, stop editing! Happy publishing”.
3. Zapisz plik i odśwież stronę, upewniając się, że nie pojawił się błąd PHP.

Na tym etapie nie rób tego jeszcze na produkcji, jeśli nie masz gotowego crona systemowego. Najpierw dodaj zadanie w crontab (kolejny podrozdział), przetestuj, a dopiero na końcu włącz DISABLE_WP_CRON.

Dodanie zadania cron wywołującego wp-cron.php

Najprostsza linia w crontab, która zastępuje wywołanie wp-cron przez użytkownika, wygląda następująco:

*/5 * * * * /usr/bin/php /var/www/html/wp-cron.php > /dev/null 2>&1

Co trzeba w niej zmienić:

• /usr/bin/php – ścieżka do interpretera PHP na Twoim serwerze, np. /opt/alt/php82/usr/bin/php lub /usr/local/bin/php. Sprawdzisz ją komendą which php po zalogowaniu przez SSH.
• /var/www/html/wp-cron.php – pełna ścieżka do pliku wp-cron.php w katalogu WordPressa, np. /home/uzytkownik/domains/twojadomena.pl/public_html/wp-cron.php.
• */5 * * * * – oznacza „co 5 minut”. W razie potrzeby możesz użyć np. */1 (co minutę) lub 0 * * * * (o pełnej godzinie).

Przekierowanie > /dev/null 2>&1 wyrzuca standardowe wyjście i błędy do kosza. Na etapie testów lepiej je zastąpić logowaniem do pliku:

*/5 * * * * /usr/bin/php /var/www/html/wp-cron.php >> /var/log/wp-cron.log 2>&1

Wtedy możesz na bieżąco sprawdzać postęp i ewentualne komunikaty błędów w pliku /var/log/wp-cron.log (lub innym katalogu, gdzie masz uprawnienia).

Jak poprawnie edytować crontab i nie zablokować zadań

Na większości serwerów Linux crontab użytkownika edytuje się komendą:

crontab -e

Po wpisaniu komendy:

1. Zostanie otwarty edytor (nano, vim lub inny).
2. Dodajesz linię z zadaniem na końcu pliku.
3. Zapisujesz i wychodzisz (w nano – Ctrl+O, Enter, Ctrl+X).
4. Sprawdzasz aktualny crontab:

crontab -l

Typowe pułapki:

• nadpisanie istniejących zadań – jeśli użyjesz crontab nazwa_pliku bez świadomości, że czyści to poprzednie wpisy, możesz skasować inne zadania działające na tym samym koncie,
• edytowanie crontab dla złego użytkownika – jeśli włączysz cron jako root dla ścieżek z katalogu użytkownika, mogą pojawić się problemy z uprawnieniami,
• brak nowej linii na końcu pliku – niektóre implementacje crontab bywają na to wrażliwe.

Najprostsza zasada: zawsze po edycji uruchom crontab -l i sprawdź, czy wszystkie zadania są widoczne tak, jak oczekujesz.

Krok 3: instalacja i podstawy WP-CLI – fundament automatyzacji

Instalacja WP-CLI na serwerze

WP-CLI to interfejs wiersza poleceń dla WordPressa. Pozwala robić to, co normalnie klikasz w panelu, za pomocą komend, a więc świetnie nadaje się do crona i skryptów. Standardowa instalacja na serwerze opartym na Linuxie wygląda tak:

1. Pobranie pliku phar:

   curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
   

2. Sprawdzenie, czy działa:

   php wp-cli.phar --info
   

3. Uczynienie pliku wykonywalnym i przeniesienie do katalogu w PATH:

   chmod +x wp-cli.phar
   sudo mv wp-cli.phar /usr/local/bin/wp
   

4. Weryfikacja:

   wp --info
   

Jeśli nie masz uprawnień do /usr/local/bin, możesz trzymać wp-cli.phar w katalogu domowym i wywoływać go jako php wp-cli.phar, ale do automatyzacji wygodniej jest skrócić to do samego wp.

Łączenie WP-CLI z konkretną instalacją WordPressa

WP-CLI działa „kontekstowo” – musi znaleźć plik wp-config.php, aby wiedzieć, z jaką bazą i instalacją pracuje. Standardowo:

• wchodzisz do katalogu, gdzie jest WordPress:

  cd /var/www/html
  wp plugin list
  

• lub podajesz ścieżkę za pomocą opcji --path:

  wp plugin list --path=/var/www/html
  

Przy wielu instalacjach na jednym serwerze dobrze jest unikać zgadywania ścieżki. Pomagają w tym aliasy powłoki. W pliku ~/.bashrc (lub odpowiedniku) możesz dodać wpisy w stylu:

alias wp_sklep="wp --path=/home/uzytkownik/domains/sklep.pl/public_html"
alias wp_blog="wp --path=/home/uzytkownik/domains/blog.pl/public_html"

Po ponownym wczytaniu powłoki wp_sklep plugin list zawsze trafi w dobry katalog, bez ręcznego cd. Zmniejsza to ryzyko, że przez pomyłkę wykonasz komendę na złej bazie danych, co przy operacjach typu search-replace jest wyjątkowo kosztowne.

Druga rzecz to użytkownik systemowy, z którego odpalasz WP-CLI. Jeśli cron działa na innym koncie niż to, na którym testujesz komendy, różnice w zmiennych środowiskowych (PATH, wersja PHP, uprawnienia do plików) potrafią zmienić zachowanie skryptów. Dobrym nawykiem jest uruchamianie komend testowych dokładnie w taki sposób, w jaki zrobi to cron, np.:

sudo -u www-data wp --path=/var/www/html cron event run --due-now

Jeżeli polecenie zadziała poprawnie w tej formie, jest duża szansa, że identyczna linia w crontabie będzie stabilna. Jeżeli nie – trzeba doprecyzować ścieżki, wersję PHP albo uprawnienia katalogów.

Najważniejsze komendy WP-CLI, które przydają się w automatyzacji

Żeby cron i własne skrypty miały sens, potrzebny jest zestaw „klocków”, z których je złożysz. W WordPressie tymi klockami są konkretne komendy WP-CLI. Kilka z nich wraca w praktyce najczęściej:

• Aktualizacje:

  wp core update
  wp plugin update --all
  wp theme update --all

  Taki pakiet można wpiąć w nocny cron, ale lepiej łączyć go z backupem i ograniczyć do środowiska stagingowego.

• Optymalizacja bazy:

  wp db optimize
  wp transient delete --all
  wp option delete _site_transient_timeout_*

  Cykliczne czyszczenie przejściowych danych potrafi utrzymać WordPressa w lepszej kondycji bez ręcznej ingerencji.

• Praca z mediami:

  wp media regenerate --only-missing

  Przydaje się po zmianie motywu lub wtyczki od obrazków. Lepiej odpalać w nocy, bo intensywnie obciąża dysk i CPU.

• CRON wewnątrz WordPressa:

  wp cron event list
  wp cron event run --due-now

  Druga komenda pozwala ręcznie wymusić wykonanie zaległych zadań – świetne narzędzie diagnostyczne.

• Eksport i import danych:

  wp db export /backup/wp-$(date +%F).sql
  wp db import /backup/wp-ostatni.sql

  Zestaw, na którym można oprzeć automatyczne backupy bazy danych uruchamiane przez cron.

Każdą z tych komend warto najpierw uruchomić ręcznie, zobaczyć, jak długo działa, jak obciąża serwer i dopiero wtedy wkładać ją w harmonogram crona.

Bezpieczne korzystanie z WP-CLI w cronie

Zestawiając cron z WP-CLI, najczęściej popełnia się trzy błędy: brak pełnych ścieżek, brak środowiska i brak logów. Żeby uniknąć tych pułapek, dobrze jest trzymać się kilku prostych zasad.

• Zawsze używaj pełnych ścieżek. Zamiast:

  * * * * * wp plugin update --all

  lepiej zapisać:

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

  Cron nie zna Twojego PATH z powłoki, dlatego poleganie na samym wp często kończy się błędem „command not found”.

• Loguj każde zadanie. Nawet jeśli log ma dodawać tylko kilka linijek dziennie, przy pierwszym problemie różnica jest ogromna. Bez logu można godzinami zgadywać, czy cron w ogóle się uruchamia.
• Ustal użytkownika. Jeżeli WordPress ma pliki należące do www-data, a cron chodzi na użytkowniku root lub Twoim koncie SSH, uprawnienia mogą się rozjechać. Bezpieczniej uruchamiać:

  0 2 * * * sudo -u www-data /usr/bin/php /usr/local/bin/wp ...

  o ile konfiguracja serwera na to pozwala.

Dobrą praktyką jest przygotowanie prostego „testowego” zadania, które zapisze datę i wynik w pliku logu. Jeśli to działa w cronie, kolejne komendy można dokładać dużo spokojniej.

Krok 4: własne skrypty automatyzujące WordPressa

Dlaczego nie wsadzać wszystkiego bezpośrednio do crontaba

Kuszące jest wrzucanie każdej komendy WP-CLI lub PHP jako oddzielnej linii w cronie. Przy dwóch zadaniach to jeszcze działa, ale przy kilkunastu liniach zaczyna się chaos: trudniej to dokumentować, przenosić między serwerami i debugować.

Lepszy wariant to trzymanie logiki w jednym lub kilku skryptach (bash lub PHP), a w cronie mieć tylko krótką linijkę, która ten skrypt wywoła. To ułatwia:

• wersjonowanie (skrypt w repozytorium, crontab niekoniecznie),
• testy lokalne – uruchamiasz dokładnie to samo, co serwer,
• dodawanie warunków, blokad, powiadomień mailowych.

Prosty skrypt bash do porządkowania WordPressa

Przykład prostego skryptu Bash, który wykonuje kilka zadań konserwacyjnych dla jednej instalacji WordPressa:

#!/bin/bash

WP_PATH="/var/www/html"
PHP_BIN="/usr/bin/php"
WP_BIN="/usr/local/bin/wp"
LOG="/var/log/wp-maintenance.log"
DATE=$(date '+%Y-%m-%d %H:%M:%S')

echo "=== Start: $DATE ===" >> "$LOG"

# Backup bazy
$PHP_BIN $WP_BIN db export "$WP_PATH/wp-backup-$(date +%F).sql" --path="$WP_PATH" >> "$LOG" 2>&1

# Aktualizacja wtyczek
$PHP_BIN $WP_BIN plugin update --all --path="$WP_PATH" >> "$LOG" 2>&1

# Czyszczenie przejściowych danych
$PHP_BIN $WP_BIN transient delete --all --path="$WP_PATH" >> "$LOG" 2>&1

echo "=== Koniec: $(date '+%Y-%m-%d %H:%M:%S') ===" >> "$LOG"

Taki plik (np. /usr/local/bin/wp-maintenance.sh) oznaczasz jako wykonywalny:

chmod +x /usr/local/bin/wp-maintenance.sh

a w cronie zostaje tylko jedna, czytelna linia:

0 3 * * * /usr/local/bin/wp-maintenance.sh

Zmiana ścieżki, dopięcie dodatkowego kroku czy czasowe wyłączenie jakiegoś elementu odbywa się już w jednym pliku, a nie w kilku liniach rozsianych po cronie.

Własny skrypt PHP korzystający z funkcji WordPressa

WP-CLI nie obsłuży każdego, nawet bardzo specyficznego scenariusza biznesowego. Czasem trzeba sięgnąć po dedykowany skrypt PHP, który skorzysta bezpośrednio z API WordPressa: funkcji, klas, czy hooków.

Schemat takiego pliku bywa zaskakująco prosty:

<?php
// /var/www/html/scripts/custom-task.php

// Wczytanie środowiska WordPressa
require_once dirname(__DIR__) . '/wp-load.php';

// Przykład: automatyczne publikowanie wpisów ze statusu "draft",
// które mają niestandardowe pole _auto_publish_date mniejsze niż teraz.

$query = new WP_Query([
    'post_type'      => 'post',
    'post_status'    => 'draft',
    'posts_per_page' => -1,
    'meta_query'     => [
        [
            'key'     => '_auto_publish_date',
            'value'   => current_time('mysql'),
            'compare' => '<=',
            'type'    => 'DATETIME',
        ],
    ],
]);

foreach ( $query->posts as $post ) {
    wp_update_post([
        'ID'          => $post->ID,
        'post_status' => 'publish',
    ]);
}

Żeby cron mógł taki skrypt wywołać, wystarczy linia:

*/10 * * * * /usr/bin/php /var/www/html/scripts/custom-task.php >> /var/log/wp-custom-task.log 2>&1

Kluczowe są tu pełne ścieżki i przekierowanie wyjścia do logu. Taki plik warto uruchomić z linii komend dokładnie w tej samej formie, zanim trafi do crona – łatwiej wtedy wyłapać błędy w ścieżkach, brak klas lub problemy z autoloadingiem.

Blokady (locki), żeby zadania nie nachodziły na siebie

Jedna z częstszych pułapek automatyzacji to „duplikaty” zadań: poprzednie jeszcze się wykonuje, a cron już odpala kolejne. Skutki są różne – od spadku wydajności po uszkodzenie danych. Rozwiązaniem jest prosty mechanizm blokady.

W Bashu często wystarcza plik lock w katalogu tymczasowym:

#!/bin/bash

LOCKFILE="/tmp/wp-maintenance.lock"

if [ -f "$LOCKFILE" ]; then
  echo "Zadanie już działa, wychodzę."
  exit 0
fi

trap 'rm -f "$LOCKFILE"' EXIT
touch "$LOCKFILE"

# ... właściwa logika skryptu ...

W PHP można użyć flock():

<?php
$lockFile = fopen('/tmp/wp-custom-task.lock', 'c');
if ( ! flock($lockFile, LOCK_EX | LOCK_NB) ) {
    echo "Inna instancja już działa.n";
    exit;
}

// ... kod zadania ...

flock($lockFile, LOCK_UN);
fclose($lockFile);

Jeśli zadanie z natury trwa długo (np. regeneracja miniaturek, przetwarzanie dużej liczby zamówień), mechanizm locka powinien być obowiązkowy. Bez tego pojedyncza literówka w harmonogramie (np. uruchamianie co minutę zamiast co godzinę) potrafi przeciążyć nawet dość mocny serwer.

Powiadomienia o błędach i proste alerty

Automatyzacja bez informacji zwrotnej szybko zamienia się w „czarną skrzynkę”. Minimum to powiadomienie, gdy zadanie zakończy się błędem. Prosty wariant w Bashu to wysłanie maila, jeśli komenda zwróci kod różny od zera:

#!/bin/bash

ADMIN_EMAIL="admin@example.com"

# przykład: aktualizacja wtyczek
if ! /usr/bin/php /usr/local/bin/wp plugin update --all --path=/var/www/html >> /var/log/wp-update.log 2>&1; then
  echo "Aktualizacja wtyczek zakończona błędem" | mail -s "WP CRON ERROR" "$ADMIN_EMAIL"
fi

W PHP można w podobny sposób zawinąć krytyczne fragmenty w try/catch i wysłać maila lub webhook do zewnętrznego systemu monitoringu. Jeśli nie chcesz od razu budować rozbudowanego systemu alertów, opłaca się chociaż logować wyraźne słowa-klucze (np. [ERROR], [WARN]), aby później można było je przeszukać jednym poleceniem grep.

Krok 5: kiedy wystarczy WP-Cron, a kiedy potrzebny jest systemowy cron i własne skrypty

Decyzja, na czym oprzeć automatyzację, zależy od kilku bardzo konkretnych kryteriów: skali ruchu, przewidywalności zadań i wymagań biznesowych.

Kiedy trzymać się WP-Cron i gotowych wtyczek

• Mały lub średni ruch. Jeśli strona nie musi wykonywać zadań co dokładnie 5 minut, a opóźnienie rzędu kilkunastu minut jest akceptowalne, wbudowany WP-Cron zwykle wystarcza.
• Standardowe scenariusze. Backup raz dziennie, publikacja wpisów w zaplanowanym terminie, wysyłka newslettera z popularnej wtyczki – to obszar, który wtyczki ogarniają bez dodatkowego kodu.
• Brak dostępu do crona na serwerze. Na wielu współdzielonych hostingach jedyną realną opcją jest WP-Cron. W takim przypadku lepiej skupić się na tym, żeby ruch był równomierny (np. brak długich cache’y, które blokują wykonanie zadań).

Kiedy przejść na systemowy cron

• Wymagana powtarzalność. Skrypty integrujące system płatności, synchronizujące stany magazynowe czy generujące raporty finansowe wymagają przewidywalnego harmonogramu. Jeśli zadanie musi się wykonać „co do minuty”, systemowy cron jest dużo pewniejszy.
• Ciężkie operacje. Migracje bazy, regeneracja miniaturek, hurtowe wysyłki maili – tego lepiej nie wiązać z ruchem użytkowników. Cron systemowy uruchomi je niezależnie, np. w oknie nocnym.
• Wiele serwisów na jednym serwerze. Gdy na jednym VPS działa kilka WordPressów, sens ma scentralizowane zarządzanie zadaniami z poziomu crona i wspólnych skryptów, a nie kilkanaście niezależnych WP-Cronów.

Kiedy pisać własne skrypty

Jeśli wtyczka robi „prawie wszystko, czego trzeba”, brakuje w niej zwykle właśnie automatyzacji: dodatkowego filtra, integracji z zewnętrznym API, niestandardowego kryterium. W takich sytuacjach opłaca się:

• zachować wtyczkę jako „silnik” (np. WooCommerce, wtyczka do newsletterów),
• dopisać cienką warstwę własnego kodu (skrypt PHP, mała wtyczka),
• od strony serwera spiąć to cronem lub WP-CLI.

Próg wejścia nie jest wysoki – pojedynczy plik PHP umieszczony w katalogu scripts i jeden wpis w cronie często załatwiają sprawę. Najwięcej pracy pochłania nie sam kod, lecz przemyślenie scenariuszy awaryjnych: co jeśli API zewnętrzne nie odpowiada, jeśli baza zwróci błąd, jeśli zabraknie miejsca na dysku podczas backupu.

Praktyczny schemat wdrożenia automatyzacji

Żeby uniknąć typowych wpadek, sensowny jest powtarzalny proces wdrożenia nowych zadań. W uproszczeniu może wyglądać tak:

1. Prototyp ręczny. Najpierw uruchamiasz komendy WP-CLI ręcznie lub wywołujesz skrypt PHP z linii komend, sprawdzając czas działania, logi i obciążenie.
2. Skrypt z logowaniem. Później opakowujesz te komendy w skrypt bash/PHP, który dodaje logi, proste walidacje wejścia, ewentualnie locki.
3. Test lokalny w formie „jak cron”. Uruchamiasz skrypt dokładnie tak, jak będzie to robił cron (z tym samym użytkownikiem, tą samą wersją PHP i pełnymi ścieżkami).
4. Dodanie do crona z konserwatywną częstotliwością. Lepiej zacząć od rzadszego harmonogramu i go przyspieszyć, niż zalać serwer zadaniami co minutę.
5. Monitoring pierwszych dni. Przez kilka pierwszych uruchomień warto przejrzeć logi, obciążenie serwera i efekty biznesowe (np. czy coś nie zostało zaktualizowane zbyt agresywnie).

Na jakim poziomie zatrzymać automatyzację

Automatyzacja WordPressa ma sens dopóty, dopóki zmniejsza ryzyko i oszczędza czas. Jeśli kolejne zadania zaczynają komplikować konfigurację bardziej niż rozwiązywać problemy, lepiej się zatrzymać i zadać kilka pytań:

• Czy dane zadanie rzeczywiście musi być cykliczne, czy można je uruchamiać ręcznie przy zmianach (np. regeneracja miniaturek tylko po wdrożeniu nowego motywu)?