Debugging in HubSpot

PPrint Is Your Friend

|pprint is arguabley the one filter that every HubSpot developer should know and use. Keyword -- "USE". When you run some code that isn't working correctly this should 100% be your starting place to troubleshoot and debug your code.

Simply add it to a variable, as you would any filter, and see what comes out the other end.

Example

Let's say that we are trying to loop through an array of hubdb rows and do something with each row. We feel like we have written some banging code - yet when we look at the front-end we realize that no markup is actually showing up on the page.

Instead of weeping loudly, we -- as learned HubSpot developers -- choose to weep softly and pprint our iterations to see what the heck is going on.

{# 
  some code defining variables
#}
...

{% for row in table %}
  {# the magic tool #}
  {{ row|pprint }}

  ... 
  {# a bunch of stuff that seemingly isnt working #}
{% endfor %}

pprint not only shows you the value of what you attach it to but it will also show you the type of the output (string, array, int, etc.).

This is extremely useful because the output of our pprinted variable can help give us clues as to where our code is going wrong.

For example, in the code above it's possible that the output of our row|pprint is empty. This means that our table variable is set incorrectly and we should investigate there next.

Example 2

In another scenario we might find that each row is in fact printing, but perhaps an element that we are trying to create was not working properly.Let's say the element in question is a card link stored in a repeater field.

Our cards look fine but they aren't clickable. We pprint our row variable inside of our loop and take a look at its output. The output is a card object. We can then look for the field that isn't working - say its name is "card_link" and see if we have correctly accessed the value.

{% for card in cards %}
  {# the magic tool #}
  {{ card|pprint }}

  {#
    Might Print something that looks like
    {...card_link={open_in_new_window=false, url={href="https://www.YourSickLink.dev"}} ...}
  #}

  <a href="{{card.card_link}}">
    {# a really cool card #}
  </a>
{% endfor %}

When comparing our pprint values to the values that we are printing we can see that we havent accessed the correct value. We used card.card_link when we really should have been using card.card_link.url.href.

Wait My Code Is Already Live!

Working on dubugging some code that is already live? Maybe it works fine but your client wants to make some tweaks to how it works? Perhaps you are working on a complicated module and want to keep a bunch of debug code in a "dev environment" for yourself?

You have a few solutions.

Clone the module

Solution 1 is the "easy" fix and one that most devs think of first. Simply clone the module/tmeplate that needs some tweaking, slap that bad boy on a test page and start plugging away. Once you are done making your edits you can simply copy your code over to your live module and publish it with the fixes.

Hide Your Debugs Like A Jedi

Solution 2 is much sneakier and arguably a much better workflow because it keeps a portal nice and clean.

With this method we are going to hide our hubl debugs behind a url query parameter. The idea is simple -- say our live page that we are looking to debug exists at the path "/debug-me". We are going to structure our debug statements so they only show up when you visit the page with the query parameter of "?hsDebug=True" (/debug-me?hsDebug=True).

{% for card in cards %}
  {# 
    only display if ?hsDebug=True 
    Hides debug from live site/average visitor
  #}
  {%- if request.query_dict.hsDebug == True -%}
    {# our lovely debug attempt #}
    {{ card|pprint }}
  {%- endif -%}


  <a href="{{card.card_link}}">
    {# a really cool card #}
  </a>
{% endfor %}

?hsDebug=True isn't a random parameter, either. It does a few things that will also help us on our debugging mission. Using hsDebug=True the page will be rendered: 1. With non-minified files. 2. With uncombined CSS files. 3. Without cached files.

On top of that -- because we have wrapped our pprint in the if statement {%- if request.query_dict.hsDebug == True -%} -- hsDebug=True will also show us our lovely pprint while keeping it hidden from the average visiter.

Pretty darn neat!

So What?

pprint is the key to debugging in HubSpot. Make sure you use it - happy debugging!