Tag Archives: Ideas

11.19.12
by

Adding Custom Post Types to WordPress Google Form

I have been thinking about migrating WordPress Google Form from a shortcode based solution to a Custom Post Type solution.  Today I decided to move from thinking about it to acting on it.  As I add more features the short code complexity has grown quite a bit.  Because the short code contains URLs with special characters, the chance of introducing a syntax error is very high and it is by far the most common support request I receive.

There are a lot of benefits to adding a custom Post Type, among them:

  1. Reduced syntax errors.
  2. Shorter short codes.
  3. No chance of misspelling attribute names.
  4. No chance of having duplicate (or triplicate!) attributes and wondering why the first value isn’t working.
  5. Possibility of having form specific CSS.

I plan to retain the current short code syntax so existing installations will continue to work but will introduce a new short code (likely [wpgform id=’N’]) which can be used in place of the current short code.  Over time I will likely deprecate the older short code but not anytime soon.

The primary reason I am doing this is my desire to connect Google Forms with PayPal which I think I can do using a hook in Woo Commerce.  Having the Google Form as a very simple short code will help me do what I want to do (I think).

11.14.12
by

Adding columns to a WordPress Google Form?

I’ve received a few queries as to how a Google Form could be styled such that the form would appear to have columns.  I’ve looked at the HTML and CSS that Google provides and if it can be done in CSS, it is beyond my current CSS skill set!

That said, I think it is an interesting question and I had looked at solutions using jQuery a few months ago.  I saw one jQuery plugin in particular that looked promising but didn’t have much time to really dig into it at the time.

I received another request for columns today so I took a look at the problem again to see how hard it would be.  Here is one of my example forms split into two columns to give an idea of what this might look like:

I am using the jQuery Columnizer plugin to automatically split the form into columns in conjunction with some other jQuery to manipulate the form and add some additional DIVs which will make additional styling easier.

I am generally pleased with how it came out.  I am going to play with it a little more before releasing an update but wanted to provide a preview in case anyone had an suggestions or questions.

04.24.12
by

WordPress Google Form Enhancements

Several people have asked for enhancements, many of which are similar. The most common request is to add either pre-filled or hidden fields based on something WordPress knows about. A recent request was to add tracking so a form could only be submitted by a user once. I am certainly not opposed to adding features like these, I think most would be pretty useful. However, there are some things to think about before implementing a solution or adding new features.

  1. To auto-fill a field or populate a hidden field, the field must be mapped from what the column is called on the Google Docs side of the form to something WordPress knows about (e.g. username, email address, etc.). How should this mapping be done? Arguments as part of the shortcode? For anything to be posted to the form processor on the Google side, the field must be defined on the form so the results spreadsheet has a corresponding column. For hidden fields, wpGForm would have to turn what is an existing field (which may or may not be a simple text box) into a hidden field with a value supplied by WordPress. This isn’t impossible, jQuery can do much of the work fairly easily but the problem is it is fraught with potential errors so I am reluctant to add it until I have a better idea how to bullet proof it. Pre-populating values is fairly easy, as long as we know what the field name
  2. I’ve considered, and posted about, introducing a Custom Post Type for forms. If I do this, then it makes addressing the tracking aspect fairly easy because the CPT id could be stored as part of the users meta data. That is pretty straight forward once the CPT exists (which it doesn’t yet). However, it does require the user to be logged into the site which many people don’t want to allow. This could also be handled by the CPT which could in theory, define a new form as anonymous or not. An anonymous form would have some limitations, tracking being one of them.

I’ve got some ideas on how to implement these features, most of which would be pretty useful. Introducing a CPT is absolutely on my radar screen but right now I am focused on my Swim Team plugin as we’re gearing up for Summer Swim Season here in North Carolina. Once I knock out my to-do list on the Swim Team plugin I’ll come back and look at adding the CPT for WordPress Google Forms which would facilitate adding some of the requests people have asked for.

03.10.12
by

Possible Enhancements for wpGForm

Recently I have had a couple requests for enhancements to wpGForm. One of the recent ones was the ability to define hidden fields on a form to capture some data from a WordPress user.

Currently Google’s forms define fields like this:

<input id="entry_0" class="wpgform_ss-q-short" type="text" value="" name="entry.0.single">

It would not be too hard to add an attribute like hidden=’entry_0,entry_2,
entry_27′ to the shortcode. I could even do something like
hidden=’entry_0=email,entry_2=username,entry_27=first_name,entry_28=last_name’ where the “allowable” presets would have to map to the fields which can be returned by get_userdata() see:
http://codex.wordpress.org/Function_Reference/get_userdata Of course all of this predicates that the user is logged in so those fields exist.

I’ve also considered changing the plugin to allow for more complicated things – adding more options to the shortcode could get pretty cumbersome. What’ve I thought about is doing leveraging the Dashboard (using a Custom Post Type) to Manage Forms where you “Add” a form and the Dashbaord provides a GUI where all sorts of information would be added:

1. Form URL
2. Confirmation URL
3. Switches for all of the other options (legal, read-only, etc.)
4. More things I haven’t thought about

Forms could then be “Edited/Deleted/etc.” just like other post types. Then you’d simply embed the form using a simple shortcode like [wpgform id='1']. The rest of the information would be stored inWordPress as custom Post Type fields. I’d probably define a new shortcode for this so the current one would continue to work but that is the general idea.

Thoughts?

10.16.11
by

How to have a Meta Box appear before the Visual Editor

I am working on a new theme where I have defined a Custom Post Type.  This is my first time working with Custom Post Types and I must say they are pretty slick.  I wish they had existed back when I first started working on my Swim Team plugin!  I have far too much invested in my Swim Team plugin so I’ll stick with the custom database tables but for this new project, CPTs are working great.

Once I got my CPT defined and basically working, I wanted to add some custom fields to it using a Meta Box.  There are numerous articles that outline how to do it, I referenced this one quite a bit and found it very helpful.  In my instance, the Meta Box that holds all of the custom fields I want to collect is more important that the Visual Editor is so I wanted it to appear higher on the screen.

After poking through the Codex and number of Google searches, it appears that doing what I want to do isn’t native WordPress functionality.  I did however find this post which outlines an idea for moving the Meta Box so it appears on top of the Visual Editor.  Awesome.  Exactly what I was looking for. Except the code fragment didn’t work.  After looking at it, I decided the idea was sound but the implementation wasn’t correct or at least wasn’t correct in my application.

I tweaked the Javascript to make sure the document was ready before rearranging the Meta Box and Visual Editor and got the result I was looking for.  Here is the code I am using in my functions.php file.

/**
 * Set up a footer hook to rearrange the post editing screen
 * for the 'CPT' custom post type.  The meta box which has all
 * of the custom fields in it will appear before the Visual Editor.
 * This is accomplished using a simple jQuery script once the
 * document is loaded.
 */
function CPT_admin_footer_hook()
{
    global $post ;

    if (get_post_type($post) == 'CPT')
    {
?>
<script type="text/javascript">
    jQuery(document).ready(function($) {
        $('#normal-sortables').insertBefore('#postdivrich') ;
    }) ;
</script>

<?php
    }
}

/**  Hook into the Admin Footer */
add_action('admin_footer','CPT_admin_footer_hook');
06.10.10
by

Exploring Roles and Capabilities

I’ve had a request from my team, the MacDolphins, to be able to send e-mail to the parents of specific age groups.  We do a number of activities that are limited to older kids or only for a specific age group so I’ve been aware of this need for a while.  Unfortunately I don’t have an easy way to solve it.

I think the WordPress Roles and Capabilities functionality may be the answer to my problem.  I could create a role for each age group and assign the users that have a swimmer in that age group to the appropriate roles.  By doing this, I think I can continue to use the Email Users plugin to contact specific groups of users based on the roles defined.

I need to do more research on Roles and Capabilities.  I’ve played with a couple plugins and they aren’t real straight forward.