wp-SwimTeam v1.38.983 released

This afternoon I posted an update to wp-SwimTeam.  This update addresses a number of bugs that have been reported recently.

  • Fixed bug in Hy-tek entries generation which caused a PHP warning but no loss of data.
  • Fixed bug which caused parents/guardians to see all swimmers instead of just their swimmers when opting in or out of a swim meet.
  • Added checking and a warning message when the selected meet occurs outside of the active season. Some operations makes sense, however some do not (e.g. opt-in or opt-out).

You can find the update in the WordPress Plugin Repository or as an update via your Dashboard.  You can also download it here.

Google Forms Beta (1483 downloads)

WordPress Google Form v0.46 beta 11 available

Things are finally settling down and I am able to spend some time on my WordPress plugins.  I updated Email-Users this week and am now focusing on WordPress Google Form.

Shortly before I went out on vacation I learned from one of the people who has been testing beta releases that the CAPTCHA functionality was no longer working.  I took a quick look at it and sure enough, somewhere between Beta 5 and Beta 10 I broke something and the CAPTCHA was not working but oddly enough, it was only broken on some browsers (e.g. Chrome) but worked on others  (e.g. Firefox).  These sort of bugs are a pain to chase down and with work being very busy and my family and I getting ready to go on a week long trip to Ireland, I decided to wait until I came back to figure out what was wrong.

It turns out I had introduced a very subtle syntax error in the jQuery script which defines which form fields are validated.  I am still surprised it works in Firefox but not in Chrome.  Regardless, it is fixed in Beta 11.

This bug affected me quite a bit as I have the beta version running on my site for Help and Support Requests and I had a slew of spam responses while I was out on vacation.  Hopefully in my clean up I didn’t delete any real requests!

There are a lot of new features in v0.46, please refer to this post from about a month ago which shows how to request an email address from a user as part of the submission.  This post explains how the new Google Form Custom Post Type (CPT) works.

Google Forms Beta (1483 downloads)

Emai-Users v4.4.3-beta 1 now available

I have posted a beta release of Email-Users v4.4.3 for testing purposes. This build addresses a problem with using the new Meta Filter functionality with a set of users and also fixes a situation which can result in duplicate emails when Notifications (Page or Post) are sent by selecting both Roles and Users.

Email Users Beta (1042 downloads)

WordPress Google Form v0.46 beta 10 now available

A user recently reported a very odd issue where their server would report a 505 error when visiting the WordPress Google Form Plugin Settings Page.  Having never seen this sort of behavior, I was somewhat stumped.

The user had a test server I was allowed to access and I was able to narrow the problem down to a call to preg_match_all(), a standard PHP function.

The plugin settings page scrapes some content from the WordPress plugin repository and puts it on a tab within the Plugin Settings Page.  The call to preg_match_all() involved a fairly complex regular expression to extract just the content I wanted.

It turns out there is an undocumented WordPress Plugin API which makes extracting this same date extremely simple.  This beta release incorporates the API and eliminates the call to preg_match_all().  The solution is much cleaner, wish I would have known about this sooner!

Download the beta release and please let me know if you run into any issues.

Google Forms Beta (1483 downloads)

Email-Users 4.4.2 released

Yesterday I released an update to Email-Users which addressed a problem when using the Email to Groups function.  Too many users were incorrectly being selected as part of the group due to an initialization bug which has been fixed.

You can find the update in the WordPress Plugin Repository or via an update on your WordPress Dashboard.

Email-Users v4.4.1-beta-4 now available

This evening I updated the beta version of Email Users 4.4.1 to beta-4.  This version addresses the issue with user settings reverting which was reported here, here, and here.  I have implemented the solution proposed by @maximinime on the WordPress Support Forums.

Email Users Custom List (1582 downloads)

Please download and test the beta release.  Report back any issues and I’ll do what I can to fix them quickly.

Email Users Beta (1042 downloads)

Odd behavior with PHP’s method_exists() function

I recently had a report from a user that many of the pages within the wp-SwimTeam plugin were blank.  This is odd and incorrect behavior but I have seen it before.  When I last chased it down I found that the way various versions of PHP 5.2.x and 5.3.x handled Constructors was different and in some versions Constructors in parent classes would be called and in some versions they wouldn’t.

I assumed this new report of blank pages meant that I had missed one of these Constructor issues somewhere.  It turns out that wasn’t the case.  This time I found that PHP’s method_exists() function behaves differently between different versions of PHP on different platforms.

The report came in from a site running PHP 5.3.13 which is the same as what I am running in my development area.  The only difference I can see between the two servers is mine is running on Windows under IIS where as the problematic site is running Apache under Linux.

When a page is rendered for wp-SwimTeam, the objects on the page are traversed and HTML code is generated.  The objects which comprise the page content can either be strings (HTML code) or objects themselves which then traversed recursively until all of the leaf HTML is assembled.  This is core functionality in phpHtmlLib that I have been using for years without any issues until now.

What I found was that if the variable passed to method_exists() was a string instead of an object, PHP goes out in the weeds and never returns which ultimately results in the blank page.  This is the code that has been rendering objects in phpHtmlLib for 10+ years:

if (method_exists($item, "render") ) {

It was fairly simple to fix it.  By checking to see if the item is an object prior to checking for it’s render method, the problem is resolves and the page renders correctly.

if (is_object($item) && method_exists($item, "render") ) {

I will be updating phpHtmlLib with this fix shortly.

WordPress Google Form Update

I have spent some time comparing low level WP_Http results against wget results and have come to the conclusion that Google Cookies aren’t being passed through the series of redirect which happens when viewing a Google Form with the new URL scheme.

Unfortunately I am not sure what to do about it yet.  The usually very helpful WordPress Hackers mailing list is surprising quiet right now.  I am trying to figure out if I can “remember” cookies and pass them along each time a redirect happens.  I am reasonably confident that is what is needed however making it happen within the WordPress context is another story!

Google change to breaks WordPress Google Form

Last week Google introduced a significant update to Google Forms.  In addition to a very different UI, the format of the public URL has changed AND more importantly, it has broken my WordPress Google Form plugin.

The change only seems to affect forms created from scratch using the new version of Google Forms.  My plugin is dependent on the WordPress HTTP API to retrieve the form from Google and with the new URL format, the API is returning an error.  I am trying to figure out what Google doesn’t like.

What is odd is I am able to successfully retrieve the form using the wget utility (a Unix command line tool for retrieving remote content) however wp_remote_get() doesn’t work.

I wish had some better news to report but right now I am stumped as to why this isn’t working.

If anyone has any ideas, I have posted some of the low level debug stuff on PastBin.