A quick note about an issue I occasionally have with HubSpot forms not rendering correctly on sites.
It doesn’t happen all the time, but sometimes HubSpot forms (when using the standard embed code they provide) don’t end up showing in the correct place on a page.
Instead they will show off the bottom of the page, or aligned along the left of the browser.
It’s not consistent, and it can be hard to reproduce.
I’ve noticed this happening in some content management systems that have optimised page rendering in place. elcomCMS is an example where it tends to happen a fair bit, but I have also seen it (albeit very rarely) when using WordPress.
Turns out the solution is very simple (and thanks to HubSpot Support who alerted me to the fix for this).
The simple fix is to wrap the embed code in a named div on the page.
Here’s an example of a standard embed code that HubSpot might provide:
<!--[if lte IE 8]>
<script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/v2-legacy.js"></script>
<![endif]-->
<script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/v2.js"></script>
<script>
hbspt.forms.create({
portalId: '123456',
formId: 'xxx-yyy-zzz'
});
</script>And here’s how it looks with the embed code wrapped in a div (and note the target: line in the form code):
<div id="hsformContainer">
<!--[if lte IE 8]>
<script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/v2-legacy.js"></script>
<![endif]-->
<script charset="utf-8" type="text/javascript" src="//js.hsforms.net/forms/v2.js"></script>
<script>
hbspt.forms.create({
portalId: '123456',
target: '#hsformContainer',
formId: 'xxx-yyy-zzz'
});
</script>
</div>It’s a nice simple fix.
UPDATE: Embedding HubSpot form script in WordPress 5.x with Gutenberg blocks
If you are embedding the form code using blocks, make sure you use the HTML block (ie don’t use a normal Text or Paragraph block):
Pingback: HubSpot Forms Rendering Issue in elcomCMS | content marketing
I had this problem, nobody at HS told me this. Is this problem stated anywhere in their documentation as it has been a massive problem for me.
There may be some doco on it now, but there wasn’t at the time I ran into this – it was only when I contacted HubSpot support that they alerted me to the fix.
Thanks Craig, you have solved a problem that I have been trying to get help with through Hubspot Support for nearly 4 weeks!
Glad it helped Dan.
Thank YOU!!! Worked perfect. Been looking for the solution to this problem for weeks as well.
Unfortunately this didn’t work for me. I created a wrapper around the code and give it a target with the ID from the container. Anything I may be missing?
Can you send me a link to your page and I’ll take a look (feel free to email me at craig@xen.com.au if easier) – our comment system probably blocks adding links in comments.
Thank you Craig!
My form loses its styling when I do this, unfortunately. It was an almost perfect solution!
Hi Caterina. Styling is controlled by the css: item in the form embed code. So, if you had that as part of your original embed code, make sure you keep when adding in the target: item. Also since you are wrapping it in a new div you can add your styling to the div in your site’s CSS file as well to override styling. That’s usually how we manage styling of forms. Hope this helps.
This still works! Thanks a lot for this.
For anyone reading this article, apparently the div _cannot_ contain the script elements – it just needs to be an empty div with the ID. Don’t forget it’s case-sensitive, too!
See: https://community.hubspot.com/t5/Conversion-Tools/Embedded-Forms-Erratic-Behavior-Not-loading-sometimes/m-p/200223/highlight/true#M1584
I don’t think that’s correct Allan. I always have the script within the div and it’s not been a problem.
The case sensitive note is important though.
Beautiful, works nicely. Thanks for sharing.
It seem it is working perfectly! Thanks