Check it out:

last_step_summary="yes"

The last_step_summary parameter turns on a special mode for the last step of a multistep form, where all fields are returned by the {fields} loop. This can be used to present a summary of the form about to be submitted before the user actually submits it, giving them a chance to go back and change their responses.

Note that in order for this to work correctly, you should create an empty step at the end of the form without any fields inside of it. Otherwise the form will be expecting those fields to be set, and if they are required, it will not process the form submission.

This parameter is not supported by the Simple Form Tag since you cannot provide a custom loop for that tag and therefore it is not needed.

        {exp:proform:form form="support_request" last_step_summary="yes"}
            <!-- Step tabs, hidden fields, etc. here -->
            {if on_last_step}
                <h3>Summary</h3>
                <p>Be sure to click <b>Submit</b> to send the request.</p>
                <p>If you need to make revisions, use the Previous button or the tabs above.</p>
                <hr/>
                {fields}
                    {if field_label}
                        <p><strong>{field_label}:</strong> {field_value}</p>
                    {/if}
                {/fields}
                <hr/>
            {if:else}
                {fieldrows}
                    {fields}
                        <!-- Render fields normally based on their type (see the full example template) -->
                    {/fields}
                {/fieldrows}
            {/if}
            <!-- Previous and Submit buttons and CAPTCHA here -->
        {/exp:proform:form}
    

Results

Here's what it looks like in the browser:

I am very happy to announce the final release of ProForm 1.0.

This represents a major milestone for ProForm, and I think you'll really like the improvements I've made. This new release features an improved and much cleaner UI, multistep form support, a single template tag to render forms automatically, and even better support for 100% custom form markup. This is the biggest release for the module to date - and a lot of love and effort has gone into making it the best it can be.

I hope you like it.

Check out the new build on Devot:ee at:
http://devot-ee.com/add-ons/proform-drag-and-drop-form-builder

Read up on the new features in the documentation at:
http://metasushi.com/documentation/proform/

As always, please let me know if you have any suggestions or questions. Best contact method is through the support forums.

- Isaac

Screenshots

New template showing multiple form step support

Form settings

Entries listing

Full entry view

Form layout - the new Toolbox

Form layout - overrides

## Changelog ##

Forms
* Added multistep form support
* Added official HTML email support
* Created new Toolbar UI, which makes adding and managing fields from the form layout much easier
* Added new, single line tag to render a complete form by rendering the new sample template automatically:
   * {exp:proform:simple form="contact_us"}
* Added all-new sample template with:
   * Much better styling - and better HTML base if you want to do custom styles
   * Full multistep support
   * Default placeholders based on type and validation
   * Automatic jQuery UI selectors for date and time fields
* Added support for AJAX posting (returns form results and errors as a JSON object)
* Added support for headings inside a form
* Added option to allow redirecting data for a form to an existing DB table (experimental)
* Made all settings that ask for a field name into dropdowns

Entries
* Added options to control which columns show in entries listing
* Added new view entry page to show all fields and browser info for an entry
* Fixed some problems with entry listing pagination and incorrectly truncating values


Fields
* Added "time" field type
* Added back in real textarea field type to simplify creating these fields
* Renamed "string" fieldtype to "text", to match the HTML input type
* Added support for a blank option to lists ("i.e. 'Select an Item...' message)
* Hiding length option for fields that do not use it
* Added field option to specify if fields are reusable (where they will show up in the new Toolbar's Library section)
* Added list of forms that use a shared field to the field's edit page

Templates
* Added a {field_validation} loop inside the {fields} loop to help with custom client-side validation / styling
* Added message:* params to allow overriding validation error messages
* Added error_delimiters to allow specifying the wrapper markup for error messages
* Added variable_prefix param to allow for specifying a custom prefix for all variables (resolves potential collisions with other tags)
* Added new {hidden_fields} variable pair
* Added new {selected} variable inside of {field_setting_list} to allow reselecting items more easily
* Added support for multiselect lists and proper validation for them

Fixed Issues
* Disabled automatic Field Name generation from Field Label, if editing an existing field.
* Fixed bugs with having multiple forms on a page
* Fixed a bug where fields are not properly renamed in a form's DB table
* Fix problem with dirty warning incorrectly showing when clicking submit in some CP pages
* Fixed some bugs where IDs of Mailing Lists and Upload Preferences where incorrect due to an invalid use of array_merge
* Fixed a bug where editing a field removed form-specific overrides
* Fixed bugs in parsing some combinations of list field type options

Documentation
* Heavily updated documentation
* Added quick-start info to README
* Added installation page to documentation

Internal
* Removed requirements to set an encryption_key - config is now stored in DB and represented by a secure hash
* Added logic to make uploaded filenames unique so that they cannot be guessed
* Refactored some internal structures to be much cleaner
* Refactored handling of form sessions to be easier to work with
* Added additional notification debugging code
* Added hidden option to allow use of encrypted form data (experimental)

In this post, I'm going to walk you through a simple custom notification extension for ProForm, built using one of these hooks.

Let's say you want to send an SMS notification out to a service technician when a particular form is filled out on your site. With ProForm, we can easily accomplish this using the Twilio API and a simple custom extension.

Create the Extension

If you want to follow along, create a new blank extension using the ExpressionEngine package builder pkg.io. I'll also include the complete source code at the end of this post.

I'll be using the name Sms_custom_notification_ext for this example extension. pkg.io will create a file named ext.sms_custom_notification.php for the extension, according to the ExpressionEngine conventions.

Register the Hook

Open the ext.sms_custom_notification.php file and add the following code to register the proform_insert_end hook in the extension:

<?php // Snippet:

    public function activate_extension()
    {
        $extensions = array(
            array(
                'class'     => __CLASS__,
                'method'    => 'proform_insert_end',
                'hook'      => 'proform_insert_end',
                'settings'  => serialize($this->settings),
                'version'   => $this->version,
                'enabled'   => 'y'
            ),
        );

        foreach($extensions as $data)
        {
            $this->EE->db->insert('extensions', $data);
        }
    }

Here's the documentation for the hook that we're using:

There are two things to keep in mind: proform_insert_end is only called if validation passed for the submission, and it is not called for share type forms. For those forms, you would want to use the proform_no_insert hook instead.

Set Twilio API Settings

We'll be using the Twillio API and the twilio-php library to send our SMS message. Make sure to install the PEAR module or include it in a folder named Services within the extension package directory.

The first thing we need to do is sign up for a Twilio account. They provide a number of free SMS messages for testing, and signing up is very quick, so you should actually do it!

To create a Twilio API object, we need our sid and token values, which you can get from your profile page in Twillio. We're going to store these along with the number we want to test, and the number we are sending from (again, assigned by Twilio).

Create these new private variables on the extension class:

<?php // Snippet:

    private $twilio_sid    = 'xxxxxxxx';
    private $twilio_token  = 'xxxxxxxx';
    private $twilio_from   = '555678678';
    private $twilio_notify = '111234234'; 

Create a Hook Method

Now we will create a new method to handle this hook. We'll fill in each of these steps with a single line of code:

<?php // Snippet:

    function proform_insert_end($module, $form_obj, $data)
    {
        // 1. Create a new Twilio API object
        // 2. Send the SMS
        // 3. We haven't change the data, but we must return it:
        return $data;
    }

1. Create the Twilio API Object

First we just need to use the sid and token values to create the new object, within the proform_insert_end method:

<?php // Snippet:

    // 1. Create a new Twilio API object
    $client = new Services_Twilio($this->twilio_sid, $this->twilio_token);

2. Send the Message

The next step is to actually send the message! We're going to use the saved cell numbers we set above to do this, and construct a short summary of our form post for the on-call tech to respond to.

<?php // Snippet:

    // 2. Send the SMS
    $message = $client->account->sms_messages->create(
        $this->twilio_from,          // From Twilio number
        $this->twilio_notify,        // To admin number
        'New '.$form_obj->form_name.' post:'
        .' Name: '.$data['name']
        .' Phone: '.$data['phone']
        .' Severity: '.$data['severity']
    ); 

3. Return the Data Array

Finally, we need to return the data array (even though we did not modify it) so that the rest of the form processing will continue as normal:

<?php // Snippet:

    // 3. We haven't change the data, but we must return it:
    return $data;

That's all there is to it! We've successfully created a quick extension to send notification SMS messages to our cell phone when a new form submission is posted. This is really just scratching the surface of what is possible with ProForm and a little custom extension code.

Complete Code

<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');

// Make sure to install the PEAR module or include it in the Services folder within this extension!
// The module is available at https://github.com/twilio/twilio-php
require 'Services/Twilio.php';

class Sms_custom_notification_ext {
    
    public $settings        = array();
    public $description     = 'Sends an SMS notification when a form is submitted.';
    public $docs_url        = '';
    public $name            = 'SMS Custom Notification';
    public $settings_exist  = 'n';
    public $version         = '1.0';
    
    private $EE;
    private $twilio_sid    = 'xxxxxxxx';
    private $twilio_token  = 'xxxxxxxx';
    private $twilio_from   = '555678678';
    private $twilio_notify = '111234234';
    
    public function __construct($settings = '')
    {
        $this->EE =& get_instance();
        $this->settings = $settings;
    }
    
    public function activate_extension()
    {
        $extensions = array(
            array(
                'class'     => __CLASS__,
                'method'    => 'proform_insert_end',
                'hook'      => 'proform_insert_end',
                'settings'  => serialize($this->settings),
                'version'   => $this->version,
                'enabled'   => 'y'
            ),
        );

        foreach($extensions as $data)
        {
            $this->EE->db->insert('extensions', $data);
        }
    }
    
    function disable_extension()
    {
        $this->EE->db->where('class', __CLASS__);
        $this->EE->db->delete('extensions');
    }
    
    function update_extension($current = '')
    {
        if ($current == '' OR $current == $this->version)
        {
            return FALSE;
        }
    }
    
    function proform_insert_end($module, $form_obj, $data)
    {
        // 1. Create a new Twilio API object
        $client = new Services_Twilio($this->twilio_sid, $this->twilio_token);
        
        // 2. Send the SMS
        $message = $client->account->sms_messages->create(
            $this->twilio_from,          // From Twilio number
            $this->twilio_notify,        // To admin number
            'New '.$form_obj->form_name.' post:'
            .' Name: '.$data['name']
            .' Phone: '.$data['phone']
            .' Severity: '.$data['severity']
        );
        
        // 3. We haven't change the data, but we must return it:
        return $data;
    }
    

} 

By combining this with my field type Illuminated and the awesome Publish Bar extension, I've been able to put together a combination that almost feels like editing in a local editor like TextMate. Kind of cool if I do say so myself.

Illuminated is the anti-WYSIWYG editor - Illuminate your content and get work done.

Features output parsing to make entering content a bit easier:

• {page_url:url_title} will be replaced with the full URL to any page
• {image:filename.jpg} will be replaced with a full image tag
• {image_src:filename.jpg} will be replaced with the full URL to the image

• Purchase and Documentation on Devot:ee

Edit: I've recently (1/17/2011) given a short talk on this at the @TwinCitiesEE user group. Slides from that talk are here. Read on for more detailed discussion of the topic.

Imagine a scenario where you have some special data that you wish to query out of either built in ExpressionEngine tables or out of custom tables added by a third-party package.

Usually what most people would do at this point is resort to using the query plugin to obtain data from a custom query. However, I want to show you a better way to achieve the same kind of access to data in internal tables, but in a much safer and more controllable way.

First a little about why the query plugin isn't such a great idea in this situation. Generally, when we need to query tables in a MySQL database, we need to pass in some information that we have been given by the user or at least which has passed through the user's machine in the form of a link in a URL segment, or in a value posted to a form. For instance, you may want to get some custom member information based on a member ID. You could do this using the Query plugin like in the following example.

Imagine we have a template group named account and a template named member_info which performs this custom query. The root URL of our example site site is http://www.example.com/.

<h2>Member Info</h2>
{exp:query sql="SELECT * FROM exp_members WHERE member_id={segment_3}"}
	  Screen Name: {screen_name}<br/>
	  Registered Email Address: {email}<br/>
	  Username: {username}<br/>
	  <a href="{site_url}account/edit/{segment_3}">Edit</a>
{/exp:query}

This query is incredibly dangerous for a number of reasons.

First, imagine that we visited the following URL:

This may not look like a valid URL and you may expect ExpressionEngine to filter out this kind of request, but it is a valid URL and there is no filtering which can stop this. This request would show us all of the member information in the system.

Of course in this case we could just as easily use the current member's logged in ID - and this would be a very good way to fix this particular type of request, however most use of the Query plugin are quite a bit more complicated than this and cannot be so easily patched.

The alternative approach that I would like to recommend is to create a custom plugin that is designed to perform this exact query, and which constructs it not with SQL but instead with the CodeIgniter Active Record class.

The first step to create a new plugin is to create a package directory in the system/expressionengine/third_party folder with the name you wish to give the plugin. For instance, we might want to call this plugin "member_info", in which case we would create this directory, which must be in all lowercase:

Inside of this directory, we then need to create a PHP file with a special prefix so that ExpressionEngine knows that it is a plugin. This filename must also be in all lowercase:

After creating the plugin file, we then put in the boilerplate plugin code. You can use this as the basis of all of your custom querying plugins.

All plugins contain two major items. The first is a $plugin_info array which contains all of the meta data for this plugin. The second is the actual class that contains the plugin's custom logic.

<?php
$plugin_info = array(
    'pi_name'           => 'Example',
    'pi_version'        => '1.0',
    'pi_author'         => 'Your Name',
    'pi_author_url'     => '',
    'pi_description'    => 'Exemplifies plugins',
    'pi_usage'          => <<<USAGE
    How to call this plugin:
    {exp:example:some_query param1="something"}
    {/exp:example:some_query}
USAGE
    );

    class Example {
        public __construct() {
            $this->EE = &get_instance();
        }

        public function some_query() {
            // Get params from $this->EE->TMPL->fetch_param("param");
            // Get the contents of a tag pair as $this->EE->TMPL->tagdata;
            // Return your results as a string
        }
    }

The boilerplate plugin defines a tag named some_query, which you will want to change the name of, delete or add to. The name of your tags is completely up to you, and remember that a plugin can define multiple tags. This is useful to group all of the related custom query code for a particular site into a single file.

To continue our example, we would create the following Member_info plugin in order to replace the unsafe Query plugin call:

<?php
	$plugin_info = array(
        'pi_name'        => 'Member_info',
        'pi_version'        => '1.0',
        'pi_author'        => 'Your Name',
        'pi_author_url'        => '',
        'pi_description'    => 'Gets member information for the supplied ID',
	    'pi_usage'        => <<<USAGE
	How to call this plugin:
	{exp:member_info:query member_id="something"}
	{/exp:member_info:query}
USAGE
	);
    
	class Member_info {
	    public __construct() {
	        $this->EE = &get_instance();
	    }
	
	    public function query() {
	        // Get params fromfetch_param(). Default value is FALSE.
	        $requested_member_id = $this->EE->TMPL->fetch_param("member_id");
	        // Get the contents of the pair tag
            $result = $this->EE->TMPL->tagdata;
    
	        // Variables to be used if we can't find the member
	        $vars = array(
	            'found' => FALSE
	        );
	        if($requested_member_id) {
	            $query = $this->EE->db->where('member_id', $requested_member_id)->get('members');
	            // Check that we have at least one row
	            if($query->num_rows() > 0) {
	                // Replace the default return vars array with the result row
	                $vars = $query->row_array();
	                $vars['found'] = TRUE;
	            }
	            // Check if request is for their own data, if not we can provide less info:
	            $vars['is_current_user'] = $requested_member_id == $this->EE->session->member_id;
	        }
    
	        // Parse results variables into the output
	        $result = $this->EE->TMPL->parse_variables($result, array($row));
    
	        // Return your results as a string
	        return $result;
	    }
	}

Here's how we'll use the plugin:

	<h2>Member Info</h2>
	{exp:member_info:query member_id="{segment_3}"}
	    {if found}
	        Screen Name: {screen_name}<br/>
	        {if is_current_user}
	            Registered Email Address: {email}<br/>
	            Username: {username}<br/>
	            <a href="{site_url}account/edit/{segment_3}">Edit</a>
	        {/if}
	    {if:else}
	        Invalid request.
	    {/if}
	{/exp:member_info:query}

Using a custom plugin with CodeIgniter's Active Record class gives us two main advantages in this example:

1. The contents of the member_id value are automatically escaped for us by the where() method so that we cannot suffer injection attacks. The previous attack URL will simply print out "Invalid request" now.
2. Our query will still work even if the DB prefix is changed since the get() method prefixes it for us automatically (we only passed in "members" rather than "exp_members" like we have to with the query tag).

Other advantages are:

• We can control the data that is queried with much more flexible conditional statements.
• We can cache the data or stop queries if they have been run too often.
• We have more precise control over the output of values.
• We can more easily filter and modify the parameters sent in to query the database.
• We can more easily provide default values (such as date ranges).

Once you get used to this technique it actually becomes just as easy as using the built in query plugin, and provides much more security and flexibility for very little time investment. I'd highly recommend trying it the next time you need to create a custom query of any kind on a project!

Files should be stored as channel entries.

Actually, the idea is pretty obvious just from looking at the UI of ExpressionEngine 2.0. The Files listing is even put under the Content menu item, and has a very similar look to the listing of channel entries - but where it breaks down with the current implementation is the backend. Files aren't stored as channel entries, even though the UI implies that they would be.

Imagine being able to create multiple File Channels, each one with it's own meta data fields created as Channel Fields. Relationship fields like Playa would allow more complex relationships between files and the content that uses them. Every existing custom field type could be used to provide really advanced meta data for file uploads. The possibilities are endless.

Basically this implementation would need two things:

1. Create a simple File Upload field that is available in all channels. Create a Channel Preference that shows or hides this field. Each channel with this option enabled becomes what we currently know as a "File Upload Preference".
2. Re-work file management UI (including the built in File upload field type) to use this new data backend instead of the current files tables and File Upload Preferences.

So that's my idea. Your thoughts?

I'm planning a series of blog posts with tutorial content on ExpressionEngine as well as my own add-ons. Stay tuned!