Wraz z niedawną premierą WordPressa 5.2 (Jaco) zadebiutował też mechanizm sprawdzający stan witryny/strony, dzięki czemu nawet mniej zaawansowana osoba może w prosty sposób sprawdzić, czy strona działa prawidłowo i spełnia wszystkie wymagania WordPressa. Z naprawą/korektą w większości przypadków pewnie już tak łatwo nie będzie, i tu już może być wymagana trochę bardziej techniczna wiedza, ale zawsze od czegoś trzeba zacząć. Są jednak sytuacje, gdy niekoniecznie chcemy tego typu testem dzielić się np. z potencjalnym klientem…

Testy stanu witryny w WordPressie

Oczywiście można w takiej sytuacji przyciąć uprawnienia, ale nie zawsze będzie to możliwe. Zwłaszcza gdy klient zasłyszał gdzieś o tego typu opcji i chciałby ją zobaczyć na swojej stronie. W takim przypadku można wyłączyć „problematyczne” testy.

Tak może wyglądać przykładowy wynik skanowania/testu (WP-Admin: Narzędzia -> Stan witryny):

Nie ma tu nic nadzwyczajnie groźnego, ale może budzić pewne obawy/wątpliwości, więc można rozważyć wyłączenie niektórych (albo wszystkich ;-)) testów.

Tak wygląda ich aktualna:

• WordPress Version / Wersja WordPressa: wordpress_version (direct)
• Plugin Versions / Wersje wtyczek: plugin_version (direct)
• Theme Versions / Wersje motywów: theme_version (direct)
• PHP Version / Wersja PHP: php_version (direct)
• Database Server version / Wersja serwera baz danych: sql_server (direct)
• PHP Extensions / Rozszerzenia PHP: php_extensions (direct)
• MySQL utf8mb4 support / Wsparcie MySQL utf8mb4: utf8mb4_support (direct)
• HTTPS status / Status HTTPS: https_status (direct)
• Secure communication / Bezpieczna komunikacja: ssl_support (direct)
• Scheduled events / Zaplanowane zdarzenia: scheduled_events (direct)
• HTTP Requests / Zapytania HTTP: http_requests (direct)
• Debugging enabled / Debugowanei włączone: is_in_debug_mode (direct)
• REST API availability / Dostępność REST API: rest_availability (direct)
• Communication with WordPress.org / Komunikacja z WordPress.org: dotorg_communication (async)
• Background updates / Aktualizacje w tle: background_updates (async)
• Loopback request / Zapytanie zwrotne: loopback_requests (async)

Aktualną listę wszystkich testów znajdziemy w dokumentacji WordPressa (Code Reference).

Gdy już mamy listę testów, wystarczy skorzystać z prostego kodu PHP, który możemy wgrać jako wtyczkę lub dodać do pliku functions.php (jeśli dodajemy jako wtyczkę, to można rozważyć skorzystanie ze wtyczki typu „Must Use”):

function webinsider_wp_disable_site_status_health_tests( $tests ) {
	
	unset( $tests['direct']['wordpress_version'] );
	unset( $tests['direct']['plugin_version'] );
	unset( $tests['direct']['theme_version'] );
	unset( $tests['direct']['php_version'] );
	unset( $tests['direct']['php_extensions'] );
	unset( $tests['direct']['sql_server'] );
	unset( $tests['direct']['utf8mb4_support'] );
	unset( $tests['direct']['https_status'] );
	unset( $tests['direct']['ssl_support'] );
	unset( $tests['direct']['scheduled_events'] );
	unset( $tests['direct']['http_requests'] );
	unset( $tests['direct']['is_in_debug_mode'] );
	unset( $tests['direct']['rest_availability'] );
	
	unset( $tests['async']['dotorg_communication'] );
	unset( $tests['async']['background_updates'] );
	unset( $tests['async']['loopback_requests'] );

    return $tests;
}
add_filter('site_status_tests', 'webinsider_wp_disable_site_status_health_tests' );add_filter('site_status_tests', 'pryc_wp_disable_site_status_health_tests' );

Każda linijka zaczynająca się od „unset” wyłącza jeden, konkretny test. Jeśli któregoś nie chcemy wyłączać, wystarczy zakomentować lub skasować daną linijkę kodu. W każdym razie finalnym efektem prac powyższego kodu będzie strona ze zdanym w 100% testem (przynajmniej pozornie ;-)):

Można też ukryć widget na stronie głównej panelu zarządzania WordPressem (WP-Admin):

function webinsider_wp_dashboard_setup_remove_widget() {
    remove_meta_box('dashboard_site_health', 'dashboard', 'normal');
}
add_action('wp_dashboard_setup', 'webinsider_wp_dashboard_setup_remove_widget');

A nawet ukryć link w menu:

function webinsider_wp_admin_menu_remove_site_health() {
        $page = remove_submenu_page( 'tools.php', 'site-health.php' );
}
add_action( 'admin_menu', 'webinsider_wp_admin_menu_remove_site_health' );

Jeśli ktoś nie chce się bawić kodem, może skorzystać ze wtyczki Site Health Tool Manager (William Earnhardt), która powyższe opcje pozwala aktywować z panelu zarządzania WordPressem (WP-Admin). Ale wtedy warto pamiętać o tym, by ukryć istnienie wtyczki przed osobami, dla których „modyfikujemy” test. W innym przypadku raczej to nie ma sensu.

Oczywiście to nie jest tak, że namawiam do ignorowania sygnalizowanych problemów. Wręcz przeciwnie. Ale mam też świadomość, że nie zawsze każdy problem da się rozwiązać, a skoro nie ma on wpływu na faktyczne działanie strony (np. informacja, ze zalecany jest PHP 7.3, a nie np. 7.2) to po co nim straszyć potencjalnego klienta. W końcu to nie aktualizacje, by wyłączenie miało realnie negatywne (niebezpieczne) konsekwencje…