This morning I uploaded another beta (beta-3) build of Email Users v4.8.5. This build addresses an issue with the mailusers_update_custom_meta_filters action not being applied to User Email (it was only applied to Group and Notificationemail). This problem was reported in the WordPress Support Forum about a month ago.Email Users Beta (194 downloads)
Google has made another change to the new version of Google Forms and moved the option to downgrade a form to the older version. There is no longer a Running Man icon to click on to get the downgrade option. Instead, look for the large question mark in the lower right hand corner .
- Click on the Question Mark icon
- Click on the “Back to old Form” menu
This is the third time access to the downgrade option has moved. It is probably just a matter of time before Google eliminates this completely. If/when that happens it may no longer be possible to use Google Forms with WordPress.
This morning I released v0.87 of the Google Forms plugin. This update includes a new check when saving a form definition. The check scans the HTML from the form to ensure it has the proper HTML structure the plugin expects.
The new version of Google Forms is not supported by the plugin so this check ensures that a user is notified that the form isn’t of the expected format.
You can find this updated on your WordPress Dashboard or in the WordPress plugin repository.
This morning I posted the first beta release (beta-1) of Email Users 4.6.2. This release includes integration with the ItThinx Groups plugin. I also took the opportunity to refactor the code for integration so code isn’t unnecessarily loaded when a plugin isn’t installed and clean up the plugin’s ReadMe file.
If you use ItThinx Groups I would appreciate any feedback you can provide.Email Users Beta (194 downloads)
I was recently contacted about an Email Users issue on a site that is using bbPress and S2Member. The person had come to the conclusion that there was some sort of conflict between the three plugins which resulted in the Email Users -> Users Settings screen being empty and asked me to look into it.
Clearly something is amiss as in order to access the WordPress Dashboard you need to login and in order to login, there needs to be at least one user! This isn’t the sort of situation I can easily replicate. Fortunately the person with this problem provided me access to their server so we could do some debugging.
The functionality in Email Users is based on the WP_List_Table class and an example plugin which you can find in the WordPress Plugin Repository. When I first implemented it I was retrieving the list of users with a call to get_users() however I never got the sorting working correctly. After playing around with it for a while, I gave up and wrote my own query. The query I wrote yielded the results and sorting I wanted so I didn’t think much about it. Until today.
This the query that WordPress generates and sends to MySQL:
SELECT ID, display_name, user_email, user_login, m1.meta_value first_name, m2.meta_value last_name, m3.meta_value massemail, m4.meta_value notifications FROM wp_users u LEFT JOIN wp_usermeta m1 ON (m1.user_id = u.ID AND m1.meta_key = 'first_name') LEFT JOIN wp_usermeta m2 ON (m2.user_id = u.ID AND m2.meta_key = 'last_name') LEFT JOIN wp_usermeta m3 ON (m3.user_id = u.ID AND m3.meta_key = 'email_users_accept_mass_emails') LEFT JOIN wp_usermeta m4 ON (m4.user_id = u.ID AND m4.meta_key = 'email_users_accept_notifications') ORDER BY last_name ASC LIMIT 0,100
What this query does is select all of the WordPress User Ids, first names, and last names, which have the proper Email Users user meta keys. The data is returned and stored in a format which can be rendered in the List Table.
Because the table was empty, I wanted to see what the results of the query were as that would tell me where the issue might be. Because I had access to the MySQL database via phpMyAdmin, I was able to run the query directly against MySQL. When I did so, this is what I found:
This certainly was unexpected but it explained why the List Table was empty. I have never run into this sort of problem, in fact, I had never heard of either the SQL_MAX_JOIN_SIZE or the SQL_BIG_SELECTS MySQL system variables.
I was able to alter SQL_BIG_SELECTS using the following SQL:
When I did this and re-ran the query, phpMyAdmin returned the results I would have expected to see. This was good news – it appears this users problem is due to a MySQL setting. The bad news is sometimes it is hard to change these settings and it isn’t something I thought I could add to the query itself.
As a test, I modified the source for one of Email Users files so it was calling the original method I had coded based on get_users() to see if it would work and it did. This is very good news as I suspect fixing the sorting issue (or living with it) will be easier than changing the MySQL system variable settings.
My next step is to see if I can fix the sorting problem and roll out an update.
Yesterday WordPress 3.6 was released. The bundled version of jQuery was updated to 1.10 which broke the jQuery Columnizer plugin I use to split a form into columns. The result was jQuery would go into an infinite loop and eventually you would have to kill the page.
Fortunately someone had already encountered this problem and provided a patch to the jQuery plugin. I have incorporated the patch and released v0.55. If you’re running WordPress 3.6, this is a critical release. Older versions should continue to run correctly.
You can find v0.55 on your WordPress Dashboard or in the plugin repository.
I’ve been working on Email-Users this week and have added quite a bit of functionality. Before I release it I’d like to get a few people put an early version through its paces so if you have a chance to test it out, please do so.
This new version has a number of new features:
- All postboxes on the admin screens now have their own CSS ID and Class so they can be styled or easily hidden.
- Email-Users now support integration with two User “Group” plugins: User Groups and User Access Manager. When you set up groups in either of these plugins you will be able to select them as recipients from the Group Email and Post/Page Notification pages.
- Selection of Custom Filters as Group Recipients is no longer a separate action – it, along wit the Group support noted above, are all presented in the same target recipient selection list. This allows the Custom Filters to work on Post/Page Notifications as well.
- A new action has been introduced: mailusers_update_custom_meta_filters This action will allow for updating meta filters dynamically just prior to their use. This is the best way to create complex meta filters or integrate other plugins. There is a good example in the plugin README file.
- Chinese language support has been contributed.
- Integration panel added to the Plugin Settings Page.
- Updated language support files which incorporate 20+ new strings.
A few other things were cleaned up while I was tinkering with the code as well.Email Users Beta (194 downloads)
I have also updated the sample plugin file I use to test Custom Meta Filters. It has the full example of the “Public Works” example.Email Users Custom List (187 downloads)
This morning I released v0.54 of WordPress Google Form. It has been a while since I’ve had any bug reports for the current version or the beta version. Things appear pretty stable.
- Added internationalization support for jQuery Validation messages.
- New language support files.
- New jQuery Validation based custom validation option.
- Fixed problem with escaped characters ending up in Google spreadsheet.
- Moved transport control out of debug module and into core code so it can be a permanent setting for some server environments.
- Fixed PHP warning messages which happen with Logging Enabled when some of the server variables don’t exist.
- Fixed bug with Form Submission Log setting stickiness.
- Added an optional CAPTCHA message which will appear below the CAPTCHA input when set.
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 (396 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:
- The jQuery Validate plugin needs to know which fields (by name or id) it is going to validate. There isn’t an easy way to pull these out of the Google Form HTML. It could be done on a single page form but because Google supports multi-page forms, they only way to find the information we need is to visit every page of the form. This isn’t easy to do programatically.
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.
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.
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.