Trudging through a complex theme implementation - Work Journal October 29, 2021

With the leaves falling and the temperature getting into morning frost territory, I figured it was the appropriate time for some reflection in blog form. After a summer of camping and enjoying the outdoors, we had an exciting transition to both our kids being in school for the first time. Having both our boys in school together means my work day is a little quieter and that lunch time is less eventful. It also means I should be able to get more work done during my work day, but to be honest, I haven’t fully embraced or utilized that opportunity yet. As far as the actual work goes I’ve had a few interesting experiences over the last few months I want to touch on.

Theme changes can be tricky

My steadiest client had a new site design commissioned and then developed over a span of almost a year. The design was beautiful and modern, with some really cool elements. But taking that design and applying it to a site that has WooCommerce, Sensei, Memberships, Subscriptions, Teams for Memberships, Genesis, and almost 100 other plugins can be very tough. This site’s code has been worked on by at least 4 different development teams over the years, and the new theme needed to play well with all that prior work. In early May, the new design launched and content was transitioned to work in the new theme. So many small styling fixes had to be made over the next couple months, but there were also some functionality changes, one of the most important being the login system. Our previous login flow used Sensei’s My Account page that doubles as a login if they are not already logged in. Now we had a dedicated page for logging in that looked nicer and we had more flexibility over the design, but it introduced a lot of customer support requests related to weird redirects and things being more difficult than they were in the past. Not ideal… Eventually we actually switched back to our old login code and those problems went away. In some ways the new design felt like a two steps forward and one step back situation. By July and August most things were working as expected, but then we noticed (and customers did too) that the site was slowing down. Also not good…I don’t attribute this slowdown to the new design, as I am pretty sure that our shared hosting server was allocating too many resources to other sites which spilled over into our site running slow. We eventually switched to a new hosting plan that put us onto a smaller server with dedicated resources but also one that allowed for New Relic NPM to be set up, as our old plan did not allow for it. New Relic and similar performance tools give insights into specific queries, errors, plugins, and files that may be causing a site to run slow. I find it super helpful, especially when server performance strays outside the norm or random errors occur. You can dig deep into why a page request took 30 seconds (instead of the typical 5 seconds) and then improve the code, server config, or database handling to prevent that problem from happening again.

Here is some of our average page load times as recorded by Google Analytics this year:
April (before the new design): 4.49 seconds
May: 6.53
June: 6.91
July: 7.74
Late August: 13.63
September (new server): 5.22

As you can see, during the summer the site started taking longer and longer to load with August peaking at about double our usual load times (for the new theme). While that doesn’t seem too terrible, this is just the average, some loads (like when a quiz was submitted )would take half a minute or more and other page loads (like a static marketing page) would take only 5 seconds. So the poor performance really was hitting our paying customers the hardest, which was unacceptable. After moving to the new hosting plan, I utilized New Relic to help me optimize some queries, eliminate some code that was bloated, and get rid of a bunch of PHP warnings that were happening on a regular basis.

Through the process of switching to the new theme, we also started using Gutenberg and the WordPress block editor for the first time (on this site). Learning how the block editor functions and the new user interface can be quite the challenge for content editors who have been using the old WordPress editor for a decade. The block editor has a lot of great functionality and easy to use tools but can also take some getting used to. It’s kinda like learning to drive a new vehicle. Most of the same functionality is there but it may be at a different spot on the dashboard or require you to push the switch in another direction.

When we do another theme one day, I would definitely dedicate more efforts to better testing processes, additional testing time with a variety of testers, and a clearer collaboration between the contracted design/development team and our own site admins. I haven’t coded a new design from scratch in years, and I really don’t miss it. Designing something new can be very exciting, but converting that design to code within a framework is a large task, made even more overwhelming when a complex existing site is involved.





The complete Work Journal series:
1. Week ending January 25th, 2019
2. Week ending February 1st, 2019
3. Week ending February 8th, 2019
4. Week ending February 15th, 2019
5. Week ending February 22nd, 2019
6. Week ending March 1st, 2019
7. Week ending March 8th, 2019
8. Week ending March 15th, 2019
9. Week ending March 22nd, 2019
10. Week ending March 29nd, 2019
11. Week ending April 5th, 2019
12. Week ending April 12th, 2019
13. Week ending April 19th, 2019
14. Week ending August 9th, 2019
15. Week ending September 20th, 2019
16. Week ending September 27th, 2019
17. Week ending December 6th, 2019
18. Week ending October 2nd, 2020
19. Week ending April 2nd, 2021
20. Coding API integrations in Twilio Studio - Work Journal May 8, 2021
21. Trudging through a complex theme implementation - Work Journal October 29, 2021