Konfiguracja strażnika plików
Pierwsze ujęcie: utworzenie stanu
Przy pierwszym uruchomieniu nie ma czego porównywać — przebieg zakłada zamiast tego stan: do każdego pliku sumę kontrolną (sha256, tam gdzie PHP ją udostępnia, w innym razie md5), a do tego rozmiar, czas zmiany i obszar. Dzieje się to porcjami, fabrycznie do 400 plików lub 5 sekund na krok; okno możesz zamknąć i pojechać dalej później. Wartości procentowej przy pierwszym ujęciu nie ma, bo łącznej liczby jeszcze nikt nie zna — pokazywane są odczytane pliki i otwarte katalogi. Ważne na wstępie: strażnik zapamiętuje to, co zastanie, i uznaje to za prawidłowe. Jeżeli nie masz pewności co do instalacji, uruchom wcześniej kontrolę integralności plików (rdzeń względem WordPress.org) oraz skanowanie złośliwego oprogramowania. Po przeprowadzce lub po przywróceniu czystą drogą jest „Odrzuć stan”: wszystkie sumy kontrolne i ustalenia przepadają, a następny przebieg tworzy ujęcie na nowo. Tego nie da się cofnąć.
Co jest sprawdzane — a co nie
Sprawdzane jest drzewo od katalogu WordPressa. Jeżeli u twojego dostawcy hostingu wp-content albo katalog wtyczek leży poza nim, dochodzi jako własny korzeń i dostaje w widoku własny przedrostek. Plik wp-config.php leżący poziom wyżej niż instalacja zostaje przejęty jako nazwany plik pojedynczy i sprawdzany na początku każdego przebiegu jako pierwszy — samego katalogu nadrzędnego celowo się nie przeszukuje, u większości dostawców leżą tam obce instalacje i kopie zapasowe. Fabrycznie wykluczone są katalog uploads i 15 wbudowanych wzorców pamięci podręcznej, plików tymczasowych i protokołów (między innymi wp-content/cache, wp-content/upgrade, node_modules, .git, *.log); oba przełączniki możesz wyłączyć, wtedy przebieg trwa dłużej, a każde przesłanie obrazu tworzy ustalenie. Własne wzorce uzupełniasz na liście wykluczeń: do 100 wpisów, każdy najwyżej 200 znaków. Wzorzec bez ukośnika trafia w każdy odcinek ścieżki o tej nazwie, wzorzec z ukośnikiem jest zakotwiczony w korzeniu, * obowiązuje wewnątrz jednego odcinka. Wzorzec, który pasuje do wszystkich przykładowych ścieżek, zostaje odrzucony — wyłączyłby nadzór tak, że nie byłoby tego po liście widać. Przy wpisywaniu liczone i pokazywane jest, ile plików bieżącego stanu pod niego podpada. Nie są czytane pliki powyżej granicy rozmiaru (fabrycznie 16 MB, do ustawienia od 1 do 512), pliki nieczytelne i wszystko za dowiązaniem symbolicznym — te przypadki stoją jako osobne liczby w wyniku i wyraźnie nie liczą się jako „brakuje”.
Odczytywanie i stosowanie ustaleń
Są trzy rodzaje: zmieniony, nowy, brakuje. Do każdego pliku stoi na liście najwyżej jedno otwarte ustalenie, z pierwszym stwierdzeniem, ostatnim stwierdzeniem i licznikiem. Porównanie następuje względem ostatnio potwierdzonego stanu, a nie względem ostatniego przebiegu — dlatego ustalenie zostaje, dopóki go nie zastosujesz. Jeżeli treść sama z siebie znów zgodzi się ze stanem (aktualizacja cofnięta, plik odtworzony), ustalenie znika; zgłoszony nowy plik, którego już nie ma, zostaje zapisany ze ścieżką w dzienniku aktywności, zamiast zniknąć po cichu. „Zastosuj stan” pokazuje wcześniej, co by się stało, a potem pracuje blokami po 500: zmienione pliki dostają swoją nową sumę kontrolną, nowe dochodzą, brakujące wypadają. W samych plikach nic się nie zmienia — ale stara suma kontrolna po tym przepada, więc obejrzyj wszystko, czego nie potrafisz wyjaśnić, zanim naciśniesz. Do archiwum służy eksport CSV z maksymalnie 2000 otwartymi ustaleniami wraz ze starą i nową sumą kontrolną. Dwie granice warto znać: powyżej 3000 otwartych ustaleń liczenie trwa dalej, ale nic już nie jest zapisywane (interfejs to mówi), a z historii zostaje 500 najnowszych zastosowanych ustaleń. Przerwany przebieg nie ustala brakujących plików — do tego potrzebny jest pełny przebieg.
Natychmiastowe powiadomienie przy wrażliwych plikach
Fabrycznie włączone. „Wrażliwy” nie znaczy tu „ważny”, lecz: kto może zmienić ten plik, wykonuje własny kod albo dociera do danych dostępowych. To wp-config.php, konfiguracje serwera (.htaccess, .htpasswd, .user.ini, php.ini, web.config), drop-iny (db.php, object-cache.php, advanced-cache.php, sunrise.php i pokrewne), mu-plugins oraz pliki PHP w miejscach, w których żadnych leżeć nie powinno: w katalogu uploads, w katalogu głównym WordPressa i w wp-content poza plugins i themes. Te powiadomienia wychodzą na końcu każdej porcji, a nie dopiero na końcu przebiegu — przy dużej instalacji leżą między nimi godziny. Minimalny odstęp wynosi fabrycznie 15 minut (do ustawienia od 0 do 1440); to, co dojdzie w tym czasie, jest zbierane i wychodzi z następnym powiadomieniem, nic nie ginie. Jedno powiadomienie wymienia najwyżej 200 wpisów, resztę podaje jako liczbę. Na końcu przebiegu i przy przerwaniu reszta zostaje opróżniona bez względu na odstęp. Sprawdź raz drogę powiadomieniem próbnym: mówi ono wprost, czy wp_mail() przyjęło, czy odrzuciło wiadomość — o tym, czy zostanie ona doręczona, decyduje serwer stojący dalej. Własne wzorce możesz dodatkowo wpisać jako wrażliwe; otwarte ustalenia są przy tym natychmiast klasyfikowane na nowo, żeby lista nie pokazywała dwóch prawd.
Automatyka i harmonogram
Fabrycznie przebieg rusza tylko wtedy, gdy sam go uruchomisz. Po włączeniu automatyki wybierasz między co godzinę, dwa razy dziennie, codziennie (domyślnie) i co tydzień. Pierwszy termin leży celowo 5 minut w przyszłości, żeby przebieg nie ruszył w środku twojej pracy w zapleczu. Liczone jest od początku ostatniego przebiegu, z 5 minutami tolerancji — inaczej długi przebieg odbywałby się za każdym razem rzadziej. Cron przerabia te same porcje i planuje się na nowo co 30 sekund, dopóki coś jest otwarte; jeżeli akurat sam jedziesz w przeglądarce, czeka 120 sekund i nie sięga po kierownicę. Dwóch kierowców przy tym samym zleceniu wyklucza token, który wędruje dalej z każdą odpowiedzią; blokada wygasa po 60 sekundach, żeby zatrzaśnięta przeglądarka nie blokowała zlecenia na stałe. Jeżeli w twojej instalacji ustawiono DISABLE_WP_CRON, komunikat przy włączaniu mówi ci, że przebieg wystartuje tylko wtedy, gdy wp-cron.php zostanie wywołany z zewnątrz — czyli gdy skonfigurowano zadanie cron na serwerze.