The Magic of the get_users() Function

While working on Email Users recently I encountered a performance problem with some SQL which I had received via the WordPress Hackers Mailing List back in January of 2008.  At the time I needed it for my wp-SwimTeam plugin (where I am still using it) and it served me well.  When I first committed a patch for Email Users (v3.4.0) I used this SQL to allow sorting of the users as prior to v3.4.0, only the usernames were displayed.

It turns out this SQL is pretty inefficient (I am by no means an SQL expert) and it was causing performance problems for people using Email Users with a large number of users.  Again I turned to the WP Hackers Mailing List and received some significantly improved SQL.

The ensuing discussion also recommended migrating my SQL to the WordPress API get_users() function.  I am all for using the API when I can as it is much safer and typically much easier to work with.  In this case, I couldn’t understand how it would help me retrieve the first and last names from the Meta table that I needed.  It wasn’t mentioned anywhere in the Codex so I was confused.

A subsequent post in the thread mentioned the “magic” of get_users() which I then tried and sure enough, the data I wanted was available.  Ok, now I am really confused.  Where does this magic data come from.  Fortunately another post referenced this article which explains how these magic methods work and why the data is available.  This is pretty neat and very useful although I have no idea how developers would know this exists based on the documentation in the Codex.

These “magic methods” strike me as one of those “inside baseball” things that not being a full time WordPress developer I’d never know about.  It is very useful and something I’ll certainly remember and use in the future.  Thanks to the WordPress Hackers Mailing List – an incredibly valuable resource.

I am now contributing to the E-Mail Users plugin

I am happy to say that I have been granted Subversion commit access to the popular Email Users plugin.  I have been using this plugin for a number of years and have submitted several patches which were included in the 3.4.x releases.  Recently I needed to add some functionality to support the MacDolphins web site and use of the plugin and after submitting a patch, I was invited to be a contributor by Vincent Prat at Marvin Labs which I gladly accepted.

The 4.0.0 release of Email Users is a pretty substantial change.  It updates the plugin to use the WordPress Options API and updated menu API.  It also adds a new feature that allows easy access to managing the email options for one or more users.  No more visiting the User Profile for each user, bulk actions are now available!

More to come over the next few days.

WordPress Google Form v0.30 now available

Similar to yesterday’s update, today I pushed out wpGForm v0.30.  This version  addresses an unusual problem which prevents the custom confirmation CSS from loading properly.

In some cases, it appears that a plugin or theme, through the use of a filter (likely the_content or wpautop), was inserting paragraph tags into the content which by itself isn’t a problem, however when enabled, wpGForm adds a custom CSS block to style the form during processing, so the CSS definition portion of the content ended up with paragraph tags in it.  This results in CSS which won’t parse correctly and of course it never styles the form.  I have updated the plugin to generate the CSS definition as a single line of text where it previously spanned several lines for readability purposes.

The update should appear on your Dashboard shortly and is also available from the WordPress Plugin Repository.

WordPress Google Form v0.29 now available

Today I pushed out wpGForm v0.29.  This version adds one new feature and addresses an unusual problem which prevents the custom confirmation page, either AJAX or redirection, from loading properly.

In some cases, it appears that a plugin or theme, through the use of a filter (likely the_content or wpautop), was inserting paragraph tags into the content which by itself isn’t a problem, however wpGForm adds a jQuery script to the content during processing, so the jQuery script portion of the content ended up with paragraph tags in it.  This results in Javascript which won’t parse correctly and of course it never runs.  I have updated the plugin to generate the jQuery script as a single line of text where it previously spanned several lines for readability purposes.

Based on several requests, I have added a new short code attribute, sendto=<email address>, which when used in conjunction with email=’on’, will send a form submission note to the specified email address instead of the blog administrator (who is still bcc’d for backup purposes).

The update should appear on your Dashboard shortly and is also available from the WordPress Plugin Repository.

wp-SwimTeam v1.26.871 released tonight

I released a second build today, v1.26.871 was pushed out late tonight.  I don’t like to do this as constantly having the Update notice on your Dashboard can be a bit of a nuisance.  We’re gearing up for Swim Team, he have our season opening party in one week so I’ve am trying to get ready and have been working on the plugin a lot over the past few days.

This build addresses a few minor nits but the primary new feature is the ability to display the meet time as part of the wpst_meet_schedule short code.

  1. I’ve added a new option to Miscellaneous tab to control how time is formatted. Usage of the format is not yet pervasive through the plugin.
  2. Enhanced wpst_meet_schedule shortcode with two new attributes: fmt=’time format’ and ‘showtime=yes|no’. Default is not to show the time and use the time setting from the Miscellaneous tab. The fmt attribute expects a string formatted following the conventions outlined in the PHP date function.
  3. Removed redundant code from Swim Meet module.

The build has been pushed to the WordPress plugin repository and also appears on my Download & Installation page.

wp-SwimTeam v1.21.790 released

This morning I released v1.20.790 of wp-SwimTeam.  This release addresses a bug which only appears on some hosting configurations where the URL http://www.example.com and http://example.com don’t resolve to the same place.   It isn’t clear to me why the server variables sometimes truncate the prefix but in some cases it happens and in some cases it makes a big difference.

Thanks to a couple teams for letting me access their site and chase this problem down as it doesn’t happen on my own sites.  This version makes use of the WordPress API (which I probably should have done that in the first place) to construct URLs for the tabs instead of parsing the PHP server variables. I’ve done a fair amount of testing on four different sites over the past 24 hours so I feel pretty good about the new implementation.

I have also incorporated this URL fix into the construction of the links on the Tabs for the Swim Team, Manage, Reports, and Options pages.  While I wasn’t having a problem here, the new solution is the “correct” way to construct the URL and should be more robust in different WordPress configurations.  WordPress has already figured out the various server configurations, no need to reinvent the wheel!

The update has been pushed to the WordPress Plugin Repository so you should see an Upgrade notification on the Dashboard soon if it isn’t already there.  This build is also available from the Download and Installation page.

wpGForm v0.28 released

This morning I released an update to my WordPress Google Form plugin.  I can only assume very few people are using the email confirmation feature because it wasn’t working and I didn’t hear about it until this past weekend!  The email confirmation feature (add the attribute email=’on’ to your short code) will notify the WordPress administrator that a form submission has been made.

The update is now committed and should appear on your WordPress Dashboard shortly.

wpGForm now has email notification

I’ve received a couple of requests to have an email notification sent out when a form is submitted. Today I released v0.26 which supports a new attribute (email=’on|off’) on the gform shortcode. By default email notification is off but when set to on, an email to the blog administrator will receive an e-mail indicating a form was submitted. The email also contains the URL for the form, and date and time the form was submitted.

While I was working on this version, I also decided to see if I could make the custom confirmation work like my original implementation which did not use a Javascript redirect.  I had switched to the redirect when I added support for multi-page forms because the mechanism I was using previously no longer worked.

Email can be sent in either HTML or Plain Text formats, there is a new option on the settings page.  By default email notifications are sent in HTML format.

The v0.26 version switches from a Javascript redirect to an Ajax page load using jQuery.  In my testing it seems to work pretty well and is much less intrusive than the redirect was.  Let me know if you run into any problems with it.

The v0.26 release is now available from the WordPress plugin repository and an update will appear on your WordPress Dashboard.

phpHtmlLib v2.6.3.3563 released

This evening I released a new version of the phpHtmlLib plugin which wp-SwimTeam depends on.  This update addresses a number of PHP5 deprecated function warnings which are commonly seen when running under PHP5 with E_STRICT set.  I also fixed an icon bug which appeared on the GUI widget used across wp-SwimTeam when there was no data to display.

The update also removes the documentation and examples from the version of the plugin hosted in the WordPress plugin repository since they are only useful for developers.  A full version of the plugin including documentation and examples can be downloaded from the Download & Installation page.

Possible Enhancements for wpGForm

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.

Thoughts?