![]() ![]() Our remote submission handler will define our base URL, but outside of that, the handler doesn't give us much else to do what we need to do in the UI. ![]() Ultimately, we are using a Drupal webform, to send the user to Bookdirect/Jackrabbit with their lodging search filled in. In our case, the third party site is, the client is a Destination Marketing Organization (DMO) and we need to format the submitted values to work with their jackrabbit api. We will use a remote submission handler to tell Drupal that when the form is submitted, it also needs to submit those values to a remote, third party URL. We are going to have a webform modify the submitted results into a query string, and redirect the user to a third party url with the query attached. We will look at one way to integrate the power of webforms with some third party integration and custom code. Overview: Submitting Results to a Third Party Site as a Query But every now and then a situation arises where you need to get into the guts of create some custom webform magic to get the job done. It can do even more with the multitude of its contributed modules. In Drupal 8, the Webform module can do a lot out of the box. So if you need your Drupal webforms in code and Features isn't the best option for some reason, I invite you to enjoy the ease of creating webforms programmatically with CINC.What We're Doing Here: Webforms and Third Party Integration Sensible defaults are nice.Īs an added bonus, the CINC interface can also be used to read, update, and delete existing webforms. You may look at that "city" component and think I left something out, but that's really the entire code needed for a textfield with a name matching its form_key. The code is also far more readable than both a Features export and starting from scratch, which makes it more maintainable. The line count on that (52) is less than a third of the non-CINC example on (170), and did not require any time clicking around in a browser to create and export the webform. $webform = CINC :: init ( 'Webform' ) -> machine_name ( 'Contact Us' ) $components = array ( ) $components = CINC :: init ( 'WebformComponent' ) -> set ( 'form_key', 'gender' ) -> set ( 'type', 'select' ) -> set ( 'mandatory', 1 ) -> set ( 'ems', "Mrs|Mrs \nMiss|Miss \nMr|Mr" ) -> set ( 'extra.aslist', 1 ) $components = CINC :: init ( 'WebformComponent' ) -> set ( 'form_key', 'name' ) -> set ( 'name', 'Last name' ) -> set ( 'mandatory', 1 ) $components = CINC :: init ( 'WebformComponent' ) -> set ( 'form_key', 'first_name' ) -> set ( 'mandatory', 1 ) $components = CINC :: init ( 'WebformComponent' ) -> set ( 'form_key', 'city' ) $components = CINC :: init ( 'WebformComponent' ) -> set ( 'form_key', 'country' ) -> set ( 'type', 'select' ) -> set ( 'extra.options_source', 'countries' ) -> set ( 'extra.aslist', 1 ) $components = CINC :: init ( 'WebformComponent' ) -> set ( 'form_key', 'email_address' ) -> set ( 'type', 'email' ) -> set ( 'mandatory', 1 ) $components = CINC :: init ( 'WebformComponent' ) -> set ( 'form_key', 'subject' ) -> set ( 'type', 'select' ) -> set ( 'ems', "s1|Subject 1 \nother|Other" ) -> set ( 'extra.aslist', 1 ) -> set ( 'mandatory', 1 ) $components = CINC :: init ( 'WebformComponent' ) -> set ( 'form_key', 'message' ) -> set ( 'type', 'textarea' ) -> set ( 'mandatory', 1 ) $components = CINC :: init ( 'WebformComponent' ) -> set ( 'form_key', 'mandatory_fields' ) -> set ( 'type', 'markup' ) -> set ( 'value', 'Fields with * are mandatory' ) -> set ( 'extra.format', 'full_html' ) foreach ( $components as $index => $component ) $webform -> add_email ( ) $webform -> create ( ) ![]() Here's the example linked above from, implemented in this new CINC-based approach: So I wrote the interface I wanted for creating and managing Drupal webforms, and it's now in the Config in Code (CINC) module for anyone to use. And creating a webform node from scratch seemed overly complicated to manage pre-launch. The Features-based options for creating webforms were okay pre-launch, but would add overhead post-launch. I wanted to manage webforms in code pre-launch, then hand them to a content editor to manage (outside code) post-launch. When making webforms on a recent site, none of these options appealed to me. There are a few ways you can do that, including the Webform Features module, the Universally Unique IDentifier (UUID) module or custom code, maybe following documentation on. In that context, webforms should be created automatically for a smooth, predictable launch. ![]() Drupal webforms are useful in a variety of contexts, but the most typical context is something like a contact form: user-facing functionality that needs to exist when a site launches, and be easily edited by a site owner post-launch. ![]()
0 Comments
Leave a Reply. |