powermail dla TYPO3

powermail to produkcyjnie gotowy system formularzy dla TYPO3

Między TYPO3-Core-Form-Framework a kompletnymi narzędziami marketing-automation istnieje w praktyce luka: redakcje chcą budować formularze bez kodu, z logiką warunkową, uploadem plików, zgodą RODO, przekazywaniem do CRM i porządnym eksportem PDF. Dokładnie do tego zbudowano powermail. Rozszerzenie od in2code jest najczęściej instalowanym pluginem formularzy w ekosystemie TYPO3 i działa w większości średnich i dużych projektów TYPO3, którymi opiekuje się Gosign. Od pierwszej wersji ponad dekadę temu powermail rozwinął się w szwajcarski scyzoryk tworzenia formularzy TYPO3 i jest również ważnym wyborem, gdy TYPO3-Core-Form-Framework teoretycznie by wystarczył.

Typowe scenariusze zastosowania sięgają od formularzy kontaktowych po portale rekrutacyjne

Najczęstszy scenariusz jest trywialny, ale nieunikniony: formularze kontaktowe na stronach firmowych, które wysyłają e-maile do różnych działów. powermail pozwala na to przez warunkowe trasy odbiorców, bez konieczności ingerencji dewelopera. Redaktorzy pielęgnują pola w backendzie jak zawartość strony, wraz z kolejnością, polami obowiązkowymi i walidacją. Typowa instalacja firmowa ma trzy do pięciu wariantów formularza: ogólne zapytanie kontaktowe, kontakt prasowy, kariera, support i doradztwo produktowe. Każdy wariant trafia przez własny filtr odbiorcy do właściwej skrzynki działowej.

Znacznie bardziej wymagające są wieloetapowe formularze rekrutacyjne, jak są stosowane w instytucjach publicznych i uczelniach. Portal rekrutacyjny pyta w kroku 1 o dane podstawowe, w kroku 2 o wybrany kierunek studiów, w kroku 3 o świadectwa przez upload, a w kroku 4 o zgodę RODO z linkiem do polityki prywatności. powermail renderuje wszystkie cztery kroki z jednego rekordu formularza i zapisuje postęp między krokami w sesji, dzięki czemu kandydat może w razie potrzeby wrócić. Warunki pokazują lub ukrywają pola w zależności od wcześniejszych odpowiedzi, co przy złożonych formularzach jak wnioski stypendialne lub zgłoszenia habilitacyjne czyni przejrzystą trzycyfrową liczbę kombinacji pól.

Trzeci scenariusz, który odróżnia powermail od prostszych rozszerzeń, to integracja z narzędziami CRM i marketingowymi. Architektura finisherów pozwala na równoległe wysyłanie danych do HubSpot, Salesforce, Brevo lub własnego webhooka, zanim mail potwierdzający trafi do nadawcy. W Gosign powermail jest dlatego również standardowym narzędziem dla formularzy lead, które bezpośrednio wprowadzają dane do procesu sprzedaży. W projekcie enterprise podłączyliśmy powermail do Salesforce Marketing Cloud i jednocześnie przekazywaliśmy przez webhook do wewnętrznego systemu ticketowego, dzięki czemu zespoły sprzedaży i wsparcia mogą równolegle uzyskiwać dostęp do zapytania.

Architektura techniczna rozdziela definicję formularza, finisher i szablon

powermail składa się z trzech warstw koncepcyjnych: definicji formularza w backendzie, finisherów, które są wykonywane po wysłaniu, i szablonów Fluid, które przejmują renderowanie. Każda warstwa jest rozszerzalna, bez forkowania rozszerzenia. To czyste rozdzielenie czyni powermail solidnym narzędziem dla długowiecznych projektów TYPO3, w których formularze są pielęgnowane i rozszerzane przez lata.

Formularze są zakładane jako rekordy w tx_powermail_domain_model_form. Każdy formularz zawiera Pages (kroki), każda Page zawiera pola. Typy pól sięgają od tekstu, e-maila, select, radio, file-upload po HTML-Content i checkboxy zgody. Logika warunkowa jest pielęgnowana przez moduł Conditions: “Pokaż pole B tylko wtedy, gdy pole A ma wartość X”.

Finisher są właściwą siłą rozszerzenia. Standardowy finisher wysyła e-maile, zapisuje wpisy w bazie danych i tworzy eksporty PDF. Kolejne finishery można implementować przez FinisherInterface: wysłanie webhooka, synchronizacja z CRM, Salesforce, przekazanie do SAP. Kolejność finisherów jest konfigurowalna, a każdy finisher może przerwać proces w razie błędu.

Szablony leżą jako pliki Fluid w ścieżce EXT i są zazwyczaj nadpisywane przez SiteSet lub własny pakiet. Oznacza to: jeden globalny template-overlay wystarcza, żeby ujednolicić wszystkie formularze strony. Kto zamiast tego potrzebuje własnych szablonów per formularz, może przekonfigurować ścieżki szablonów przez TypoScript i pielęgnować template-set per typ formularza.

Częste problemy dotyczą spamu, RODO i dostarczalności e-maili

Dominującym tematem wsparcia przy publicznych formularzach powermail jest spam. Out of the box rozszerzenie przynosi pola honeypot, sprawdzanie znacznika czasu i opcjonalne ReCaptcha v3 przez ext:powermailrecaptcha. Mimo to spam trafia do backendu, gdy administracja nie aktywowała mechanizmów sprawdzania. Zalecamy w każdym formularzu łączyć honeypot ORAZ ReCaptcha i dodatkowo używać finisher rate-limit oparty na IP.

Drugim problemem jest zgodność z RODO. Zgody formularzowe muszą być dokumentowane w sposób rewizyjnie bezpieczny: data, wersja polityki prywatności, IP i User-Agent. Rozszerzenie oferuje do tego Consent-Storage, który oddzielnie protokołuje zgody i czyni je eksportowalnymi do audytów.

Po trzecie, dostarczalność e-maili to stały temat. Maile potwierdzające trafiają do spamu, bo nadawca nie jest uwierzytelniony. SPF, DKIM i DMARC muszą być prawidłowo skonfigurowane na poziomie serwera poczty, a konfiguracja powermail powinna ustawić Return-Path i ważny Reply-To. Przy dużych instalacjach zalecamy dodatkowo dedykowaną usługę maili transakcyjnych jak Brevo, Mailgun lub Amazon SES, żeby współczynnik dostarczalności nie cierpiał pod ogólną reputacją serwera.

TYPO3 v12 i v13 są w pełni wspierane

powermail jest przy każdym wydaniu LTS TYPO3 szybko dostępny, bo in2code aktywnie utrzymuje rozszerzenie. Aktualna seria wspiera TYPO3 v11, v12 i v13 równolegle. Przy upgrade starszych instalacji breaking changes dotyczą przede wszystkim własnych klas finisherów, które muszą być przestawione na aktualną sygnaturę interfejsu, oraz szablonów Fluid, które reagują na zmiany ViewHelperów.

Gosign migruje instalacje powermail zazwyczaj wraz z upgrade core TYPO3. Przy tym sprawdzamy przed skokiem, które własne finishery i szablony istnieją, które integracje stron trzecich są podłączone i czy przestarzałe warianty pluginu są jeszcze w użyciu. Migracja zazwyczaj przebiega bez migracji danych, bo struktura rekordów definicji formularzy pozostaje stabilna.