W tym samouczku pokażę, jak stworzyć zaawansowany niestandardowy typ pola Gravity Forms. Pole będzie zawierało wiele danych wejściowych i będzie wymagało specjalnej obsługi w celu przechowywania i wyświetlania przesłanych wartości.

Co zrobimy

W tym przykładzie przyjmuję przykład właściciela witryny WordPress, który zajmuje się dostawami obiadów w miejscu pracy. Właściciel ma formularz, w którym ludzie mogą wypełnić, jakiego rodzaju lunchu chcą i ile na każdy dzień tygodnia. Można to rozwiązać za pomocą podobnej do tabeli metody wprowadzania liczby dla dowolnego kursu w dowolnym dniu, w którym mają być dostarczane.

Kursy można edytować w ustawieniach pola w edytorze formularzy i można je zmienić w dowolnym momencie. A przy każdym przesłaniu formularza właściciel witryny otrzymuje pełny przegląd przesłanych wartości:

Oczywiście to tylko przykład i prawdopodobnie musisz to dostosować do swojego przypadku. Ale w tym przykładzie mamy szansę nauczyć się obsługi wielu danych wejściowych w jednym polu. Powinien dać ci kilka pomysłów na to, jak radzić sobie z własnym typem pola niestandardowego.

Przed rozpoczęciem kodowania

Zanim zaczniemy potrzebujemy miejsca na dodanie naszego kodu. Możesz dodać to do swojego motywu functions.phplub pliku wtyczki.

Wybrana przeze mnie metoda jest zorientowana obiektowo, co oznacza stworzenie klasy, która rozszerza klasę Gravity Forms GF_Field. Polecam umieścić klasę w osobnym pliku w swoim projekcie. Powinieneś również sprawdzić, czy wtyczka Gravity Forms istnieje przed włączeniem Twojej klasy, aby zapobiec awariom Twojej witryny.

Jeśli jesteś zainteresowany, możesz zajrzeć do dokumentacji Gravity Forms na GF_Field. Znajdziesz więcej funkcji i zmiennych, które mogą być potrzebne dla Twojego typu pola.

Rozszerzając GF_Fieldklasę możemy po prostu wybrać nadpisanie funkcji, które musimy zmienić. Jeśli chodzi o funkcje, których nie zastępujemy, Gravity Forms uruchomi domyślnie zdefiniowane wewnątrz GF_Field. W poniższym samouczku omówimy kolejno każdą funkcję, którą musimy zastąpić dla naszego niestandardowego pola. Bez zbędnych ceregieli zacznijmy!

Tworzenie niestandardowego typu pola

Pierwszym krokiem jest zdefiniowanie niestandardowej klasy PHP, która rozszerza GF_Field. Nadaj klasie unikalną nazwę i upewnij się, że jest ona uwzględniona w Twoim projekcie. Po definicji klasy uruchamiamy funkcję register()statyczną GF_Fieldprzekazując instancję naszej klasy jako parametr. To inicjuje naszą klasę i rejestruje typ pola.

Jedyną wymaganą zmienną, której potrzebujesz w swojej klasie, jest $type. Zmienna klasy $typemusi być unikatowa i jest nazwą informacji o pracy typu pola. W moim przykładzie nazwałem go „ food_delivery".


if (class_exists('GF_Field')) {
    class FoodDelivery extends GF_Field {
        public $type = 'food_delivery';
 
        // The rest of the code is added here...
    }
    GF_Fields::register(new FoodDelivery());
}

Z tym małym fragmentem kodu, nasz niestandardowy typ pola powinien zostać dodany jako dostępny wybór w edytorze Gravity Forms. Domyślnie pojawia się na końcu pola „Standardowe pola”. Ponieważ nie nadaliśmy jeszcze naszemu polu właściwej nazwy (kolejny krok), przycisk jest oznaczony jako wartość $type.

Definiowanie nazwy pola

Następny krok jest łatwy; po prostu nadając naszej dziedzinie lepszą nazwę. W tym celu zastępujemy funkcję get_form_editor_field_title(). Wszystko, co musimy zrobić, to zwrócić ciąg z nazwą pola.


public function get_form_editor_field_title() {
    return esc_attr__('Food Delivery', 'txtdomain');
}

Dzięki tej funkcji w naszej klasie przycisk dodawania pola jest aktualizowany o znacznie lepszą etykietę.

Zmiana kategorii pola

Ten krok jest opcjonalny. Domyślnie nasz niestandardowy typ pola pojawia się w polu „Standardowe pola”, ale możemy to zmienić. Załóżmy, że chcemy, aby zamiast tego pojawił się w polu „Zaawansowane pola”.

Aby zmienić kategorię, w której ma się pojawić pole, nadpisujemy funkcję get_form_editor_button(). Musimy zwrócić tablicę asocjacyjną z dwoma elementami. Jako wartość klucza „ group” podajesz wewnętrzną nazwę kategorii, w której ma się pojawiać przycisk. Dostępne opcje to „ standard_fields“, „ advanced_fields“, „ post_fields” lub „ pricing_fields“. (Możesz także stworzyć własną kategorię, ale nie jest to tutaj omówione). Drugi element tablicy potrzebuje klucza ‘ text‘ iw tym celu po prostu zwracamy nazwę pola wywołując get_form_editor_field_title(). Jest to funkcja, którą właśnie stworzyliśmy powyżej.

Teraz przycisk dodawania naszego niestandardowego typu pola został przeniesiony do pola „Zaawansowane pola”.

Aktywacja ustawień pola

Jeśli próbowałeś dodać typ pola do formularza, mogłeś zauważyć, że nie ma żadnych ustawień. Nie możesz nawet edytować etykiety. Sposób, w jaki to działa, polega na tym, że wszystkie typy ustawień faktycznie tam są, po prostu wszystkie są ukryte za pomocą CSS przez Gravity Forms. Musimy indywidualnie określić, które ustawienia chcemy włączyć, a Gravity Forms wyświetli dla nas wybrane ustawienia.

Musimy zdefiniować funkcję get_form_editor_field_settings()i zwrócić tablicę wszystkich ustawień, których nie chcemy ukrywać dla naszego typu pola. To, które ustawienia chcesz dodać, zależy wyłącznie od Ciebie i Twojego projektu. Pamiętaj, że Twoje pole powinno obsługiwać dowolne ustawienia, które aktywujesz, w przeciwnym razie pokazywanie ustawień dla niego nie ma sensu.

Poniżej utworzyłem krótki przegląd nazw ustawień. To nie jest pełna lista – ponieważ istnieje wiele ustawień, które są przydatne tylko dla bardzo specyficznych typów pól. Na przykład format telefonu, format daty/godziny i cała masa ustawień związanych z polami postu i cenami.

Zakładka Ogólne

Etykieta pola:label_setting
Opis pola:description_setting
Wybory:choices_setting
Wymagany:rules_setting
Brak duplikatów:duplicate_setting
Włącz kolumny:columns_setting
Włącz opcję „zaznacz wszystko”:select_all_choices_setting
Włącz opcję „inny”:other_choice_setting

Zakładka Wygląd

Symbol zastępczy:placeholder_setting
Widoczność etykiety pola i umieszczenie opisu:label_placement_setting
Niestandardowa wiadomość weryfikacyjna:error_message_setting
Niestandardowa klasa CSS:css_class_setting
Rozmiar pola:size_setting

Zakładka Zaawansowane

Etykieta pola administratora:admin_label_setting
Domyślna wartość:default_value_setting
Włącz wprowadzanie hasła:password_field_setting
Wymuś SSL:force_ssl_field_setting
Widoczność:visibility_setting
Zezwalaj na dynamiczne wypełnianie pola:prepopulate_field_setting
Włącz logikę warunkową:conditional_logic_field_setting
Włącz logikę warunkową strony:conditional_logic_page_setting

W naszym przykładzie najważniejsze są etykieta pola, opis, wybory i to, czy pole jest wymagane, czy nie. Zezwalamy również na ustawienia klasy CSS, niestandardowy komunikat walidacyjny i logikę warunkową.


public function get_form_editor_field_settings() {
    return [
        'label_setting',
        'choices_setting',
        'description_setting',
        'rules_setting',
        'error_message_setting',
        'css_class_setting',
        'conditional_logic_field_setting'
    ];
}

Odśwież edytor formularzy i powinieneś teraz zobaczyć wszystkie wybrane ustawienia i zakładki w naszym polu. Wszystkie ustawienia są obsługiwane i zapisywane automatycznie przez Gravity Forms.

Śmiało i dodaj kilka pozycji na liście Wybory, abyśmy mieli nad czym pracować. Oto, co ustawiłem jako przykład:

Definiowanie niestandardowych opcji domyślnych

Jeśli jesteś przyzwyczajony do używania np. przycisków radiowych lub pól wyboru w formularzach grawitacyjnych, prawdopodobnie zauważyłeś, że są one napędzane opcjami takimi jak „Pierwszy wybór”, „Drugi wybór”, „Trzeci wybór”. Jest to domyślne zachowanie z Gravity Forms, jeśli nie zapisano żadnych wyborów (wcześniej) i uruchamia się to tylko w tych określonych typach pól. Ale w przypadku naszego niestandardowego typu pola nie zostaną wypełnione żadne opcje. To sprawia, że jest to trochę kłopotliwe, ponieważ nie dostaniesz przycisku „+”, aby dodać kolejny wybór. Musisz użyć przycisku „Dodaj zbiorczo/predefiniowane opcje”, dodać tam kilka opcji, a następnie uzyskasz dostęp do przycisków „+”, aby dodać opcje. Ale łatwo jest zdefiniować niektóre niestandardowe opcje – wystarczy zdefiniować zmienną tablicową klasypublic $choicesa Gravity Forms automatycznie wygeneruje wstępnie zdefiniowane wybory w twoim polu, gdy dodasz je do swoich formularzy.

Uwaga: to jest zmienna klasy, którą możesz dodać u góry klasy, tuż poniżej public $type. Każdy wybór musi być tablicą, a wybór jest wartością klucza „ text“.

Pamiętaj, że jeśli już dodałeś to pole do formularza, nie wypełni ono opcji z mocą wsteczną. Działa to tylko wtedy, gdy do formularza dodasz nowe pole.

Uwaga: W Gravity Forms wydaje się, że możliwe jest również dodanie kluczy ‘ value‘ do każdego wyboru. Ale nie udało mi się to zadziałać – wartości automatycznie staną się takie same jak tekst wyboru.

Definiowanie wartości pola jako tablicy

Następny krok jest dość prosty, ale konieczny. Domyślnymi wartościami pól w Gravity Forms są łańcuchy. Potrzebujemy, aby wartość była tablicą, ponieważ pracujemy z wieloma danymi wejściowymi. W tym celu definiujemy funkcję is_value_submission_array()i return true.


public function is_value_submission_array() {
    return true;
}

Gwarantuje to, że możemy poprawnie pracować z wprowadzoną wartością naszych wielu danych wejściowych.

Renderowanie danych wyjściowych pola

Jeśli chodzi o renderowanie danych wyjściowych pola, należy pamiętać o kilku rzeczach.

Po pierwsze, musisz wybrać między dwiema funkcjami; get_field_input()lub get_field_content(). W pierwszej metodzie Gravity Forms automatycznie renderuje element listy zawijania, etykietę, opis i pojemnik dla komunikatu o błędzie walidacji do twojego pola i kontrolujesz tylko wewnętrzne wyjście pola. W przypadku drugiej metody nic się nie dzieje i masz większą kontrolę nad danymi wyjściowymi pola. Musisz jednak ręcznie wyrenderować etykietę, opis i komunikaty o błędach. Pierwsza metoda, get_field_input(), jest w większości przypadków odpowiednia.

Drugą rzeczą, o której należy pamiętać, jest to, że funkcja renderowania pola wpływa na trzy różne lokalizacje. Te trzy to renderowanie danych wyjściowych pola w interfejsie użytkownika, podgląd pola w edytorze formularzy i wreszcie pole podczas edycji wpisu. Na szczęście Gravity Forms oferuje funkcje, które pozwalają łatwo określić, na jakim widoku się znajdujemy. Zazwyczaj renderujesz pole w ten sam sposób we wszystkich trzech przypadkach. Ale ponieważ renderowanie dużej tabeli z wieloma danymi wejściowymi staje się niepotrzebne w edytorze formularzy, zdecydowałem się renderować pole inaczej w edytorze formularzy.

I na koniec musimy upewnić się, że wszelkie dane wejściowe otrzymają odpowiedni nameatrybut, aby Gravity Forms mógł zebrać jego wartość po przesłaniu formularza. Wszystkie dane wejściowe w Gravity Forms wymagają nameatrybutów zgodnych z tą zasadą: name="input_{FIELD_ID}"(pola wielokrotnego wyboru używają dodatkowego identyfikatora, ale nie musimy się tym martwić w naszym przypadku). Mamy dostęp do identyfikatora pola, ponieważ jest to zmienna klasy (z GF_Field). Ale w naszym przypadku powiedzieliśmy Gravity Forms, że wartość jest tablicą, a nie wartością pojedynczą (poprzedni krok), więc dodajemy nawiasy kwadratowe po atrybucie name; name="input_{FIELD_ID}[]". Jeśli więc pole ma ID 4 wewnątrz formularza, atrybutem nazwy powinien być „ input_4[]“.

Zdecyduję się na użycie get_field_input(), które ma trzy parametry. Pierwszym parametrem jest obiekt formularza, którego tak naprawdę nie potrzebujemy w naszym przykładzie. Drugi parametr to aktualna wartość. Może to być wartość pola z $_POSTchwili, gdy próba przesłania formularza zakończyła się niepowodzeniem. Możemy zachować poprzednio zgłoszone wartości. Lub jeśli funkcja działa podczas edycji wpisu, wartość będzie wartością przechowywaną z przesłanego zgłoszenia. Później zajmiemy się tą wartością. A trzeci parametr to obiekt wejściowy, którego również nie będziemy potrzebować w naszym przykładzie.

Zacznijmy od implementacji get_field_input(), która oczekuje ostatecznego renderowania jako ciągu. Prosto z nietoperza postanawiam zwrócić pusty ciąg, jeśli jesteśmy w edytorze formularzy – ponieważ nie chcę renderować pełnej tabeli w tym widoku. Możemy użyć tej metody, $this->is_form_editor()aby sprawdzić, czy jesteśmy w edycji formularza. Możesz to pominąć lub wyrenderować coś innego, jeśli chcesz wyświetlić podgląd pola w edytorze formularzy.

Następnym krokiem jest zbudowanie kodu HTML tabeli, która zapętla się przez tablicę dni w celu wygenerowania kolumn i wierszy dla każdego elementu kursu. Ale ponieważ potrzebujemy dostępu do tablicy dni (kolumn tabeli) w wielu miejscach, powinniśmy zdefiniować ją jako zmienną klasy, dzięki czemu jest dostępna z dowolnych funkcji w niej zawartych. Definiuję zmienną klasy $delivery_daysz tablicą dni, na które chcę zaoferować dostawę.


class FoodDelivery extends GF_Field {
    public $type = 'food_delivery';
 
    private $delivery_days = ['Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday'];
 
    public function get_form_editor_field_title() {
        ...
}

To tylko przykład! Możesz chcieć pobrać tablicę dla kolumn z innego miejsca, które nie jest zakodowane na stałe.

Wróćmy get_field_input()i zbudujmy naszą tabelę z danymi wejściowymi. Najpierw zapętlę zmienną klasy i wygeneruję nagłówki tabeli. Następnie przeglądam opcje wprowadzone w ustawieniach pola dla opcji Wybory. Jest to dostępne ze zmiennej klasy (from GF_Field) $this->choices. Dla każdego wyboru renderuję dane wejściowe z odpowiednimi atrybutami nazwy. Mamy dostęp do identyfikatora pola ze GF_Fieldzmiennej klasy $this->id.

Z tym kodem powinniśmy otrzymać ładną tabelę wyrenderowaną dla naszego typu pola w interfejsie użytkownika! Oczywiście HTML zależy wyłącznie od Ciebie, to tylko podstawowy przykład.

Na razie zostawiamy tę funkcję, ale wrócimy do niej później, aby obsłużyć przesłaną wartość!

Prawidłowe przechowywanie wartości

W tej chwili Gravity Forms zapisze nasze pole jako jednowymiarową tablicę wypełnioną wprowadzonymi wartościami i pustymi ciągami, w których dane wejściowe były puste. Poza indeksem nie ma informacji o dniu lub wyborze, do którego należy wartość. Musimy przekształcić tę jednowymiarową tablicę w wielowymiarową tablicę asocjacyjną, w której przechowujemy dzień i etykietę wyboru. Możemy wtedy łatwo uzyskać dostęp do zapisanej wartości liczbowej, np $value['Ham sandwich']['Monday'].. Po tej transformacji tablicy musimy również serializować tablicę, aby Gravity Forms mogła prawidłowo przechowywać wartość w bazie danych.

Będziemy musieli przekształcić tę tablicę wartości w wiele miejsc, więc zdefiniuję do tego osobną funkcję. Funkcja akceptuje tablicę jednowymiarową i przekształca ją w tablicę wielowymiarową z przechowywanymi wartościami dla dni i wyborów:

Spowoduje to zapisanie nazw dni i wyborów bezpośrednio w wartości pola. Robienie tego w ten sposób umożliwia późniejszą zmianę wyborów bez naruszania starych wpisów.

Przejdźmy teraz do nadpisania funkcji obsługującej przechowywanie przesłanej wartości; get_value_save_entry(). Ma pięć parametrów, ale potrzebujemy tylko pierwszego, który jest przesłaną wartością. Wewnątrz funkcji przekazujemy wartość do naszej funkcji niestandardowej powyżej, serializujemy jej zwrot i ostatecznie zwracamy nową wartość.

W tym momencie Gravity Forms z powodzeniem przechowa nasze wartości tak, jak tego chcemy! Jednak przechowywana wartość jest teraz zserializowaną tablicą, którą Gravity Forms z radością odezwie się wprost. Musimy zaimplementować funkcje, aby przekształcić go z brzydkiej zserializowanej tablicy w jakieś ładne wyjście, gdziekolwiek tego potrzebujemy.

Wyświetlanie przesłanej wartości

Są trzy miejsca, w których musimy zmienić wyjście wartości naszego pola; listę wpisów, patrząc na pojedynczy wpis i w obrębie znaczników scalania Gravity Forms. Tagi scalania są najczęściej używane w powiadomieniach e-mail. Przykładem {all_fields}może być znacznik scalania, który wyświetla pełne wartości przesłanego formularza w wiadomościach e-mail.

Ponieważ renderujemy to samo wyjście w trzech różnych przypadkach, sensowne jest utworzenie dla niego oddzielnej funkcji. Zdefiniowałem funkcję niestandardową, która akceptuje wartość; nieserializowana tablica wielowymiarowa jako parametr. Funkcja następnie buduje kod HTML, który wyświetla tablicę w ładny sposób i zwraca ciąg. Zdecydowałem się na <ul>listę zagnieżdżoną, ale możesz zmienić wynik w dowolny sposób.

Świetnie, zacznijmy od pierwszego: listy wpisów: get_value_entry_list(). Możesz wybrać, aby wyświetlić pełne dane wyjściowe tutaj, ale widok listy może być dość niezgrabny i długi, więc zdecydowałem się po prostu zwrócić stały ciąg, który wyjaśnia, że użytkownik musi przejść do szczegółów wpisu, aby zobaczyć pełny przegląd.


public function get_value_entry_list($value, $entry, $field_id, $columns, $form) {
    return __('Enter details to see delivery details', 'txtdomain');
}

To oczywiście zależy wyłącznie od Ciebie, możesz na przykład wybrać wyświetlanie tylko pierwszej liczby x znaków.

Druga funkcja to ta, która wpływa na widok pojedynczego wpisu: get_value_entry_detail():

Po prostu usuwamy numer seryjny tablicy za pomocą funkcji WordPressa [maybe_unserialize](https://developer.wordpress.org/reference/functions/maybe_unserialize/)()i zwracamy wynik ciągu z naszej niestandardowej funkcji.

Ostatnia funkcja wpływa na znaczniki scalania i zapewnia, że wartość naszego pola wygląda dobrze również w wiadomościach e-mail: get_value_merge_tag().

Zwróć uwagę, że nie będziemy musieli usuwać numeru seryjnego wartości wewnątrz tej funkcji.

Dzięki tym trzem funkcjom wszystkie przesłane wartości powinny wszędzie wyglądać całkiem dobrze! Na przykład podczas przeglądania przesłanego wpisu:

Brakuje jednak jednej ważnej rzeczy! W tym momencie nasze dane wejściowe nie zachowują wcześniej przesłanych wartości, a to jest dość złe.

Spraw, aby nasze dane wejściowe zachowały wcześniej przesłaną wartość

Istnieją głównie dwa przypadki, w których musimy upewnić się, że dane wejściowe zachowują wcześniej przesłane wartości. Pierwszy przypadek ma miejsce, gdy przesłanie formularza nie powiodło się (na przykład użytkownik zapomniał wymaganego pola). W tej chwili wszystkie nasze dane wejściowe tracą wszystkie wcześniej wprowadzone wartości, a użytkownik musi ponownie wprowadzić wszystkie wartości. Po drugie, gdy właściciel witryny edytuje wpis, dane wejściowe nie są wypełniane przesłanymi wartościami ze zgłoszenia – co uniemożliwia prawidłową edycję wartości.

Aby to naprawić, wracamy do funkcji get_field_input(). Drugim parametrem tej funkcji jest wartość. Pamiętaj jednak, że ta funkcja wpływa zarówno na renderowanie frontendu, jak i edycję wpisów. Jest to ważne, ponieważ przechowywana wartość jest różna w tych dwóch przypadkach. Jeśli jesteśmy na froncie i obsługujemy przesyłanie formularzy, wartość jest w formacie tablicy jednowymiarowej, o której mowa wcześniej. A jeśli edytujemy wpis, wartość jest w formacie szeregowanej tablicy wielowymiarowej. Musimy więc odpowiednio przetłumaczyć podaną wartość, get_field_input()aby łatwo uzyskać dostęp do rzeczywistych wartości.

W powyższym kodzie, zanim zaczniemy tworzyć kod HTML dla wyjścia pola, tworzymy zmienną $table_valuezawierającą poprawnie przetłumaczoną wartość. Używamy GF_Fieldfunkcji, is_entry_detail()aby sprawdzić, czy edytujemy wpis, czy nie. A następnie dla naszych danych wejściowych łatwo jest uzyskać dostęp do odpowiednich wartości i ustawić je jako valueatrybuty danych wejściowych:

Po zaktualizowaniu powyższego get_field_input()wszystkie nasze niestandardowe dane wejściowe powinny zawsze być wypełnione poprzednią wartością; bez względu na to, czy edytujesz wpis, czy ponawiasz próbę przesłania formularza.

W tym momencie wszystko, co dotyczy renderowania i przechowywania naszych wartości, jest już gotowe i w pełni działa. Ale jest jeszcze jedna rzecz, którą zdecydowanie musimy naprawić.

Spraw, aby nasza przepustka terenowa była „wymagana” walidacja

Formy grawitacyjne mają kontrole, aby sprawdzić, czy wartość pola jest pusta, czy nie. Jest to często konieczne, gdy pole jest ustawione zgodnie z wymaganiami. Gdy pole jest wymagane, nie możesz przesłać formularza, jeśli jest puste, prawda? Problemem jest dla nas to, że mamy wiele wejść i chcemy, aby niektóre z nich były puste. Staje się to problemem, jeśli nasze pole jest ustawione na wymagane. Gravity Forms niestety źle interpretuje „czy to jest puste” i wymaga wypełnienia wszystkich danych wejściowych. Musimy więc dodać regułę, która mówi, że jeśli przynajmniej jedno z wielu danych wejściowych jest wypełnione, całkowita wartość pola nie jest pusta.

Ostatnią funkcją, którą musimy przesłonić w naszej klasie, jest is_value_submission_empty(). Jako parametr tej funkcji otrzymujemy tylko identyfikator formularza, więc musimy wyodrębnić wartość pola za pomocą funkcji Gravity Forms, aby pobrać ją z $_POSTtablicy: rgpost('input_<FIELD ID>'). Zwrot powinien być jednowymiarową tablicą, którą widzieliśmy wcześniej. Wszystko, co musimy zrobić, to przejść przez tablicę i wrócić false, jeśli gdzieś znajdziemy wartość. W przeciwnym razie zwracamy, trueponieważ wartość pola jest rzeczywiście całkowicie pusta.

Z powyższą funkcją w miejscu, nasze pole nie zawiedzie, jeśli jest ustawione na wymagane i co najmniej jedno wejście jest wypełnione.

Wniosek i kod końcowy

Ten samouczek pokazał ci szczegółowo, jak stworzyć własny niestandardowy zaawansowany typ pola dla Gravity Forms. Nawet jeśli twój projekt jest inny niż mój przykład, mam nadzieję, że masz kilka wskazówek i a-ha po drodze. W niektórych przypadkach brakuje mi dokumentacji Gravity Forms, co jest wynikiem wielu prób i błędów! W każdym razie, miejmy nadzieję, że przydało ci się to!

Dla odniesienia, oto kompletny kod w całości:

Źródło nagrywania: awhitepixel.com