I am currently running a beta version of wpGForm v0.11 here on my site. The big change for this version if the support for multi-page Google Forms. You can see how they work using my Sample Multi-Page Google Form.
I am looking for some people to test this version and provide feedback. If you can check it out and provide some feedback I’d really appreciate it. There are quite a few changes in this version due to the rearchitecture required to support multi-page forms. There shouldn’t be any changes to what is actually rendered for the user.
This version also fixes the confirmation page bug that has been present when a custom confirmation page wasn’t specified. The behavior of the custom confirmation page is slightly different too in this version.
I’ve been trying to find a solution that will allow wpGForm to support multi-page Google Forms. I realize that this is a pretty important feature for people who use Google Forms and my lack up updates or news isn’t from lack of effort! I’ve tried a number of things, each of which hasn’t worked out.
The single page Google Form works pretty well but even with it, there are still a couple of minor nits (e.g. properly handling optional fields). I’ve thought that if I can find a better way to handle multi-page forms that I may also be able to eliminate the limitations that single page forms have too.
The problem with trying to do what I am trying to do is that Google Forms aren’t really designed to be anything but their own entity. Yes, you can embed them with an IFRAME tag and they will work correctly but there is no way to modify the HTML in an IFRAME due to Cross Site Scripting (XSS) security concerns. Yesterday I thought I had a clever solution that used jQuery and AJAX to load to the result from a form submission using a small script within the plugin to submit the form and then WordPress could load the results from the plugin script eliminating the XSS concern but I couldn’t get it to work reliably (and it was slow).
I’ve been using wp_remote_get() to retrieve the contents of the Google Form since I started this plugin. Why it never occurred to me (until last night) to use wp_remote_post() to submit the form to Google I have no idea. This was one of those “Doh!” moments we (at least I do and I am pretty sure I am not alone) have when you simply get caught up making the problem much harder than it needs to be.
This morning I noodled on this while I was at the gym and from my preliminary experiments, it looks like it is going to work. No promises or commitments yet but this path is the most promising I’ve explored since I’ve started looking at the multi-page form problem. So far I’ve been able to submit a multi-page form however only the first page of the form is styled correctly and the confirmation page isn’t working properly either. I think both are solvable.
I am posting this because this question comes up a few times a week and I am sure the lack of progress I’ve demonstrated may result in lack of confidence for the plugin.
Assuming I get this flushed out in the next day or two, I’d like a couple volunteers to test the plugin before I release and update through the WordPress plugin repository. Please let me know if you’d be interested in testing an early build.
The answer is: I don’t know yet. WordPress 3.3 came out last night and I am just playing with it now. One of the key features of WordPress 3.3 is the inclusion of the complete JQuery UI library. This definitely affects wpGForm because I am loading one of the UI libraries that wasn’t previously included from Microsoft’s CDN. That will no longer be necessary (yeah!). I guess the question now is what to do about backward compatibility with older versions of WordPress.
Historically I’ve just put a stake in the ground and moved on but wpGForm is the first WordPress theme or plugin that I’ve done that has quite a few users so I’ll probably implement some sort of version detection and conditionally load the UI library from the CDN if running an older version of WordPress. A little more work for me but probably the right answer.
This morning I added a new feature to my WordPress Google Form plugin. You can now set a form to be ‘read only’ using the readonly=’on’ attribute in the shortcode. This option, when turned on, use a little snippet of jQuery to disable all of the form elements.
[gform form='<long_url_to_your_google_form>' readonly='on']
I suspect your immediate reaction to this is “why would I want my form to be read only?” and it is a logical reaction. After all, the whole point of creating a form is to collect data right? The purpose of some forms, in fact I’d bet it is the case for most forms, is to collect data for some period of time and after a certain point (e.g. 5:00 PM on October 31), there is no reason to collect data any longer.
Imagine a sign up sheet for working the snack bar at your local High School football game. Once the game has happened, there is no value in letting people sign up any more. The readonly option will allow you to retain the form as part of your WordPress web site while preventing the collection of any more data.
I need to do little more testing before I release an update but so far, it looks pretty good!
Note: The more I think about this, I may want add an expire option after which the form will automatically become read only.
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.
* 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.
global $post ;
if (get_post_type($post) == 'CPT')
/** Hook into the Admin Footer */
This morning I fixed a bug which occurred when the default CSS was not enabled (which it isn’t by default). When the default CSS was not enabled, the jQuery Validation plugin wasn’t loading and then the jQuery script that initialized the validation would fail.
If you downloaded the beta prior to 10:00 EDT on 10/7, you should download it again and re-install.
WordPress 3.0 introduced a concept called Contextual Help. Contextual Help provides a mechanism for plugins to hook into the standard WordPress Help system. This is pretty cool because it provides a way to provide Help that is consistent with the WordPress Dashboard.
I’ve had something I’ve called Guidance on almost every page and tab through the plugin and while helpful, it tends to clutter up the interface. I had a question from our swimteam’s volunteer coordinator about adding more help to the page and I was worried about adding even more clutter. I tried a couple experiments with a jQuery Dialog solution but I wasn’t happy with the results. It was then that I wondered if I could make use of the existing Help button in the Dashboard as it is always there on the Dashboard.
After a bit of reading and some experiments I was able to have custom content displayed within the Swim Team Dashboard pages. However, trying to have different content for each tab was a little more of a challenge. I ended up solving this problem using a simple jQuery script to swap the default content with some tab specific HTML. Awesome! Elegant Help solution achieved!
I am now in the process of retrofitting this new model for every page and every tab which will take a little while. I expect I will have a build available in a few days but in the mean time, here are a couple screen shots to get an idea of what this new Help model will look like.
Events for each swim meet is now working. Even re-ordering also works. I still need to implement Importing Standard Events but I am pretty sure this will be pretty straight forward. Hope to have it completed this weekend. Once done, I will start working on importing meet results.
Now that I have the standard events working with drag and drop reordering, I need to propagate events to each meet. My thinking has been that a meet will start by importing the standard events and then add, delete, edit, and reorder as necessary to support a specific swim meet.
While I have had this model in my head, my first look at actually implementing it raised a bunch of questions – where I do put it? How does it work? The event management isn’t as simple as other meet management tasks so it sort of breaks in the way that I implemented the meet data. I have an idea how to solve it but it will take some experimenting to see if it will work.
It has taken me a little longer (ok, a lot longer) than I had expected but I have drag and drop event ordering working for the default events. Now that it is working, I need to clean it up and style it. The jQuery Table DnD plugin I found works great – it does exactly what I need it to do.