Blog
Form submission summaries in ProForm
May 17, 2012
I've just added a new parameter to ProForm to enable form submission summaries, in response to a client request last night.
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.
Example Usage
{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
ProForm 1.0 Released!
April 12, 2012
Tags: none
Hello, lovely ExpressionEngine community!
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
@Airways ScreenshotsNewsletter Online
March 11, 2012
The MetaSushi EE Add-ons Newsletter is now available. To stay up to date with the latest ExpressionEngine add-on news from MetaSushi, be sure to subscribe today (very low volume).
ProForm Extensions - Sending an SMS Notification
February 26, 2012
Tags: extensions, proform, ee, add-on development, twilio
ProForm has an extensive list of available hooks with which you can extend it's behavior by writing fairly simple custom extensions. You can find a complete list and description of each hook on the ProForm Extension documentation page.
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 ExtensionIf 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 HookOpen the ext.sms_custom_notification.php file and add the following code to register the proform_insert_end hook in the extension:
File: ext.sms_custom_notification.php
<?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:
HookParamsReturn proform_insert_end $module, $form_obj, $data noneDescription
This hook is called just after inserting the data
AjaxPublish + Illuminated + Publish Bar
February 04, 2012
Tags: ee, extensions, publish
I've been playing with a new extension I'm calling AJaxPublish. It basically hooks into the publish page to prevent the need for a full page reload when saving an entry.
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.
RSS Fixed
February 04, 2012
Tags: site
Looks like the RSS feed was broken there. Should be all fixed now!
New field type - Illuminated
January 19, 2012
Tags: ee, fieldtypes
Tired of struggling with a WYSIWYG editor to edit content on your site? Speak HTML? Then Illuminated is for you - a high quality editing surface that supports full syntax highlighting for HTML and JavaScript code - right in your publish page.
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
Easy custom plugins
January 11, 2012
Tags: ee, add-on development, plugins
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/.
URL: http://www.example.com/account/member_info/45
Template: account/member_info
<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="{
Channel file handling for ExpressionEngine
January 06, 2012
I've been thinking about the way that file handling is done in ExpressionEngine 2.0 lately. I think I've come up with a design that would be a lot easier to work with and provide a lot of additional options beyond what we have right now. Basically the idea boils down to this:
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:
- 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".
- 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?
New metasushi.com add-on website launched!
December 31, 2011
Just in time for the new year, I'm finally launching the all new metasushi.com!
I'm planning a series of blog posts with tutorial content on ExpressionEngine as well as my own add-ons. Stay tuned!





