I’m going to try something new where I summarize the week, along with its challenges and highlights, so you have a better idea what I am up to and the type of work I accomplished. This was inspired by Adam Wathan and Eric Barnes both starting to do it recently.
In just over a week I start a big project for Zao that will fill all the remaining time, after my retainer client work. So this week I was trying to move some projects closer to the finish line and get retainer client hours in before the end of the month.
I am getting close to finishing up an integration between FORTUS from Applied Systems and Gravity Forms. The goal is to have new leads created in FORTUS when the form is submitted. I created a new Gravity Forms add-on that has fields that can be mapped to specific places in an XML structure submitted to FORTUS. The XML file is very detailed and complex, but right now our target is 20-30 key fields we want to be passed from the form into the API. This week I was making some adjustments to the XML structure, running tests, evaluating what got stored at the other side of the transfer, and doing that until the information we required was properly stored.
As part of our retainer services for Practical Ecommerce, I accomplished two main things this week: setting up New Relic again and testing out lazy loading of images on the homepage. New Relic is a performance monitoring tool that is installed at the server level to give us deep insight into the loading of pages on the site, and it’s especially useful when the site slows down or crashes. I can see exactly what database queries or WordPress plugins seem to be causing the issue and debug from there. Last year New Relic was running, but then our host made some changes to the control panel and upgraded PHP to 7.x, so New Relic had to be set up again for the new PHP version.
The homepage for Practical Ecommerce has a section on the bottom half of the page with a lot of headlines and images. I recommended we test out delaying the loading of that content until the homepage has finished loading and someone is getting to that area of the page. Loading a few dozen images that someone may never scroll down to is a waste of bandwidth for our visitors and hurts our page load speed. I followed Googles lazy loading guide to create a solution that will load the images when someone scrolls down to that part of the page. Google provides example code for lazy loading that works in the latest browser and also another example that works on older browsers. You can check out how I simply combined the two to create something that should work well in the majority of browsers. Our implementation of that is now on our staging site so we can test it out some more and make sure we are happy with it before pushing it live.
ISS of BC
I thought I was done. This project was to create a new online english assessment using the Sensei WordPress plugin and some customizations. The project seemed to work well in my testing, but then we figured out that the Sensei plugin doesn’t behave how we would expect. I made an issue on Github but the chances of them changing how Sensei works to match my expectations are slim, so I will probably need to create an alternate solution. My problem is that Sensei sends out the email notification that a user has completed the quiz before it saves the users answers for the assessment (a quiz in Sensei lingo). I wanted to put content in the email based on what the users answered during the assessment, but I can’t get their scores for the questions yet. Next week, I will attempt to send the email using my own trigger instead of the default one that sends earlier than I need. This is the only thing left on the project. The email notifications look good, the assessment has custom section intros for the different question groupings, and I made it so that the audio file can only be played once through for the listening portion of the assessment.
My buddy Richard was trying to figure out how to get the s2 Member plugins user list to allow sorting users by two different aspects, so I spent a few hours helping him out. We needed to get it sorting users by role first and then their last name second. He already had figured out how to get it sorting by roles via a pre_user_query hook, and we tried out a bunch of ways to get a second sort value mixed in there maybe with some crazy SQL query construction, but it seemed like a fool’s errand. Sorting users by role is a very complex query because user roles are stored in a serialized array, which can’t be easily searched. After chatting with some other WordPress developers in the Post Status slack channel, it was suggested by Jon Christopher (the developer of SearchWP) to go for the simpler route of storing each users role in a custom meta field.
His solution required us going through all existing users to store their role in the new meta field and making sure any future changes to a users’ role update that field. But now we would have a clean and simple meta field to sort by that works much easier than the wp_capabilities field. Once we knew we could depend on all users having the role in the custom meta field, we were able to use pre_get_users to handle two different meta values to for it to sort by.
That’s the bulk of what I did during the week. Of course there was some of the less exciting stuff of paying bills, doing bookkeeping, following up with leads, and finding some content to share on twitter. This week had a few bumps, and I was hoping things would be a little more cleaned up as the end of the month is coming fast. Next week’