Formularz WordPress nie działa? Jak znaleźć miejsce awarii

Problemy z formularzami podziel na konkretne sytuacje: brak pól na stronie, nieaktywny przycisk, odrzucone dane, komunikat sukcesu bez powiadomienia albo wiadomość w spamie. Każdy objaw prowadzi do innego testu. Wymiana wtyczki na początku diagnozy może ukryć przyczynę i utrudnić porównanie, zamiast rozwiązać problem.

Zapisz adres strony, godzinę próby ze strefą czasową, urządzenie i widoczny komunikat. Sprawdź, czy awaria występuje u niezalogowanego użytkownika, czy tylko w panelu. Ustal też, kiedy formularz działał ostatnio i jakie zmiany wykonano później. Aktualizacja, modyfikacja powiadomień i zmiana dostawcy poczty są różnymi tropami.

To mapa sprawdzania, nie lista pewnych przyczyn. Jeden kod HTTP lub kolor komunikatu nie wystarczy do postawienia diagnozy.

Gdy widzisz sam shortcode, sprawdź aktywność dodatku i to, czy wskazany formularz nadal istnieje. Przy pustym obszarze porównaj zawartość edytora z publiczną stroną. Jeśli pola są obecne, lecz układ się rozpada, sprawdź pobieranie arkuszy stylów oraz reguły motywu. Nie zaczynaj wtedy od ustawień skrzynki pocztowej.

W narzędziach przeglądarki otwórz Console i Network. Odtwórz objaw na kopii testowej oraz zobacz, czy po użyciu przycisku pojawia się żądanie. Brak żądania może wiązać się ze skryptem lub walidacją, ale trzeba odczytać komunikaty. Sam czerwony wpis w konsoli również nie dowodzi, że dotyczy formularza.

Sprawdź wersję zasobów po zmianie ustawień optymalizatora. Wyczyść właściwą warstwę cache lub porównaj odpowiedź z pominięciem jej na stagingu. Masowe czyszczenie wszystkich mechanizmów serwera nie zawsze jest potrzebne. Nie wyłączaj zabezpieczeń produkcji, aby wykonać szybki test. Jeśli problem dotyczy konfiguracji nowego elementu, skorzystaj z osobnej instrukcji instalacji formularza.

Żądanie wysłane przez przeglądarkę musi jeszcze przejść kontrolę aplikacji. Odczytaj nie tylko status HTTP, ale również treść odpowiedzi i komunikat dodatku. Odpowiedź 403 może pochodzić z różnych warstw: serwera, usługi pośredniczącej lub aplikacji. Nie przypisuj jej automatycznie wygasłemu tokenowi albo jednej wtyczce bezpieczeństwa.

Sprawdź wymagane pola, dozwolone pliki, limity i reguły antyspamowe. Dla zewnętrznego zabezpieczenia potwierdź zgodność konfiguracji z domeną oraz środowiskiem. Na stagingu zmieniaj jeden warunek i zapisuj wynik. Jeżeli test wymaga czasowego ograniczenia zabezpieczenia, odizoluj środowisko i po próbie przywróć ustawienie.

FAQ Contact Form 7 rozróżnia niepowodzenia wysyłki i odrzucenia jako spam. Przy innej wtyczce korzystaj z jej dokumentacji, zamiast przenosić znaczenie kolorów lub nazw statusów. Dodaj próbę z prawidłowymi danymi oraz z celowo błędnym polem. Poprawka nie jest odebrana, jeśli formularz przepuszcza wszystko, lecz utracił potrzebną walidację. Ważna jest zarówno dostępność dla klienta, jak i zachowanie reguł przyjęcia.

Oddziel trzy zdarzenia: przyjęcie danych przez formularz, zapis zgłoszenia i wysłanie powiadomienia. Nie każdy dodatek wykonuje wszystkie trzy. Contact Form 7 domyślnie nie zapisuje wiadomości w bazie, co opisuje jego dokumentacja. Brak wpisu w panelu nie musi więc oznaczać nowej awarii zapisu, jeśli takiej funkcji wcześniej nie skonfigurowano.

Jeżeli zapis jest aktywny, sprawdź identyfikator zgłoszenia i moment utworzenia. Potem przejdź do warunków powiadomienia: odbiorcy, mapowania pól i ewentualnej logiki zależnej od odpowiedzi. Udany test transportu nie sprawdza automatycznie tych ustawień. Formularz może w ogóle nie uruchomić wiadomości, którą potrafi wysłać narzędzie testowe.

Referencja WordPress wp_mail zaznacza, że wartość true nie potwierdza dostarczenia wiadomości odbiorcy. Dlatego komunikatu sukcesu nie traktuj jako dowodu konkretnej usterki funkcji PHP mail(). Ustal, gdzie kończy się ślad. Jeśli nie zapisano danych i nie ma śladu transportu, nie obiecuj odzyskania treści zgłoszenia, którego system nie zachował.

Jeżeli aplikacja uruchomiła powiadomienie, sprawdź log transportu i odpowiedź dostawcy. Zapisz czas oraz identyfikator wiadomości, o ile jest dostępny. Błąd uwierzytelnienia, odrzucenie adresata i brak połączenia wymagają różnych działań. Nie poprawiaj rekordów DNS tylko dlatego, że test pokazał niepowodzenie logowania.

Konfigurację SMTP albo usługi API odtwórz według dokumentacji używanego dostawcy. Host, port i sposób szyfrowania muszą tworzyć zgodny zestaw. Port 465 nie oznacza z definicji starego, nieszyfrowanego rozwiązania; może obsługiwać implicit TLS, opisany w RFC 8314. Nie zamieniaj portów w ciemno. Sprawdź też, czy konto wymaga odrębnego sposobu uwierzytelnienia zamiast zwykłego hasła skrzynki.

SMTP samo nie podpisuje domeny DKIM ani nie zapewnia przejścia SPF. Takie ustawienia zależą od infrastruktury i konfiguracji dostawcy. Przyjęcie wiadomości przez serwer wysyłający pozostaje innym etapem niż umieszczenie jej w skrzynce odbiorczej. Porównaj ślad rzeczywistego powiadomienia z wynikiem testu, zamiast zakładać, że oba korzystają z identycznego nadawcy i warunków.

Adres From ustaw zgodnie z tożsamością, którą używany dostawca pozwala uwierzytelnić. Adres wpisany przez klienta nadaje się do Reply-To po prawidłowej walidacji; nie powinien służyć do podszywania się pod jego domenę w polu nadawcy. Sprawdź również, czy odbiorca nie jest starym adresem pozostałym po migracji witryny.

Wytyczne Gmail dla nadawców opisują znaczenie SPF, DKIM, DMARC oraz innych warunków dostarczania. SPF wskazuje uprawnione źródła dla sprawdzanej domeny, DKIM pozwala weryfikować podpis, a DMARC obejmuje zgodność domen i politykę. Rekord MX dotyczy kierowania poczty przychodzącej; nie zastępuje uwierzytelnienia wysyłki.

Folder spam nie wskazuje jednej pewnej przyczyny. Sprawdź wyniki uwierzytelnienia, komunikat odrzucenia, reputację i reguły odbiorcy. Nie obiecuj dostarczalności tylko dlatego, że zmienisz usługodawcę lub dodasz rekord DNS. Wprowadzając poprawkę, zachowaj pozostałe legalnie używane źródła wysyłki domeny. Po zmianie zweryfikuj faktyczny wynik, zamiast uznawać samo upłynięcie określonej liczby godzin za zakończenie problemu.

Konflikt sprawdzaj na kopii z przechwytywaniem poczty oraz wyłączonymi produkcyjnymi integracjami CRM i pomiaru. Zachowaj zależności między dodatkami. Wyłączenie nadrzędnej wtyczki może uruchomić inny błąd i nie dowodzi, że właśnie ona odpowiadała za pierwotny objaw. Porównuj ten sam formularz, dane i stan sesji.

Zapisuj jedną zmianę oraz jej wynik. Po znalezieniu podejrzanej kombinacji potwierdź objaw po jej przywróceniu, a następnie sprawdź poprawkę. Przy błędach PHP sięgnij do poradnika debugowania WordPressa. Do zgłoszenia dołącz adres, wersje, czas i zanonimizowany komunikat, bez haseł, kluczy i treści klientów.

Odbiór obejmuje widok mobilny, walidację, przyjęcie, zapis jeśli wymagany i przekazanie powiadomienia do kontrolowanego odbiornika testowego. Nie wysyłaj prób do klientów ani nie licz ich jako leadów. Wsparcie dla WordPressa oraz zakres opieki technicznej można uzupełnić małym pakietem godzinowym. Napisz do KC Mobile, aby ustalić zakres diagnozy i późniejsze kontrole; SLA oraz czasy reakcji uzgadniamy indywidualnie.