Case of the Coding Mystery

A recent member portal redesign project was one of those times. Besides a visual update, our client also wanted to add daily event listings and custom member information blocks. It wasn’t my first proprietary platform, but it was my first time working with this platform. I didn’t even know what language the site used. But I was going to find out.  

Partial list of template files

All I had to go on was a folder full of template files and sparse documentation. To make changes and implement features all over the site, I first had to figure out the templates’ architecture. How did the files relate to each other? The files did have a naming convention, but the filenames were too generic to be of any help. I had to do a little more snooping to figure this out.

I logged into the portal and studied the output from each page. I discovered unique comments in the output and tracked those comments down in each template. I cracked the first nut. I had the architecture! Now, I had to figure out what language the code was using.

The Game is Afoot

The templates had a big clue. They already contained code that implemented built-in features. The specific syntax of computer languages varies widely, but they are all built on the same concepts. All programs need a place to hold data (variables), a way to ask questions (conditionals), and a way to process lists of data (for-loops).

Conditional and loop processing statements wouldn’t help much since they don’t vary much from language to language. But variables do. I looked at how variables were defined in the templates:

{% assign variableName = someValue %}

The assign keyword was very unique. Usually variables are defined using a var keyword or the data type of the variable:

var variableName = someValue;
string variableName = someValue;

I bet that a Google search on “{% assign” would tell me a lot. And there it was.

The templates were written in Liquid, an open-source template language created by Shopify! Now I was getting somewhere. I knew what files to edit and what language to write in, but I still needed data. The client wanted to customize and that always means customize with data. If the information they wanted to display wasn’t there, we were done. I poured back through the code in the template files, looking for clues.

Gleaning the Data

Some things were obvious from the platform’s built-in features. Since I could create events, buy products, and view my profile, I knew there would be events data, ecommerce data, and member data available. I just had to figure out where to look. Then I found it. A way to read all the data available to the page.

If this worked for profileTags, it would work for all the information stored in data. I used my newfound command to look at the data. It was a list of events, member and purchase info—all in an accessible format. It looked like I had everything I needed for the custom data blocks. Now I could finally get to coding and apply everything I had learned.

First, I had to create a list of upcoming classes. Classes were just one category of event, but the system did not have a filtered events’ widget. So, I had to write one. I added a new “class” category through the system. Then I wrote a loop that cycled through all the events data and only display events whose category matched the “class” category.

Then I needed to create a list of all events happening “today.” This sounded a lot like the code I just wrote. But instead of matching on category, it would match on the current date. Easy. I wrote the code and published the file.

It didn’t work! I just got an unfiltered list of all the events. Liquid must not be able to directly test date values. That meant Liquid could only match against text values. But date values were numbers, not text. Then it hit me. I knew that I could format dates to customize their display and I could use that to work around the limitation. I tried formatting the current date into a string then matched each event date formatted the same way. That time, it worked like a charm.

Now I just had to do one more thing. The member welcome block needed to show primary subscription information and any add-on subscriptions. I used my data look-up trick, confident that the data would be there. But it wasn’t. I found main subscription data easily, but no matter how many times I looked through the giant list of data, add-on subscriptions were just not there.

Tech support confirmed my suspicions. The information wasn’t there. They told me to be patient, that they were working on new features to be available sometime later. But deadlines are deadlines and this time was no different. This website was done for today. It’s okay, though. You don’t always get what you want, but sometimes you get close.