Jeśli sklep WooCommerce przestał wysyłać maile, a w logach SMTP stoi 535 Incorrect authentication data, serwer pocztowy odrzuca login lub hasło skrzynki zapisane w wp-config.php. Standardowo wp_mail() przy błędzie SMTP zwraca false i uruchamia hak wp_mail_failed, ale w naszych sklepach część ścieżek wysyłki zwracała true mimo odrzuconego logowania, więc sklep wyglądał na zdrowy, a klienci nie dostawali potwierdzeń zamówień. Poniżej opisujemy, jak wygląda taka awaria na dwóch sklepach, które hipotezy odrzuciliśmy i dlaczego po zmianie hasła strona dalej używała starego.
Jak wygląda awaria wysyłki maili w WooCommerce?
Klient zgłosił, że maile nie docierają. Potwierdziliśmy, że dwa sklepy na jednym serwerze nie wysyłają żadnych wiadomości transakcyjnych: ani potwierdzeń zamówień, ani powiadomień o realizacji. Zamówienia wpadały do sklepu normalnie, ale nie wychodziły ani maile do klientów, ani powiadomienia dla obsługi, więc awarię zauważył dopiero klient.
Skala: dwanaście zamówień w dwóch sklepach bez żadnego maila do kupującego. Przez kilka dni strona działała bez żadnego komunikatu o błędzie.
Jak sprawdzić, dlaczego SMTP odrzuca logowanie?
Zamiast ufać wynikowi wp_mail(), odpalamy własny dialog SMTP z kontenera i patrzymy na odpowiedzi serwera. U nas serwer odpowiadał tak:
SERVER -> CLIENT: 535 Incorrect authentication dataHasła zapisane w wp-config.php (20 i 16 znaków) nie były akceptowane. Zanim uznaliśmy to za przyczynę, odrzuciliśmy sześć innych hipotez:
| Hipoteza | Jak sprawdzono | Wynik |
|---|---|---|
| Blokada adresu IP serwera | nc na port 587, banner serwera | port otwarty, serwer odpowiada |
| Tymczasowy blok po nieudanych próbach | powtórny test po 4 minutach | ten sam błąd |
| Hasło uszkodzone przez znaki specjalne | oględziny surowej linii w pliku | cudzysłowy pojedyncze, długość zgodna |
| Wtyczka przechwytuje maile | SHOW TABLES LIKE '%wpmc%' | brak tabel |
| Zły format loginu | próby z pełnym adresem i samą nazwą | oba odrzucone |
| Brak STARTTLS | dialog SMTP | STARTTLS działa, AUTH PLAIN LOGIN ogłaszane |
Certyfikat serwera był wystawiony na nazwę hosta poczty, nie na domeny sklepów. Taka niezgodność nie powoduje błędu 535, który dotyczy logowania, więc nie była przyczyną. Weryfikacji certyfikatu nie warto wyłączać: wygodniej wpisać w konfiguracji nazwę hosta zgodną z certyfikatem. Zostawało jedno: serwer poczty przestał akceptować hasła do skrzynek.
Kiedy dokładnie przestała działać wysyłka?
Z logów da się odtworzyć zarys osi czasu. Pierwszy błąd uwierzytelnienia pojawił się 25.08, ostatnie udane maile wyszły 26.08 z jednego sklepu i 30.08 z drugiego, a ostatni zarejestrowany błąd to 31.08. Między tymi datami trafiały się też błędy połączenia (28.08), więc wysyłka nie urwała się jednego dnia, tylko wygasała przy kolejnych nieudanych logowaniach.
Pełną oś czasu złożyliśmy dzięki jednemu ze sklepów: jego wtyczka SMTP miała podpięty hak wp_mail_failed, który zapisuje każdą nieudaną wysyłkę do logu. Drugi sklep nie miał go wcale, więc awaria przeszła tam bez śladu w logach WooCommerce przez kilka dni.
Masz ten sam problem? Nie masz pewności, czy sklep wysyła maile? Sprawdzimy dialog SMTP, dopniemy hak wp_mail_failed i ustawimy alert. Opisz sytuację →
Jak dodać log nieudanych maili w WordPressie?
Hak wp_mail_failed przekazuje obiekt błędu z komunikatem serwera. Wystarczy zapisać go tam, gdzie ktoś zajrzy:
add_action( 'wp_mail_failed', function ( $error ) {
error_log( '[wp_mail_failed] ' . $error->get_error_message() );
} );To jedna z pierwszych rzeczy, które dodajemy do sklepu przy przejęciu opieki. Sam log bez alertu to jednak za mało: warto powiązać go z powiadomieniem, które trafia do kogoś, kto je przeczyta w ciągu godziny.
Dlaczego po zmianie hasła strona dalej nie wysyła?
Hasła skrzynek ustawiliśmy na nowo w panelu pocztowym (DirectAdmin) i wpisaliśmy do wp-config.php obu sklepów, zostawiając kopie starych plików. Dialog SMTP z kontenera zwrócił 235 Authentication succeeded dla obu kont, a wp_mail() z wiersza poleceń zwrócił true bez wp_mail_failed.
Pułapka: strona dalej mogła używać starego hasła. Php-fpm miał opcache.validate_timestamps=0, więc zmiana wp-config.php nie była dla niego widoczna bez przeładowania. Test z CLI przechodzi, bo uruchamia świeży proces, a sklep w przeglądarce trzyma wartość z pamięci. Rozwiązaniem bez ponownego tworzenia kontenera, które kosztowałoby około 60 sekund błędu 502, jest łagodne przeładowanie. Zakłada ono, że php-fpm jest procesem głównym o PID 1, więc najpierw sprawdź to poleceniem docker compose exec wordpress ps:
docker compose exec wordpress kill -USR2 1Sprawdziliśmy to tymczasowym plikiem PHP wywołanym przez nginx: php-fpm czytał już nowe wartości.
Co ustawić, żeby wysyłka maili nie padła po cichu?
- hak
wp_mail_failedna każdym sklepie, w tym tym drugim, który go jeszcze nie miał, - alert po pierwszym błędzie uwierzytelnienia, a nie po tygodniu,
- test dialogiem SMTP z
SMTPDebug = 2po każdej zmianie haseł, zamiast wiary w wynikwp_mail(), - przeładowanie php-fpm po zmianie
wp-config.php, gdy opcache nie sprawdza znaczników czasu, - osobny test pełnej ścieżki: złożenie zamówienia i sprawdzenie, czy mail doszedł.
Szerzej o kontrolach, które wykrywają takie awarie, piszemy w artykule o monitoringu sklepu poza uptime.
Kiedy zlecić to specjalistom?
Gdy sklep przyjmuje zamówienia, ale klienci twierdzą, że nic nie dostali, a w panelu nie ma żadnych błędów. W ASAPDevs ustalamy przyczynę po stronie SMTP, naprawiamy konfigurację i dodajemy monitoring w ramach opieki nad WordPressem. Gdy liczy się czas, zobacz Pogotowie IT.
Źródła: WordPress Developer Resources, hook wp_mail_failed; dokumentacja PHP, opcache.validate_timestamps.
