This morning I pushed the v4.3.14 update to Email Users to the WordPress plugin repository. This update adds a new Spanish language translation, updates the French language translation, and fixes a problem where users who have either the capability to send to a single user OR the capability to send to multiple users, but not both, receive a permission denied error when trying to send email. A number of the permission errors have also been updated so they use the proper WordPress styling.
Tag Archives: Bug
WordPress Google Form v0.33 released
This afternoon I released the v0.33 update to WordPress Google Form. This update introduces a new setting which allows users who are using the email notification to turn off the Bcc to the Blog Admin feature. This setting is on my default to match the behavior of the plugin prior to v0.32.
Several other minor bugs were also fixed which affected how default plugin settings are handled. You can find the update in the WordPress Plugin Repository or on your WordPress Dashboard Update notification.
What happened to v0.32? I failed to update the version number in the plugin file before tagging the relase in the WordPress plugin repository so I had to increment the version number again.
WordPress Google Form v0.31 released
After a couple weeks of sitting on a new release, I have pushed out v0.31. This release addresses the ModSecurity problem that I had noted in a post a few weeks ago. After chasing this problem down with the help of several users who were willing to work with debug code and/or give me access to their server, I was able to figure out what was going on.
The simple explanation is that the Apache ModSecurity module can be pretty restrictive and returns 403 errors when a form is submitted. WordPress then does it’s thing and concludes that the page should be displayed again. The net result is that form is never submitted and no feedback is provided to the user. From what I’ve seen, ModSecurity doesn’t like URLs passed as parameters which WordPress Google Form does for the Google Form – it needs it to submit the responses to the form.
With this update two things have changed:
- If a 403 error is returned, the plugin will check for it and show a message if/when it happens.
- The Google Form URL is passed as an encoded parameter so it doesn’t get flagged by ModSecurity.
These changes won’t address all instances when ModSecurity kicks in – if your form includes any input where a user can type a response AND they user submits a URL as a response, there is a pretty good change a 403 error will be issued by the server.
Hopefully this change will help some very odd use cases where users don’t understand why the plugin isn’t working for them. It has worked in four (4) additional situations that users have asked me to look at it plus the two original that I looked at.
You can find the update in the WordPress Plugin Repository.
wpGForm and Apache Sercurity
A while back I was contacted by a user who had deployed wpGForm on their site with a problem they wanted my help with. In looking at it I was absolutely stumped as to why it wasn’t working. Nothing appeared obvious – when the form was submitted, the form would be displayed again as if for the first time. In the process of chasing down this problem I’ve added quite a bit of debug code but in the end, I found Firebug’s Net Panel incredibly useful.
In this particular case it was showing me that the form was being posted but a 403 Permission Denied response resulted. Why? The exact same URL worked to show the form, why wasn’t it working to process the form? I ended up separating the rendering and processing part of the plugin thinking this was the problem (like it was on a site a couple of weeks ago) but it didn’t make any difference (although it was the right thing to do). I was still getting 403 problems.
I was working closely with the site owner, they were nice enough to allow me to really dig into their site. What did I find? A bunch of plugin and theme minor issues that I chased thinking they were conflicting somehow to no avail. I ended up opening a ticket with the hosting provider and once we clarrified the problem, they sent me so error log information:
[error] ModSecurity: Access denied with code 403 (phase 2).Match of "rx
://%{SERVER_NAME}/" against "MATCHED_VARS:gform-action" required.
[file "/usr/local/apache/conf/modsec/10_asl_rules.conf"]
[line "489"]
[id "340162"]
[rev "262"]
[msg "Atomicorp.com UNSUPPORTED DELAYED Rules: Remote File Injection attempt
in ARGS (AE)"] [data "
https://docs.google.com/spreadsheet/formresponse?formkey=dhzsutftwllwzwf6lwd
yb0xcmkzsogc6mq&ifq
"]
[severity "CRITICAL"]
[hostname "lanaddicts.org"]
[uri "/test-form/"]
[unique_id "UAbUbnrJTaEAAHtoboQAAAAG"]
Wow! At first I didn’t know what to make of this. A Google Search led me to this Atomic Corp Wiki. I decided that the Apache Security Module must not like the Google Form URL that I need to carry around through the process in order to submit the form variables to Google. I decided to encode it and then decode it when needed to see if that would satisfy the Apache Security Module.
Guess what? It works!!!! This is a big relief as I have another user with almost the exact same error being reported and I am betting my updated plugin will fix their problem too.
If you want to try out an early build while I continue to test, you can find one here.
wp-SwimTeam v1.34.963 available for download
This afternoon I fixed a couple of minor bugs and pushed out v1.34.963. The primary new feature in this release is the ability to export Meet Entries to Hy-tek Team Manager. I have had lots of requests to support Hy-tek over the years so I am happy to say I can finally support it!
As anyone who has read my postings over the past few years knows, I am no fan of Hy-tek. Between the closed data format and the awful user interface, it amazes me that their products have become the defacto standards for Swim Team and Swim Meet management but they have. If you want to play in this space you need to interface with Hy-tek. Fortunately some smart guys decoded the HY3 checksum and through lots of experiments some other people have figured out the HY3 file format so building on the work of others, I can now export a roster and meet entries in HY3 format.
I would appreciate feedback in this area as I have tested what I can but there is no such thing as too much testing and I may not have envisioned every scenario. There is also a very strong possibility that some of the fields in the HY3 format may not be in the right place or contain the right data.
I also fixed a number of issues when browsing Parents, Swimmers, and the Roster where the Search function wasn’t working correctly. Most of these problems were due to the SQL changes I made to address performance issues but a couple of them were due to allowing search against fields which are computed as opposed to extracted from the database.
wp-SwimTeam v1.34-beta with Hy-tek HY3 meet entries!
Tonight I posted an early build of wp-SwimTeam v1.34. You can download it and manually install it if you would like to try it. This build introduces the ability to export Meet Entries in Hy-tek HY3 format which can be imported directly into Team Manager and Meet Manager.
This build also addresses a number of bugs I’ve encountered, the most notable being the inability to generate a single swimmer roster export in SDIF and HY3 formats. Instead of just one swimmer, the entire roster was exported. This has been fixed. The CSV export was not affected by the bug.
Please let me know if you run into any issues. I plan to release this later today after some more testing.
Download: [download#14]
If you run into any problems, please let me know. I’d like to release this update in the next day or so.
wp-SwimTeam v1.33.949 now available
After a day of testing on the MacDolphins site without any issues, I have released v1.33.949. There are no changes between this build and the v1.33 beta build except the version number and the removal of the beta tag.
This build fixes a number of problems related to swimmer and user data which surfaced after I changed the database queries I was using in v.1.32.
- Fixed bug which prevented generating roster report.
- Fixed bug which prevented scratching swimmers from Meet tab.
- Added additonal table to Meet Report when operating in Stroke mode which reports number of swimmers Opting In or Opting Out per age group.
- Completed first phase Meet Entries export in Hy-tek HY3 format. Not exposed on the GUI yet.
- Fixed bug which prevented Job Reminder emails from being sent.
You can find the update on the Download & Installation page or in the WordPress Plugin Repository.
wp-SwimTeam v1.33-beta.948 now available
This afternoon I posted an early build of wp-SwimTeam v1.33. You can download it and manually install it if you would like to try it. This build addresses a number of bugs which I introduced by changing the SQL in v1.32 for querying user data as it relates to swimmers.
Please let me know if you run into any issues. I plan to release this later today after some more testing.
Download: [download#14]
If you run into any problems, please let me know. I’d like to release this update in the next day or so.
wp-SwimTeam v1.32.931 now available
After a few days of testing on the MacDolphins site without any issues, I have decided to go ahead and release v1.32.931. There are no changes between this build and the beta build except the version number and the removal of the beta tag.
The primary feature in this update is new SQL which addresses performance problems when working with user data, particularly when is relates to swimmers. The Job Commitment Report was particularly noticeable in how slow it was (4-5 minutes) if it completed at all. The SQL addresses that performance problem however since it used extensively across the plugin I wanted to make sure I hadn’t broken something else.
You can find the update on the Download & Installation page or in the WordPress Plugin Repository.
Beta build of v1.32 available
This evening I posted an early build of wp-SwimTeam v1.32. You can download and manually install it if you would like to try it. This build introduces new SQL to address some pretty serious performance problems querying user data as it relates to swimmers.
For several weeks our Swim Team Chair has been telling me there is a problem with the Job Commitment Report. I have been chasing this problem only to have it “go away” and start working correctly. I finally figure out that it was related to the large number of users registered with the site (we have almost 300). I was able replicate the problem by creating a large number of dummy users in my development database. The manifestation of the problem was most evident on the Job Commitments Report. The page would “go away” and give the appearance of a hung process. In some cases the report would finish but might take 4-5 minutes (ugh), in others it would timeout and return an error.
I had to solve a similar problem for the Email Users plugin last week so once I figured that one out, it dawned on me what the problem with wp-SwimTeam might be. Fixing it in wp-SwimTeam is a little more involved because of the database table relationships are a little more complicated. I’ve learned a lot about JOIN ON this week and this beta release represents completely new SQL for querying user data.
I’ve been through all of the tabs and forms at least once but there is a chance I’ve missed something. I am running this beta build on the MacDolphins web site and if I don’t run into anything over the next few days, I’ll go ahead and release it.
Download: [download#14]
If you run into any problems, please let me know. I’d like to release this update in the next day or so.