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.
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 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!
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.
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.
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).
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.
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.
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.
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!
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.
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.
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.
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.
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.