Tworzenie niestandardowych szablonów wiadomości e-mail i logiki transakcyjnej w PrestaShop

Zauważamy, że każdy sklep PrestaShop wysyła kilka e-maili tygodniowo, a nikt się nad nimi nie zastanawia: potwierdzenia zamówień, powiadomienia o wysyłce, resetowanie hasła, powitania na koncie. Następnie klient przesyła dalej jeden z tych e-maili, pytając: „Zaraz, czy to naprawdę od ciebie?”. Szablon nadal ma klasyczny, wieloletni wygląd PrestaShop, ale system e-mail jest teraz tym, co sprawia wrażenie nowoczesnego i przemyślanego.

Dostosowywanie szablonów e-maili PrestaShop to nie jest tak naprawdę jedno zadanie. To dwa problemy, które po prostu wyglądają podobnie. Jeden dotyczy wyglądu e-maila, a drugi tego, kiedy i dlaczego jest on wysyłany. Większość poradników omawia tylko pierwszy. Ten artykuł omawia oba, ponieważ właściciel sklepu, który korzysta tylko z szablonu wizualnego, w końcu napotka mur, gdy będzie chciał niestandardowego powiadomienia, na przykład e-maila z informacją „Twoje zamówienie właśnie zostało uzupełnione”, którego PrestaShop po prostu nie wysyła domyślnie.

1.0 Jak PrestaShop faktycznie obsługuje wiadomości e-mail

Modyfikowanie szablonów oznacza zmianę wyników logiki bez naruszania samej logiki. Przed wprowadzeniem jakichkolwiek zmian pomocne będzie zrozumienie struktury rzeczy, ponieważ PrestaShop dzieli funkcjonalność przetwarzania wiadomości e-mail na dwie odrębne warstwy znajdujące się w zupełnie różnych lokalizacjach.

Pierwszą warstwę zobaczysz pracując w back-office. Każdy e-mail wysyłany przez PrestaShop jest ważny i wartościowy. Może to być e-mail potwierdzający zamówienie, z fakturą, z pomocą w zresetowaniu hasła lub potwierdzający subskrypcję newslettera. Dla każdego z tych e-maili, w zależności od języka, dostępny jest plik HTML oraz plik tekstowy. Wersje te są zapisywane jako pliki dla każdego języka. Pliki te znajdują się w folderze „Mails” w Twojej instalacji.

Warstwa logiczna to kod. W PrestaShop, kod PHP w rdzeniu lub module wywołuje metodę Mail::Send() . Ta metoda jest sposobem, w jaki PrestaShop 1.7 i 8.x wysyłają transakcyjne e-maile po wystąpieniu zdarzenia. Nowsze przepływy administracyjne oparte na Symfony. Chociaż niektóre z tych modułów korzystają z własnych usług pocztowych, nic nie zastąpi usługi opakowującej metodę Mail::Send() we wszystkie moduły rdzenia. Ta konkretna metoda Mail::Send() zajmuje się procesem decyzyjnym dotyczącym ładowania pliku szablonu, wymaganych zmiennych oraz osoby, która otrzyma e-mail, niezależnie od tego, czy będzie to zamówienie, status, czy zmiana hasła. Zmiana pliku szablonu wpłynęłaby na wynik tej logiki, a nie na samą logikę.

Funkcja Mail::Send() będzie potrzebowała następujących parametrów:

1. $id_lang
2. $template (nazwa pliku, bez rozszerzenia)
3. $ temat
4. $template_vars (tablica ze zmiennymi do zastąpienia zmiennych w szablonie)
5. $do
6. $to_name
7. $od
8. $ FROM_NAME 

i inne potencjalne parametry, takie jak $attachment.

Obsługuje również tryb SMTP i wymusza niestandardową ścieżkę szablonu, a także $id_order. W praktyce większość wysiłku w tworzeniu niestandardowego modułu e-mail sprowadza się do poprawnego zbudowania tablicy $template_vars i upewnienia się, że $template wskazuje na właściwy plik. Wywołanie metody Mail::Send() rzadko wymaga czegoś więcej.

To rozróżnienie ma znaczenie, ponieważ wielu właścicieli sklepów napotyka na problemy. Mówią: „Edytowałem szablon, ale nic nie zmieniłem” lub „Jak dodać automatyczną wiadomość e-mail?”. Te problemy wynikają z pomieszania tych dwóch warstw.

1.1 Warstwa szablonu w praktyce

Jeśli chcesz zmienić wygląd szablonu, zacznij od zaplecza.

• Kliknij Ulepsz > Międzynarodowe > Tłumaczenia (ta ścieżka dotyczy PrestaShop 1.7 i 8.x, ale w PrestaShop 1.6 użyj Lokalizacja > Tłumaczenia). Wybierz Modyfikuj tłumaczenia, a następnie wybierz Tłumaczenia e-maili jako typ tłumaczenia.

Strona Tłumaczenia w zakładce Ulepsz > Międzynarodowe

• Wybierz, czy chcesz edytować treść czy temat.

Typ tłumaczenia wiadomości e-mail z wybraną treścią tematu

• Wybierz motyw, zazwyczaj Core (nie wybieraj motywu), chyba że używasz zastąpienia określonego motywu i języka, który chcesz edytować.

Tłumaczenia wiadomości e-mail ustawione na Treść z wybranym motywem i językiem

• Kliknij Modyfikuj i wybierz z listy konkretny adres e-mail, np. dotyczący utworzenia konta lub potwierdzenia zamówienia.

Lista wiadomości e-mail głównych i modułów wyświetlana po kliknięciu przycisku Modyfikuj

Rozszerzono listę głównych wiadomości e-mail, pokazując nazwy poszczególnych szablonów

Pełna lista podstawowych szablonów wiadomości e-mail dostępnych do tłumaczenia

Wybrany szablon konta z kartami Wyświetl HTML / Edytuj HTML / Wyświetl/Edytuj TXT

Po wykonaniu tej czynności zobaczysz trzy opcje: podgląd wersji HTML, edytowalną wersję HTML, która umożliwia przejście do kodu źródłowego, jeśli chcesz pominąć edytor WYSIWYG , oraz wersję w postaci zwykłego tekstu.

Modyfikuj wersję HTML wiadomości e-mail za pomocą wbudowanego edytora WYSIWYG

Za każdym razem modyfikuj zarówno wersję HTML, jak i zwykły tekst, ponieważ niektóre klienty poczty e-mail i niektórzy użytkownicy z wyłączonymi obrazkami czytają tylko wersję tekstową. Pominięcie tej opcji oznacza, że ​​połowa odbiorców otrzyma wiadomość e-mail, która nie będzie zgodna z tą, którą właśnie stworzyłeś.

Wyświetl/edytuj wersję TXT szablonu wiadomości e-mail konta

Jeśli wolisz pracować z plikami, dostęp do tych samych szablonów jest możliwy przez FTP lub SFTP w folderze „Mails”. Folder jest uporządkowany według języków. Edycja pliku account.html w tym folderze i ponowne przesłanie go daje taki sam efekt, jak użycie edytora backoffice.

Zauważamy, że narzędzie WYSIWYG nie oferuje żadnej siatki bezpieczeństwa. Każdy drobny błąd w tagach Smarty lub Twig w kodzie szablonu spowoduje błąd renderowania. Moim zdaniem, testowanie wszelkich modyfikacji wprowadzonych przez FTP na stronie testowej sklepu jest niezwykle istotne. Praktyczną uwagą, która często wydaje się myląca, jest to, że zmiany w szablonach są specyficzne dla motywu i języka. Jeśli w sklepie działa niestandardowy motyw i dokonano edycji „Core (brak wybranego motywu)”, wiadomości e-mail mogą nadal korzystać z nadpisów nadpisanych przez sam motyw. Zawsze należy sprawdzić, który motyw jest faktycznie aktywny, zanim założymy, że zmiana nie została wprowadzona; ten pojedynczy szczegół jest odpowiedzialny za dużą liczbę wątków pomocy technicznej z informacją o braku wyświetlania zmian. Jest jeszcze jeden szczegół. W PrestaShop 8.x, jeśli sklep korzysta z motywu e-mail opartego na Twig zamiast klasycznego systemu szablonów, wiadomości mogą w ogóle nie pojawiać się w ekranie tłumaczeń. Sprawdź ścieżkę menu Ulepsz > Projekt > Motyw e-maila, aby znaleźć opcję tłumaczenia, zanim założysz, że klasyczny ekran zawiera wszystkie wiadomości e-mail wysyłane przez sklep. Najpierw sprawdź jeszcze raz menu w PrestaShop, ponieważ PrestaShop stale zmienia lokalizację obsługi wiadomości e-mail w miarę aktualizacji do Symfony.

Jeżeli motyw zastępuje szablony poczty, pliki te będą znajdować się w folderze motywy/ /poczta/ /, który podąża za układem folderów jako główny katalog mails/. Plik o nazwie account.html umieszczony w tej lokalizacji będzie używany jako plik z głównego katalogu mails/ w sklepach korzystających z tego motywu.

To ten sam mechanizm nadpisywania, który jest już wykorzystywany w szablonach witryn sklepowych, tyle że zastosowany do wiadomości e-mail.

Projekt > Motyw e-mail w PrestaShop 9.x, pokazujący opcje Generuj e-maile i Tłumacz e-maile dla motywów e-mail opartych na Twig

2.0 Typowe błędy edycyjne, których warto unikać

Kiedy właściciele sklepów zaczynają samodzielnie dostosowywać szablony, powtarza się kilka wzorców:

• Edycja dotyczy tylko wersji HTML. Wersja tekstowa nie dziedziczy zmian automatycznie, a tego typu desynchronizacja szablonu TXT/HTML po aktualizacji tłumaczenia jest często zgłaszanym zjawiskiem w systemie śledzenia błędów PrestaShop, nawet bez ani jednego kanonicznego zgłoszenia błędu.
• Usunięcie zmiennych szablonu może się zdarzyć przypadkowo. Tagi takie jak {firstname}, {order_name} lub {id_order} to symbole zastępcze, które zostaną wypełnione przez skrypt generowania wiadomości e-mail podczas jej wysyłania. Jeśli jednak kod HTML wokół zmiennej szablonu zostanie zmieniony, zmienna może stać się bezużyteczna. Przestanie działać poprawnie. Tagi mogą nie działać. Znikają lub pojawiają się w wiadomości e-mail zamiast zostać rozwiązane.
• Niewyczyszczenie pamięci podręcznej po edycji może powodować problemy. PrestaShop generuje szablony, a nieaktualna pamięć podręczna jest najczęstszą przyczyną braku wyświetlania wiadomości e-mail po edycji i przetestowaniu. Należy ją wyczyścić w panelu administracyjnym, w sekcji Parametry zaawansowane > Wydajność, ponieważ odświeżana jest tam pamięć podręczna szablonu Smarty; polecenie bin/console cache: clear czyści inną pamięć podręczną w frameworku Symfony i nie może być używane jako zamiennik. Ta sama zasada działa również z nadpisanymi szablonami motywu: motyw udostępnia własne szablony wiadomości e-mail w folderze themes/. Folder /mails/ generuje je i buforuje tak samo jak PrestaShop, więc zmiany nie będą widoczne, dopóki nie wyczyścisz również tej pamięci podręcznej.
• Zakładanie, że zmiany w temacie wiadomości znajdują się w tym samym miejscu, co zmiany w treści, jest błędem. Temat wiadomości to rozwijana lista wyboru na ekranie „Tłumaczenia” i łatwo ją przeoczyć przy pierwszym podejściu.
• Testowanie w przeglądarce lub skrzynce odbiorczej może być mylące. Podgląd w panelu administracyjnym wyświetla wiadomość e-mail w kontekście CSS motywu administracyjnego. Dotyczy to prawdziwych programów pocztowych, takich jak Gmail, Outlook czy Apple Mail, które mają ograniczoną funkcjonalność CSS. To, co wydaje się dobre w podglądzie, może stać się bałaganem po wysłaniu wiadomości.
• Teraz pojawia się druga warstwa. Możesz chcieć powiadomić klientów, gdy produkt z zamówienia zaległego pojawi się ponownie w magazynie. Możesz skonfigurować alert dla magazynu za każdym razem, gdy zamówienie jest oznaczone jako delikatne. Obecnie nie ma szablonu PrestaShop, który spełniałby którąkolwiek z tych funkcji. Ponieważ nie ma również żadnego istniejącego wyzwalacza dla tego szablonu PrestaShop.

Żaden z tych problemów nie jest egzotyczny. Szablony to powód, dla którego zdanie „edytuj szablon, zapisz i kontynuuj” często zamienia się w godzinną sesję debugowania.

3.0 Kiedy edycja szablonu nie wystarczy

W tym miejscu druga warstwa odgrywa kluczową rolę. Na przykład, możesz chcieć poinformować klientów, kiedy zamówione przez nich produkty staną się dostępne, mimo że były niedostępne w magazynie. Możesz chcieć powiadomić pracowników magazynu, gdy w zamówieniu znajdzie się produkt, który łatwo się psuje. PrestaShop nie oferuje gotowych komunikatów dla tego typu alertów, ponieważ nie ma sygnału dla takich sytuacji.

To problem logiczny, a nie szablonowy. Należy go rozwiązać na poziomie modułu.

System modułów PrestaShop udostępnia punkty zdarzeń haków w bazie kodu, do których moduły mogą dołączać niestandardowy kod. Kilka z nich jest uruchamianych w związku ze zdarzeniami dotyczącymi zamówienia i cyklu życia klienta (actionOrderStatusUpdate oraz actionOrderStatusPostUpdate w przypadku zmiany statusu zamówienia, actionCustomerAccountAdd do tworzenia konta itd.). Moduł zbudowany do obsługi niestandardowego e-maila transakcyjnego zazwyczaj wykonuje dwie czynności:

1. Nasłuchuje haka wyzwalającego. W przypadku powiadomienia o uzupełnieniu zapasów może to oznaczać podpięcie się pod aktualizacje stanu magazynowego. W przypadku wiadomości e-mail z informacją o statusie zamówienia oznacza to reakcję na hak actionOrderStatusUpdate, który uruchamia się tuż przed zapisaniem nowego statusu, lub na hak actionOrderStatusPostUpdate, który uruchamia się tuż po nim. Te dwa haki nie są zamienne, ponieważ kod podpięty do pierwszego nie zobaczy jeszcze nowego statusu zapisanego w bazie danych.
2. Połączenia Poczta::Wyślij() z nowym szablonem. Zamiast wykorzystywać istniejący plik szablonu, dobrze skonstruowany, niestandardowy e-mail definiuje własną parę HTML/TXT, umieszczoną w module maile podfolder lub dodany do folderu językowego sklepu i przekazuje mu określone zmienne, których potrzebuje nowy szablon.

PrestaShop oferuje kilka haków pocztowych, ale każdy z nich służy innemu celowi. Wybór odpowiedniego sprawia, że ​​moduł jest lekki i pozwala uniknąć niepotrzebnych nadpisywań klas pocztowych.

3.1 akcjaEmailWyślijPrzed

To najlepszy sposób na zmianę głównych danych wiadomości e-mail przed jej wysłaniem. Działa on ze zmiennymi odbiorcy, tematu i szablonu, a także pozwala całkowicie zablokować wysłanie wiadomości.

Używaj tej opcji, gdy Twoje wymagania mają wpływ na treść wiadomości e-mail, a nie na jej ostateczny wygląd.

Przykład: Zmiana odbiorcy i tematu

funkcja publiczna hookActionEmailSendBefore($params)
{
    // Przekieruj e-mail podczas testów
    $params['to'] = '[email chroniony]';

    // Aktualizacja tematu
    $params['subject'] = '[TEST] ' . $params['subject'];
}

Przykład: Warunkowe anulowanie wiadomości e-mail

funkcja publiczna hookActionEmailSendBefore($params)
{
    jeśli ($params['template'] === 'order_conf') {
        zwróć fałsz; // Zatrzymaj wysyłanie tego e-maila
    }
}

3.2 akcjaEmailAddBeforeContent

Użyj tego haka, gdy chcesz dodać treść tylko przed wygenerowanym tekstem wiadomości e-mail w formacie HTML lub TXT. Sprawdza się on dobrze w przypadku powiadomień, które powinny pojawiać się na górze wielu wiadomości transakcyjnych. Oryginalny szablon wiadomości e-mail pozostaje niezmieniony.

Oryginalny szablon wiadomości e-mail pozostaje nienaruszony.

Przykład: Dodaj powiadomienie nad treścią wiadomości e-mail

funkcja publiczna hookActionEmailAddBeforeContent($params)
{
    powrót ' Ważne: Zachowaj ten e-mail dla celów ewidencyjnych. ';
}

3.3 akcjaEmailAddAfterContent

Ten hak działa podobnie jak poprzedni, z tą różnicą, że treść jest dołączana po wygenerowanej treści wiadomości e-mail.

Użyj tej opcji w przypadku informacji, które naturalnie powinny znaleźć się w stopce.

Przykład: Dodawanie informacji pomocniczych

funkcja publiczna hookActionEmailAddAfterContent($params)
{
    powrót '
    Potrzebujesz pomocy? Skontaktuj się z naszym zespołem wsparcia w dowolnym momencie. ';
}

3.4 actionMailAlterMessageBeforeSend

Ten hak jest przeznaczony do zaawansowanej personalizacji. Zamiast modyfikować dane szablonu, zapewnia dostęp do ostatecznego obiektu wiadomości tuż przed jej dostarczeniem.

Wybierz ten hak, jeśli Twoje wymagania dotyczą samego obiektu poczty, a nie zawartości szablonu.

Przykład: Dodaj niestandardowy nagłówek wiadomości e-mail

funkcja publiczna hookActionMailAlterMessageBeforeSend($params)
{
    /** @var \Symfony\Component\Mime\Email $message */
    $message = $params['message'];

    $message>getHeaders()>addTextHeader(
        'XModuleSource',
        „Mój niestandardowy moduł”
    );
}

3.5 Szybki przewodnik decyzyjny

Zasadniczo zawsze zaczynaj od actionEmailSendBefore w przypadku logiki biznesowej, używaj hooków content do prostego wstrzykiwania treści i zarezerwuj actionMailAlterMessageBeforeSend do zaawansowanej personalizacji na poziomie wiadomości. Takie podejście zapewnia zgodność modułu z podstawowym systemem pocztowym PrestaShop bez konieczności nadpisywania.

W przypadkach, w których powyższe natywne hooki nie obejmują, niektóre moduły zewnętrzne idą o krok dalej: zamiast aby każdy moduł oddzielnie nadpisywał główną klasę Mail PrestaShop , moduł taki jak prestashopmailhook wykonuje to nadpisanie raz i ponownie udostępnia je jako własny hook, actionMailSend, który nadal jest aktywowany za każdym razem, gdy wiadomość e-mail jest wysyłana przez system, niezależnie od tego, czy została wysłana pomyślnie, czy nie. Warto jasno zaznaczyć, że jest to nadal nadpisanie głównej klasy Mail, co niesie ze sobą to samo ryzyko związane z podatnością na aktualizacje, opisane powyżej. Jego prawdziwą zaletą jest to, że inne moduły mogą analizować lub modyfikować wiadomość e-mail, zamieniać serwer wysyłający, dodawać zmienne niestandardowe lub wstrzymywać wiadomość w określonych warunkach, reagując na ten sam hook, zamiast nadpisywać Mail niezależnie, co w rzeczywistości powoduje, że moduły walczą o ten sam plik. Przed zainstalowaniem takiego modułu należy sprawdzić jego zgodność z wersją PrestaShop pod kątem zgodności z parametrem ps_versions_compliancy, ponieważ nieobsługiwane nadpisanie Mail to dokładnie ten rodzaj nadpisania, przed którym ostrzega ten artykuł powyżej.

3.6 Praktyczny przykład: niestandardowy e-mail z funkcją OrderStatusTriggered

Załóżmy, że chcesz wysłać klientowi spersonalizowaną wiadomość e-mail z podziękowaniami i instrukcjami dotyczącymi pielęgnacji, szczególnie w przypadku, gdy zamówienie powiązane z określoną kategorią produktów wymaga wysyłki, której domyślny szablon potwierdzenia wysyłki nie potrafi obsłużyć, ponieważ nie rozpoznaje kategorii produktów.

Praktyczna postać tego rozwiązania wygląda następująco:

• Mały niestandardowy moduł rejestruje się na actionOrderStatusUpdate (lub actionOrderStatusPostUpdate) hak.
• Wewnątrz metody hook moduł sprawdza, czy zamówienie zawiera produkt z odpowiedniej kategorii i śledzi, które zamówienia zostały już wysłane e-mailem, ponieważ ten hook może zostać uruchomiony więcej niż raz dla tej samej zmiany statusu w niektórych procesach, a dwukrotne otrzymanie przez klienta tego samego „dziękuję” jest traktowane jako błąd.
• Jeśli tak, moduł ładuje własną parę szablonów (nie główny szablon wysyłki) i wywołuje metodę wysyłania poczty ze zmiennymi specyficznymi dla zamówienia, takimi jak imię i nazwisko klienta, nazwa produktu, link śledzenia, uciekając przed każdą wartością dostarczoną przez klienta, zanim trafi ona do szablonu HTML, ponieważ zmienna bez ucieczki przed zmienną to realne pole do wstrzyknięcia przechowywanej treści.
• Główny e-mail z potwierdzeniem wysyłki jest wysyłany jak zwykle; jest to osobny e-mail dodany na górze.

Jest to zupełnie inne podejście niż zmiana szablonu wysyłki, ponieważ modyfikacja tego szablonu powodowałaby wysłanie wiadomości do wszystkich wysyłanych zamówień, a nie tylko tych, których chcesz.

Moduł punktów lojalnościowych Knowband (kbloyaltypoints) to prawdziwy przykład tego schematu. Rejestruje się on w actionOrderStatusUpdate , a każda skonfigurowana reguła lojalnościowa definiuje własny warunek (na przykład minimalną wartość koszyka) oraz własne powiadomienie e-mail. Gdy status zamówienia zmienia się na jeden ze statusów skonfigurowanych w Ustawieniach ogólnych modułu jako „przyznane” lub „anulowane”, hook uruchamia się, sprawdza zgodność zamówienia z pasującą regułą i, jeśli spełnia kryteria, wysyła powiadomienie e-mail (zbudowane na podstawie tematu i szablonu WYSIWYG modułu, a nie podstawowego szablonu statusu zamówienia), aby poinformować klienta o zdobyciu lub anulowaniu punktów lojalnościowych.

Ustawienia ogólne modułu punktów lojalnościowych, w którym konfiguruje się statusy zamówień, które powodują przyznanie/anulowanie punktów.

Własny szablon zakładki Powiadomienia tej reguły to faktyczna wiadomość e-mail wysyłana do klienta, gdy hak statusu zamówienia przyzna mu punkty lojalnościowe.

Co klient faktycznie otrzymuje w swojej skrzynce odbiorczej po uruchomieniu haka i wysłaniu powiadomienia e-mail zgodnie z regułą.

Zobacz sam moduł tutaj: Moduł punktów lojalnościowych Knowband

4.0 Decyzja, którego podejścia faktycznie potrzebujesz

Przed rozpoczęciem jakichkolwiek prac nad dostosowaniem warto przeprowadzić krótką kontrolę decyzyjną:

• Chcesz po prostu zmienić sformułowanie, kolory lub logo w istniejącej wiadomości e-mail? Pozostań w oknie „Tłumaczenia”. Kod nie jest wymagany.
• Chcę tegoCzy e-mail ma wyglądać znacząco inaczej – nowy układ, inna struktura, spójny z marką system projektowania w każdym e-mailu transakcyjnym? Nadal edytujesz pliki szablonów, ale planujesz odpowiednio przeprojektować parę HTML/TXT (najlepiej HTML oparty na tabelach dla zapewnienia zgodności z klientem poczty), zamiast łatać domyślny kod kawałek po kawałku.
• Potrzebujesz nowego e-maila, który obecnie nie istnieje, lub chcesz, aby istniejący e-mail został wysłany w nowych warunkach? Wymaga to modułu z logiką haka; sama warstwa szablonu tego nie zrobi.
• Zarządzasz wieloma szablonami w wielu sklepach lub językach i nie chcesz ręcznie edytować każdego z nich? To właśnie tutaj dedykowany moduł zarządzania szablonami wiadomości e-mail lub pakiet gotowych szablonów jest wart swojej ceny, ponieważ zazwyczaj obsługuje synchronizację wielu sklepów i języków, co na domyślnym ekranie jest uciążliwe. 
• Budowanie czegoś wielokrotnego użytku w różnych projektach, na przykład współdzielonej biblioteki logiki transakcyjnej poczty e-mail? To wskazuje na potrzebę napisania małego wewnętrznego zestawu SDK lub biblioteki pomocniczej zamiast duplikowania. Poczta::Wyślij() połączeń w wielu modułach.

5.0 Szybka lista kontrolna przed uruchomieniem

Zanim wprowadzisz jakiekolwiek zmiany w wiadomościach e-mail, wykonaj poniższe czynności:

• Zaktualizowano i zapisano wersje HTML i TXT
• Prawidłowy motyw wybrany podczas edycji (nie tylko domyślny „Core”)
• Wszystkie zmienne szablonu są nienaruszone i renderują się poprawnie podczas wysyłania testowego
• Pamięć podręczna wyczyszczona po edycji
• Wysyłanie testowe zostało wykonane przynajmniej w dwóch prawdziwych skrzynkach odbiorczych (nie tylko w podglądzie administratora)
• Temat wiersza edytowany osobno, jeśli zachodzi potrzeba zmiany
• W przypadku logiki niestandardowej: hak potwierdzono do uruchomienia tylko w zamierzonych warunkach, a nie przy każdym zamówieniu 
• Ustawienia SMTP zostały zweryfikowane w obszarze Parametry zaawansowane > E-mail, więc test nie maskuje problemu z dostarczaniem

Warto zwrócić uwagę na jeden problem: rejestry poczty w PrestaShop rejestrujące wywołanie i przekazanie funkcji Mail::Send() nie stanowią dowodu na to, że wiadomość dotarła do skrzynki odbiorczej. Nieprawidłowy host SMTP, port lub dane uwierzytelniające w sekcji Parametry zaawansowane > E-mail sprawią, że każda z tych wiadomości będzie wyświetlana w tym logu jako wysłana, bez wysyłania czegokolwiek poza serwer. Po zmianie jakichkolwiek ustawień serwera poczty zawsze weryfikuj faktyczne dostarczenie wiadomości do prawdziwej skrzynki odbiorczej.

6.0 Właściwe fundamenty

Wiadomości transakcyjne są o wiele ważniejsze, niż większość właścicieli sklepów o nich myśli; stanowią jedną z niewielu form korespondencji, którą klienci faktycznie czytają, ponieważ oczekują na szczegóły zamówienia lub konta. Niemarkowy, ogólny szablon wiadomości e-mail nie do końca pomaga w utrzymaniu zaufania klienta. Jednak rozwiązanie nie zawsze polega na edycji kodu HTML; czasami tłumaczenia wymagają pięciominutowej korekty, a innym razem mały moduł musi wiedzieć, kiedy dany e-mail powinien zostać wygenerowany.

Jeśli dopiero zaczynasz pracę nad swoim projektem, nie powinieneś próbować robić dwóch rzeczy naraz. Najpierw musisz poprawić swoje szablony, ponieważ samo to sprawi, że Twój sklep będzie wyglądał bardzo profesjonalnie, a następnie możesz przejść do tworzenia niestandardowych hooków opartych na logice, jeśli masz ku temu konkretny powód, jak wspomniano powyżej. 

7.0 Wersja skrócona

Każdy e-mail PrestaShop niesie ze sobą dwa oddzielne problemy: wygląd i moment wysyłki. Edycja szablonu rozwiązuje tylko pierwszy problem.

Zmiany kosmetyczne powinny być wprowadzane w ekranie tłumaczeń bez konieczności pisania kodu. Zupełnie nowe powiadomienie lub istniejący e-mail, który ma zostać wysłany w nowych warunkach, wymaga modułu łączącego się ze zdarzeniem PrestaShop i wywołującego funkcję Mail::Send().

Zanim zbudowano pełny moduł, własne haki poczty elektronicznej PrestaShop actionEmailSendBefore i podobne mogą już przepisywać, rozszerzać lub anulować wysyłkę bez konieczności nadpisywania klasy Mail.

Warto pamiętać jeszcze o jednej rzeczy: wpis „wysłane” w logu poczty oznacza jedynie wywołanie funkcji Mail::Send(), a nie to, że wiadomość dotarła do skrzynki odbiorczej. Zawsze potwierdzaj doręczenie.

Dziękuję za przeczytanie.