This evening I posted a new beta release (#4) of WordPress Google Form v0.54. This beta release addresses a problem where values with escape characters and/or other encoded characters end up in the response spreadsheet.
As you can see in the image above, the values are escaped until the final entry. This fix needs some testing to make sure it doesn’t break anything, please try it out and let me know how you make out.
Google Forms Beta (8510 downloads )I am doing some experiments with the TwentyTen theme and Git. Up until very recently I have never used Git, I’ve done all of my version control with Subversion. With Git gaining in popularity, I see more and more WordPress projects using it. I figured I ought to educate myself.
I recently picked up the O’Reilly Version Control with Git book. On a recent trip to Phoenix and back I read through a fair amount of it. I have found that nothing forces you to learn how to do or use something like having a real problem to solve. You can take training classes, read books, attend lectures, etc. but you’ll never really learn until you have to actually have to apply the material to solve a real problem.
It was like that for me with Git. While I’ve used Subversion for quite a while, I was having a tough time getting my arms around the concepts of forks, pushes, pulls, etc. For all practical purposes, I still am but I am getting there.
I like the idea of child themes. I have no desire to completely reinvent the wheel. The guys who put out WordPress are smart and clever and have done some nice themes that work well. In particular, I like TwentyTen as a parent theme and have done a couple child themes from it. I find myself using some of the same ideas and plugins across these theme projects so what I’d really like is a core child theme that I can adapt or build from that contains all of the things I like and have figured out already.
So while reading up on Git I envisioned being able to use it to build a base theme that I could adapt to several others very quickly. If I made a change it would propagate out to the other themes that are based on the base theme. At least that is the theory. I am still not sure if it will work like that or not but I’ve decided to try.
For the past day or so I’ve assembled a TwentyTen child theme I am calling TwentyTen-ACME. Why ACME? Because it is a pretty generic name. ACME was the company that provided everything to Wile E. Coyote in the Road Runner cartoons. ACME is the definition of generic!
So now that I have my base theme pretty much done, I am going to build a derivative from it for a project I am doing for our middle school. Shortly there after I am going update my LEGO theme which is based on Sandbox and is long overdue for an update. I am hoping that as I need to push changes back to the base theme I will be able to flow them back out to the others quickly. We’ll see.
I have just posted wp-SwimTeam v1.40-beta-2. This update fixes the problem where adding age groups generates an error. The error only happened when using swimmer numbers that didn’t include a prefix (e.g. Simple Numeric sequence or USA Swimming format).
wp-SwimTeam Beta (2401 downloads )I have uploaded a preliminary build of wp-SwimTeam v1.40-beta-1. This build introduces new functionality to support mixed gender and combined age groups. It also fixes a number of small bugs I encountered along the way.
I have not done thorough testing on it as I don’t have access to MM and TM right now to validate the changes. However, I am reasonably confident that the changes I’ve made will have little to no impact on Hy-tek compatibility.
If you run into any issues, let me know and I’ll get them fixed as quickly as I can.
wp-SwimTeam Beta (2401 downloads )I am working on some new functionality to support mixed gender events. While I am at it I have decided to fix a limitation with the current Age Groups where the need to define overlapping age groups works but causes some discrepancies on the roster and other reports.
I have enhanced the definition of an Age Group so it can either be “Standard” (which is what it has always been) or “Combined”. A combined age group can support mixed genders and/or age ranges that span multiple age groups. By differentiating two types of age groups it cleans up the issues with overlapping age groups too.
Here are a couple of screen shots of what the changes look like. I am running through some testing now to make sure everything still works.
It turns out adding support for mixed-gender events isn’t as simple as I thought it might be. Because so much of wp-SwimTeam revolves around age groups, I haven’t made it very easy on myself to add this enhancement.
Events are tied to age groups so in order to add a mixed gender event, I need a mixed gender age group to associate it with. A mixed-gender age group doesn’t really make any sense although it is similar to another feature which isn’t easy to support – age groups which are supersets of other age groups.
I have learned that some leagues have “special” events which are open to swimmers from multiple age groups. For example: The league my niece and nephew swim in has open freestyle events at the end of the meet. There are two age groups (10 and under, 11-18) for each gender. The wp-SwimTeam definition of an age group doesn’t work well for these groups either although it isn’t as problematic as a mixed gender event it.
After noodling around with a few ideas I think I have come to the conclusion that I need some sort of Age Group classification to allow defining a group which spans ages and/or genders. I am struggling with nomenclature for these groups but I believe the fundamental idea is sound.
For now I am referring to these special age groups as a “Combined” age group. They will not be counted in swimmer population numbers but will be used for Events and Entries.
A quick bump to beta-3 for WordPress Google Form v0.54 to fix a problem which resulted in a PHP error message due to missing post meta data for field validation. Forgot to account for the situation where a form hasn’t defined any fields to validate!
Google Forms Beta (8510 downloads )I have just uploaded beta 2 of WordPress Google Form v0.54. This update fixes the problem with the validation meta box not allowing adding additional fields (a jQuery script was not loading correctly) and also fixes the issue with range checks I mentioned in the beta 1 announcement. At this point I believe everything is working correctly.
I have put together a Validation Demo Form that you can play with to see how it works. There are some images below from the demo form running in my development area including how I set up the validation information when creating the form.
Google Forms Beta (8510 downloads )
The first beta release of WordPress Google Form v0.54 is now available for download. This beta release introduces a pretty significant enhancement – Advanced Validation for any field on a Google Form. This is an “advanced” feature as it requires the user to dig into the form in order to gather the necessary information for the validation to work correctly.
There are a few things which I know aren’t working (e.g. Range Checks) which I will look into. I would really appreciate some feedback on this new functionality.
Google Forms Beta (8510 downloads )One of the most common requests I receive is the desire to validate fields on a Google Form. Google provides some basic validation (required or not) but there really isn’t a way to ensure that if you request an email address that the user actually provides a valid one. Similarly, there is a need for URLs, numbers, and other specific fields.
I’ve been using the jQuery Validate plugin (which looks to have a new home) for a while now to validate required fields and in some cases, email addresses, and most recently, CAPTCHA support.
A number of people have asked me about extending the validation to include any field. I have been reluctant to do this for several reasons:
For these reasons I’ve kept this on the back burner for a while. However, a couple recent requests got me thinking about it again and it would be useful for a project I am doing for my daughter’s soccer team. So I decided to dig into it.
I don’t think it is possible to make it completely foolproof however I did want to make it as simple as possible. I decided to add a new Meta Box to the Custom Post Type editing screen which “helps” the user define new rules.
The key to making rules which accomplish something is getting the name attribute for the form entry element that needs to be validated. There really isn’t a good way to do this other than to look at the HTML source. I like FireBug with Firefox but both Chrome and IE have the ability to easily inspect an element.
Now that I know my input element’s name (entry.409811816) I can set up my new rule.
If you have been using WordPress Google Form the first thing you’ll notice is the Form Editing screen has changed quite a bit. The form was getting very long and cluttered so I have moved some of the lesser used options to a new Meta Box on the right hand side leaving just the critical or frequently used options on the primary Meta Box.
There is a new Meta Box just for Validation. This Meta Box lets you add a series of fields where you can enter the name, the type of check to perform, and if needed, a check value.
Once the validation fields are set up, you can see the effect as you fill out a form.
I am going to clean up a few things and make a beta release available for people to test with. I think this functionality is pretty cool and it was a bit of a challenge to (a) get it working and (b) find what I think is a viable usage model. As always, feedback is welcome.