Based on a question in the Support Forum I have added a new feature to suppress breaking a form into multiple columns when the browser is narrower than a specified width (e.g. on a phone). This should allow forms which are set up for columns to be presented better on phones and tablets.
If you’d like to try out this feature, download this beta release and provide feedback on any issues. By default, the plugin will handle columns exactly as it always has.
Google Forms Beta (157 downloads)
This evening I posted beta-1 of Email Users v4.7.0. This build addresses, or at least recognizes, an issue recently reported in the WordPress Support forum where email was not being sent when a large number of users were being selected.
The crux of this problem is the PHP max_input_vars configuration setting which by default, is set to 1000.
Every user selected on the form plus the other form fields are submitted as “input vars”. If ~990 or more users were selected, the input vars would be exhausted and the form submit would be missing required fields. The result was no email sent and the form being redisplayed for the user.
While I can’t change the setting of PHP’s max_input_vars setting, I can detect when the scenario, I can detect when it might be a problem and warn the user.
The warning shown above will now be displayed whenever the number of users which could be selected approaches or exceeds the current setting of max_input_vars.
Hopefully this will alleviate the confusion around this issue. Please report back on any bugs or odd behavior.
Email Users Beta (71 downloads)
This evening I released a minor update to Email Users. This update, v4.5.1 addresses two feature requests (Post Author Keyword Replacement and Post Excerpt Filtering, removes some debug code, and adds Italian language support.
You can find the update in the WordPress Plugin Repository or on your Dashboard as an update.
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.