Putting your own code on one page

Sometimes there's no element for what you want: a booking widget from another service, a snippet your accountant's software gave you, a small bit of markup you'd rather write by hand. The Custom code element is a box on the page that holds your own HTML, CSS and JavaScript and puts it exactly where you dropped it.

This is the one element ClickWhale doesn't check. Everything else in the builder produces markup ClickWhale wrote. What you type here goes onto the page as-is, so a mistake in it is a mistake on the page. An unclosed tag can swallow the rest of your layout, and a script that throws an error can stop the ones after it from running. Test on a copy of the page before you put it on your home page.

When to use it, and when not to

The rule of thumb: the element is for content that belongs in one spot. Anything that has to be on every page, and anything that loads a third party, belongs in the site-wide screens instead, not least because those are the ones that can wait for cookie consent.

Writing the code

1. Drop a Custom code element into a column, container or div, like any other element.
2. Select it. A small toolbar appears above it. Click the pencil.
3. The Edit custom code window opens with three tabs: HTML, CSS and Javascript. Each is a proper code editor with syntax colouring.
4. Fill in whichever tabs you need. All three are optional.
5. Click Save in the window, then Save changes in the editor toolbar.

Both saves are needed, the same way they are for text: the window's Save puts the code into the element, the editor's Save sends it to ClickWhale.

Cancel really cancels. The three tabs work on copies, so closing the window with Cancel leaves the element exactly as it was, however much you typed.

Where each part ends up

The three tabs don't all land in the same place:

Two consequences:

Your CSS is not scoped. A rule like p { color: red; } in a Custom code element turns every paragraph on the page red, not just the ones near it. Write your rules against a class you put in your own HTML.

Your JavaScript runs early. It runs where the element is, so anything further down the page doesn't exist yet. If your script looks for something on the page, wrap it:

<script>
document.addEventListener("DOMContentLoaded", function () {
  // your code here
});
</script>

Or simply put it in the Javascript tab and keep the same wrapper. It's the safe habit either way.

What you see in the editor

Nothing. The element shows as a small purple box with three rows labelled html, css and js, each showing the first hundred characters of what you typed. It does not run your code and it does not draw your widget.

Preview is the only way to see what your code actually does. Save, then use Preview. See Saving, previewing and publishing.

Styling

Custom code is the one element with no Display settings tab: no padding, no background, no width, no responsive behaviour, and it can't join a display set. Whatever the code produces is what appears.

To give it space or a background, put it inside a Container or a Div and style that. That's the normal answer for a stubborn embed too: a container with a fixed minimal height stops the page from jumping while a third-party widget loads.

Cookie consent

Code in a Custom code element is never held back. It loads for every visitor, immediately, whatever they chose in the cookie bar. There is no category selector on the element.

So if the snippet you're about to paste sets a cookie, or loads a file from someone else's server, this is the wrong place for it. You would be loading it for people who refused. Instead:

• Put it in the site-wide screens. Site-wide custom code has one page per category, and code on the Functional, Analytics or Marketing page waits until the visitor has agreed to that category.
• Or gate it yourself. If it genuinely has to live on one page, ask ClickWhale whether the visitor has agreed before you load anything:

<div id="my-widget"></div>
<script>
document.addEventListener("DOMContentLoaded", function () {
  ClickWhale.consent.on(function (granted) {
    if (granted.indexOf("functional") !== -1) {
      // now it's allowed: load the widget
    }
  });
});
</script>

ClickWhale.consent.on calls your function straight away with what the visitor has already agreed to, and again each time they change their mind, so you don't have to worry about which happened first. The full list of what you can call is in Checking cookie consent from your own code.

Videos and maps don't need any of this. The Video and Map elements are already held back behind functional consent for you. See The cookie bar.

Blog placeholders

On a page that shows a blog post, a handful of bracketed words in the HTML tab are replaced with that post's own details:

Handy for a share link or a byline you want to lay out yourself. Anywhere other than a blog post the words stay on the page exactly as you typed them, so don't use them on an ordinary page.

Tips

• One widget per element. When something breaks you want to know which box to empty.
• Keep the original. Paste the snippet into a text file of your own as well. Custom code has no version history.
• Prefix your class names. .my-shop-badge, not .badge. A short name will eventually collide with something in your design.
• Never paste code you don't understand from a source you don't trust. It runs on your visitors' browsers, under your domain name, with access to anything they type into your pages.
• Check it on a phone. Third-party widgets are a common cause of a page that scrolls sideways on mobile.

Common issues