This afternoon I posted the third beta release of Email Users v4.5.3. There is a pretty significant change in this build so I may bump to v4.6 when I release it.
Yesterday I posted an article about an odd Email Users problem I was looking at. This build fixes (correctly) the problem encountered by that user by properly using get_users() instead of a complex SQL query to retrieve the information used to construct the User Settings page.
In addition to being properly constructed, the User Settings page has a number of fixes including proper sorting and the addition of Search (which I could never get working using the old query).
A second beta release of Email Users v4.5.3 is now available. This beta addresses a problem reported on the WordPress Support Forum where the Dashboard widget was shown to all users as opposed to only users who have some level of Email Users capability.
This evening I released v0.56 of WordPress Google Form. I have not had any bug reports in about a week and my own usage has looked pretty solid so it was time to push it out.
This release fixes some issues dealing with UTF-8 characters which are common when using non-English versions of Google Forms. It also adds a significant new feature in HTML5 Placeholders. Placeholders are useful for providing your users with hints on what should entered into various fields without setting default values which could then be submitted. A placeholder has the appearance of a value without actually having something that can be POSTed to the form processor.
Placeholders are an advanced topic in that usage requires knowing the name of the input element. I have based Placeholders on the same basic usage model as the Advanced Validation functionality I introduced a few releases back. Locating the name of the input element isn’t difficult but does requiere examining the HTML source. I wrote up a post on Advanced Validation a few weeks ago and there is a good description of how to identify the name of the input element.
I have released beta-4 of WordPress Google Forms. This beta update addresses a problem reported where the settings for the form weren’t being saved correctly (e.g. turning Title on would not appear to be saved).
It turns out that the settings were saved correctly so the form would work as desired however subsequent edits to the form would return all of the settings to the default state which would then be saved unless the author noted they were wrong and set them correctly again.
The logic to pre-populating the current state of the form’s settings was faulty. This beta update fixes this bug.
My solution to this request was to implement the placeholder attribute for the input tag. This is also much easier than expecting users to decipher the complex URL requirements to pass default values to a form. The difference between a placeholder and a default value is the placeholder value cannot be submitted. In the case of wanting to have something like “email address”, which isn’t a valid email address, in the form field as a “placeholder”, using the placeholder attribute is a better solution. At least I think so.
Placeholder values are defined when the form is added as a Custom Post Type.
Like the custom validation rules, to use placeholders you will need to know the name attribute for the field you are defining a placeholder for. Refer to this post I wrote on Advanced Validation to learn how to identify the field name.
I have not had any additional issues reported against the v4.5.0-beta-2 release of Email-Users so I have released it to the WordPress plugin repository. The update should appear on your Dashboard soon! Thanks to everyone who provided feedback on the beta releases.
I have posted the initial beta version of WordPress Google Form v0.56. This preliminary release has bug fixes to handle UTF-8 characters in from values and also handles the unusual case where a tab character is embedded in the form response value.
The embedded tab issue was particularly tricky to track down as it is (a) it wasn’t obvious since web browsers render tabs as white space and (b) it isn’t easy to actually enter a tab into an HTML form (which is how Google Forms are created). I was able to embed a tab in a form response by pasting some text from Word. It turns out the user that had the problem I was trying to resolve had done the exact same thing.
Handling the tabs turned out to be tricky so initially I thought I thought I might have to simply detect them and display a warning but in the end I was able to find a viable solution.
This beta release also has the first implementation of Transients for the initial rendering of a form. This use case is likely not all that common but came from a user who had four (4) forms on a single page and was seeing timeouts from Google. Caching the initial rendering of the form will help in this situation. Thanks to Camilo Flores for providing a patch which I based the implementation on.