Mike Walsh's random thoughts and musings …
Posts tagged Progress
WordPress Google Form minor update – v0.21
35 days
This morning I have updated WordPress Google Form and fixed a number of documentation problems and added one minor new feature. While I am not a big fan of Javascript Alerts, I had a request to allow a message to be displayed upon successful form submission. I have added a new parameter (alert=’message’) to the gform short code to enable this new functionality.
[gform form='https://docs.google.com/spreadsheet/viewform?hl=en_US&formkey=dEYwbGNYVG9TRUhXellMaDBuZ1RQTHc6MQ#gid=0' confirm='http://localhost/?page_id=435' alert='You da man!']
The new release should appear in the WordPress repository immediately and as Dashboard update fairly soon.
wpGForm Bugs in v0.15
111 days
I have been alerted to a couple of bugs in the current (v0.15) version of wpGForm that I am working on fixing.
- Select boxes do not retain their value when going back on multi-page forms. I’ve already fixed this problem in my development build.
- Check boxes are not passing their values correctly.
- Sometimes Radio buttons do not retain their values when going back on multi-page forms.
This third item is proving difficult to track down. It is odd that some questions with radio buttons work fine going back and forth between pages but others do not. If I can fix the check boxes this morning I will likely release an update that addresses the first two bugs and keep working on the third problem.
WordPress Google Form v0.12 is out
026 days
Yesterday I committed and tagged the v0.12 release of my WordPress Google Form plugin. It is available from the WordPress plugin repository. The main feature of this release is support for multi-page Google Forms. The changes made to support multi-page forms should also enable use of fields that have optional answers.
There is still some leftover code from the old validation process that I was reluctant to completely remove until I know for sure this new architecture is working in more use cases than I have to test with. There will likely be another update that is nothing more than a code clean up in a couple weeks unless someone reports a problem.
wpGForm v0.11 beta update
931 days
This morning I posted an updated wpGForm v0.11 beta release. This updated beta introduces two new shortcode attributes:
- title=’on|off’ – Show (default) or remove the Google Form title. The title is often redundant with the WordPress post or page title, this attribute will allow you to remove the title from the HTML displayed within the WordPress context.
- maph1h2=’on|off’ – Map H1 elements (usually just the title) on the Google Form to H2 elements. This allows you to retain the form title from the Google Form but map it’s H1 tags to H2 tags which prevents multiple H1 tags from appearing on the WordPress page (which I understand is an SEO no-no).
This build also includes default CSS definitions for div.ss-q-help classes. Why the help text appears adjacent to the question as opposed to on top of it is a question comes up pretty frequently. This CSS makes the output more consistent with how Google presents the form so I’ve decided it should be the default.
label.ss-q-help {
display: block;
}
I’ve also started removing debug and obsolete code.
Mutli-Page GForm Update
033 days
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.
Multipage Google Forms – no solution yet
071 days
Yesterday I had some time to look at supporting multipage Google Forms. Unfortunately it doesn’t look like it will be possible because of the way multipage forms work. As you work through a multipage form Google adds hidden values to each successive page to facilitate moving forward and back without losing any data. Pretty standard stuff for a “wizard-like” form implementation.
The problem is the way the plugin is implemented, the HTML code for the form is extracted and then re-processed before being added to a page within WordPress. What I’ve implemented works fine for a single page form, actually, in my opinion, it works pretty well. However, detecting the page transitions and obtaining the hidden form fields either isn’t easy or isn’t possible. Right now I am leaning toward the later because the hidden fields are generated based on the prior page (Continue or Back) form submission.
What I have successfully made work is to use the “embedded” version of a Google form within a WordPress page. It works but aesthetically it looks awful. What I am playing with right now is some jQuery to try and manipulate the embedded form to use the styling from the site instead of from Google. We’ll see how it goes ….
TwentyEleven Child Theme Learnings
088 days
For the past week or so I’ve been playing around with a TwentyEleven child theme for a soccer team project I am fiddling with. For the most part I’ve been able to accomplish what I want using a TwentyEleven child theme. Using TwentyEleven as a base for this project isn’t bad but it certainly is different than using a theme framework (e.g. Thematic).
Last week I had posted that I didn’t care much for how the header was constructed and after working with it for a week, I still feel that way. TwentyEleven has a number of filters and actions but customizing the header isn’t among them. I also find it very odd how the default behavior is to use featured images as the header if there is one available. I can’t imagine what application that turns out to be a good thing. Fortunately it is fairly easy to disable that and set your own header.
TwentyEleven has a showcase template that is sort of like a magazine style but not exactly. For it to work it requires that posts be tagged as “sticky” which also means they appear at the top of the list in a standard chronological post view. What I really wanted was functionality like the showcase for the latest articles and let that view become the default home page. I was able to accomplish this by copying the showcase.php file from TwentyEleven into my child theme directory and calling it latest-news.php. I now have a new template that shows the five latest posts using the featured content slider which TwentyEleven has built into the showcase template.
Now that I have it working, I am finding that images in the showcase template are wonky and adding a featured image really messes things up. I am sure I’ll figure it out but the decisions the theme designer(s) made in this area are odd. It’s like having an 80% solution but the other 20% will take a while to work out.
The one thing I am pretty happy with though is how well it seems to work on my iPad and I didn’t have to do anything special to make it work. It just works which is nice. Once I am done with this I will probably turn it into a generic soccer theme but for now it is really only useful for CASL teams.
GForm validation bug PoC
0131 days
This afternoon I spent some playing with a jQuery Form Validation plugin to determine if it will help me resolve the issue with required fields. The initial results look fairly promising as I was able to tag a couple fields on a test form and they were flagged when I submitted it.
In the image above, the jQuery Validation plugin added the “Thus field is required” when I submitted the form with those fields empty. This is exactly the behavior I want, the challenge now is to scale my Proof of Concept (PoC) to work in the generic case of the plugin. The Google form defines a block for each input field and the class the denotes a field as required is assigned to one of the DIV blocks that wraps the label and form element (e.g. INPUT or TEXTAREA tag) as opposed to the form element tag itself. This makes finding the required elements a little tricky.
The real challenge I think will be input groups (e.g. radio buttons and check boxes). I need to do some jQuery research before I have a solution but assuming I can figure out which elements to select, I believe this will solve the problem with required fields.
wpGForm v0.5 fixes Settings page bug
0149 days
I have just committed v0.5 of the WordPress Google Form plugin. It addresses the problem with the Tabs on the Settings page not working correctly. It turns out that I had a couple of problems which were masked by the theme I was using. I have moved my development environment back to the stock Twenty-Eleven theme and turned off all other plugins.
By doing this I determined that the jQuery UI libraries I expected to be loaded, were in fact, not loaded at all. They were being loaded by the theme! Once I got the libraries loaded correctly the Tabs started working but they didn’t have the proper styling. WordPress doesn’t appear to include the jQuery UI CSS so I ended up loading it from Google’s CDN.
Everything seems to be working correctly now, v0.5 should appear as an update shortly if it hasn’t already.
WordPress Google Form Settings Bug
0149 days
The WordPress Google Forms settings page makes use of tabs to show information about the plugin and set its options. It appears that the theme I was using, which I am in the process developing, is the culprit. It loads some new jQuery functionality from Google’s API that apparently allowed the tabs to work as I expected. I am not sure yet why the builtin WordPress jQuery functionality isn’t working correctly as I expect it should.
Now that I know where the problem is, I think it should be pretty straight forward to fix it.
Recent Comments