Category Archives: Development

07.13.15
by

wp-SwimTeam v1.45 released

Today I released wp-SwimTeam v1.45 which fixes a possible security problem I was alerted to as well as addresses a number of bugs.  The CSV roster export bug was the primary issue holding up getting this release out, I fixed the security problem last week.

It turns out I had implemented a method in both a parent class and (redundantly) in a child class as well.  The RE1, SDIF, and HY3 exports all (properly) used the method from the parent class but the CSV export was using the child class version.  It took me a while to sort it out as I was staring at the wrong code trying to determine what was wrong. It turns out, nothing was wrong, I was just looking in the wrong place.  Once I removed the redundant method declaration, everything resumed working as it should.

I think I have resolved all of the multi-site issues, please let me know if you run into any more.

This update is available via the WordPress Dashboard or from the WordPress Plugin Repository.

04.09.15
by

wp-SwimTeam User bug with Multi-Site

Today I learned of a bug with wp-SwimTeam where the list of Users associated with the site doesn’t get populated when running under WordPress multi-site.  This problem does not happen on standard installations of WordPress.

I am looking into the problem but it isn’t a simple solution as the query references the explicit users table which isn’t the same under WordPress multi-site.

I thought I had a quick solution but it didn’t work so I will need to sit down for an hour or two and sort this out over the next couple of days.

03.03.15
by

Email Users v4.7.1-beta-2 available

This evening I released beta-2 of Email Users v4.7.1.  This build addresses a couple of issues and introduces a new filter which allows manipulation of portions of the generated email headers.

The Dashboard Widget can now be disabled.  It is on by default but can be turned off with a setting (Dashboard > Settings > Email Users).

There have been several requests to support wpMandrill.  It wasn’t until recently that I learned that in addition to overloading wp_mail(), Mandrill requires the recipient addresses to be in the TO header where as Email Users uses the BCC header to send email.

I didn’t want to make it simple to use the TO header instead of the BCC header as I view it as risky.  Exposing the recipients of a mass mailing is a no-no.  However, Mandrill is widely used and with several requests, I needed a safe yet viable solution.

The new mailusers_manipulate_headers allows the user to modify the headers so they’ll work with Mandrill while not making it too easy to do so.  Here is an example of how the headers could/would be modified to have the recipients in the TO header instead of the BCC header.

/**
 * wpMandrill needs the recipients in the TO header instead
 * of the BCC header which Email Users uses by default. This
 * filter will move all of the recipients from the BCC header
 * into the TO header and clean up any formatting and then nuke
 * the BCC header.
 *
 */
function mailusers_mandrill_headers($to, $headers, $bcc)
{
    // Copy the BCC headers to the TO header without the "Bcc:" prefix
    $to = preg_replace('/^Bcc:\s+/', '', $bcc) ;

    // Empty out the BCC header
    $bcc = array() ;

    return array($to, $headers, $bcc) ;
}

add_filter('mailusers_manipulate_headers', 'mailusers_mandrill_headers', 10, 3) ;

This code would be placed in the functions.php file.  More details can found in the ReadMe.txt file.  The example above is now included with the plugin, you can find it in the examples directory.

Email Users Beta (5387 downloads )
02.12.15
by

Google Forms v0.73-beta-1 now available

It has been a while since I’ve done an update to Google Forms. There weren’t any glaring bugs (that I was aware of) but there were a number of requests that I had yet to handle and one (unnecessary Javascript loading) has been on my to-do list for a long time. In this build are several changes and a couple of enhancements.

  1. Javascript is now loaded only when needed.  When a form is displayed, the relevant Javascript is loaded.  It is no longer loaded on every page like it has been historically.  The same is true for CSS.
  2. While fixing #1, I found that I was also loading Javascript on the Dashboard on every page as well as opposed to limiting it to when a Google Form was being edited.  There was a bug in the logic used to detect when a form was being edited which has been fixed.
  3. The plugin has long supported the ability to override the default Google text on a global basis.  This has been extended to form specific overrides.  This means the “Submit” button can be different on every form if desired.  Form specific overrides take precedence over global overrides.
  4. After submission, Google Forms show, unless hidden with CSS, a “Submit another response” link which links back to the Google Docs version of the form.  This link is now replaced with the proper link to URL where the form appears on the WordPress site.

Please do some testing with this beta version and report any problems.  I will do my best to fix them quickly as I would like to get this version released as soon as possible.

Google Forms Beta (8433 downloads )
08.06.14
by

When do you Start over?

About a month ago I posted that I had started on a Ruby on Rails project.  It was my first RoR project and I spent a couple weeks working on it, learning as I went.  One of the things I had deferred working on was User registration.  I had some done some reading and it looked like there were several viable Gems I could integrate fairly easily.

I have gotten into the habbit of taking my iPad to the gym in the morning and reading up on whatever project I am noodling on.  So I’ve done a lot of RoR reading while on the elliptical machine and came to the conclusion that AuthLogic would suit my rather simple needs.  So I kept working on the functionality I needed for the App, deferring User management for a later day.

I had to put my RoR project aside for 3-4 weeks while working on a Tcl based project for work but got back to it over the weekend.  I decided it was time to tackle the User login module.  Initially everything seemed to be ok, I could follow the examples and make things work but I kept running into little issues and I never got it to work reliably.  The lack of Rails 4 examples to use as a reference got me thinking (and concerned).  Maybe I should have picked Devise (the other Gem which seems pretty popular).

I created a simple RoR App solely to test Devise and it will very simple to setup and configure.  Great, let me fold it into the App I am working on.  Uh-oh.  Not so easy.  I am not sure if it was because Authlogic also defines a User model and there were some leftover pieces of it that were confusing Devise or it was something else in my App but after a couple hours of playing with it, I concluded what I was trying to do was a fool’s errand.

This got me thinking – was it time to start over?  Should I consider all of the work I’ve done to date a “learning experience”?  The more I thought about it the more I knew starting again was the right answer.  But I had so much other functionality already working I hated to throw it away.  Decisions, decisions.

In the end I decided to start over and being with the Devise user module.   I decided to make use of the Rails-Devise example application as a starting point as it will walk through a configuration processs where by answering questions it will generate the basis for a Rails App.  It is pretty slick.  I ran it a couple times to understand the impact of some of the choices but settled on a final configuration which has become my starting point.

I was very quickly able to add some of the functionality I had worked out previously so as painful as it was, I am pretty sure that starting over was the right answer in this situation.  Granted my problem was much smaller in scope than many projects and more importantly, it hadn’t been deployed yet so other than a release delay, my decision has not impacted the end user at all.  That isn’t always the case.

07.10.14
by

Working with Rails

Last fall I had written a post where I noted that I had a problem to solve at work which I thought might be well suited for Ruby on Rails.  Like a lot of side projects, this one never went anywhere but I did end up playing around with RoR enough to get an idea of how it works and how quickly things can be developed with it.

I do some volunteer work with our High School Booster Club and last year built them a WordPress based site which is largely used to facilitate the purchase of memberships.  While it seems like overkill, the plan is to use the web site to host more content relevant to the various athletic teams.

A couple months ago I was approached about how the Booster Club’s mobile app could be improved or replaced as the currently technology is being withdrawn and no longer supported.  I learned that the back end for the mobile app was extremely cumbersome to use and was a source of frustration for the people who maintain rosters, schedules, results, etc.

I am now working on a replacement for the Mobile App and the backend infrastructure.  Because we already have a WordPress site, I had considered using the WordPress site to host all of the data and leverage the WordPress JSON REST API plugin to serve content up to a Mobile App.  But I had some reservations.

jQueryMobileBookI’ve never done Mobile App development and in the interest of time, am not sure I want to take that on right now.  Based on my jQuery experience with WordPress, I thought a jQueryMobile web app might be a reasonable compromise.  I picked up a copy of jQuery Mobile Up and Running a while back when I had heard it referenced on a Podcast.  At the time I didn’t have an immediate application for it but it was interesting reading.  I dusted it off and realized jQuery Mobile would be a good solution for building a prototype mobile web app.

So now I have some thought in my head of a mobile web app I want to build but wasn’t sure about how to feed it.  While I could see putting all of the data in WordPress, I was worried about maintaining it.  I need something dead simple to enter rosters, teams, schedules, results, etc. into a system.  Ideally it should be accessible from a phone so scores can be quickly entered by unsophisticated users.

What I’ve decided to do is build a mobile first (maybe only) application using Ruby on Rails.  I have made all of my HTML views based on jQuery Mobile.  Within a week or so of working on it for a few hours a day, I have the basic application up and running on my Ubuntu VM.  I can set up teams, coaches, and athletes, and assign coaches and athletes to teams.  I have started on venues.  There is a ton left to do – events, schedules, user login, Google Maps, and a lot more.

While I am excited about how much progress I have made in a relatively short time frame, I am worried I am “doing it wrong” or have made a decision that will be difficult to unwind.  I’ve learned a fair amount about Rails in the past two weeks and much to my surprise, have not had to learn a whole lot of Ruby yet.

The ability to quickly add database columns and connections in RoR is pretty slick.  During my first couple of scaffold generations I was worried about getting the database “right” but having dropped some columns and added others, I’ve found it relatively painless.

While I am impressed with RoR, I am really impressed with jQuery Mobile.  It is pretty amazing how quickly a mobile web app can be assembled.  I’ve been using a regular web browser for developing my app and even using jQuery Mobile with a regular browser is pretty nice.  I had forgotten that the laptop I borrowed while my Vaio was being repaired has a touchscreen.  Using the app on Chrome with a touch screen is pretty effective at mimicking a mobile device.

I still have tons more to learn as I get ready to deploy the first build for some people to play with and populate with dummy data but I can already see other uses for Ruby on Rails.  I am still not a big fan of the Ruby syntax but I can live with it for the benefits and development efficiency I am seeing with Rails.

03.17.14
by

Email Users v4.6.6-beta-3 available

Over lunch I posted beta-3 of Email Users v4.6.6.  This build addresses an issue with User Groups integration when using a non-English version of WordPress.  A value embedded in the form was translated which the form processing logic wasn’t handling correctly.  This problem also could have manifested itself if a group name contained a hyphen (dash) character.

Email Users Beta (5387 downloads )
02.14.14
by

Google Forms v0.64-beta-6 available

I have just released beta-6 of Google Forms v0.64 which is a CRITICAL update for anyone who loaded beta-5.  Beta-5 had a serious bug which if you had defined more than one form using the Dashboard UI, would corrupt the content of all of the saved forms so every form would display the same content.  Beta-6 fixes this issue!

Google Forms Beta (8433 downloads )
02.04.14
by

wp-SwimTeam v1.42-beta-1 available

I recently had a report from a user regarding a problem importing a HYV event file.  This event file was using Event Numbers with a one character suffix (in their case A-J).  I didn’t know using a character suffix was a legal event number and had never encountered one previously.

It turns out it is fairly common, particularly with High School and YMCA teams.  Since the database had defined the Event Number as an integer field, adding support for these “suffixes” as I am calling them wasn’t simple.

This build of wp-SwimTeam adds support for non-numeric Event Numbers and needs testing.  I have added, updated, imported, and deleted event numbers and all seems to be working correctly.  I have also exported SDIF and HY3 entry files which also look correct.  However, I would appreciate some testing from someone who is more familiar with these sort of event numbers than I am.

Please checkout the beta release and provide feedback on any problems you encounter.

wp-SwimTeam Beta (2384 downloads )
01.03.14
by

Email-Users v4.6.3-beta-8 now available

I have just uploaded beta-8 of Email Users v4.6.3.  This build addresses an unusual out of memory situations which affected sites with very large numbers of users.  You can find a detailed write up of the problem here.

The change s required to address this problem are pretty substantial so I would appreciate any testing people can do, I don’t want to break anyone’s email system!

Email Users Beta (5387 downloads )