HubSpot CMS overview
If you’re new to the HubSpot CMS, we suggest beginning with the quickstart tutorial and coming back to this when you need it.
The HubSpot CMS is designed to help businesses grow their web presence with an emphasis on enabling marketers to create and manage content. The website's content, lead collection, and analytics are integrated with the HubSpot CRM, making it easy to create personalized experiences for visitors and integrate those experiences with the rest of the business.
The primary job of HubSpot CMS developers is to work as content enablers rather than content creators. In this way, the HubSpot CMS is designed to balance the needs of developers with the needs of content creators through its theme and module system and drag-and-drop areas.
A well-crafted HubSpot CMS site should be developed in close collaboration with your content creators to understand their needs, and will then require less ongoing support and maintenance from a developer. As you build on the HubSpot CMS, continuously preview how the page building experience looks and feels for content creators. This ensures they can work independently with the site as much as possible.
HubSpot takes care of hosting and maintaining the CMS, means you don’t have to worry about plugin management, updates, hosting, scaling, or security. The tradeoff here is that the system puts a few more restrictions on what you can do than self-hosted CMSs. For example, you can’t alter or extend system fundamentals manually or via plugins, manipulate low-level rendering, or access and alter database content directly.
When a page is rendered, HubSpot routes the request to one of many servers based on domain, renders the page on our servers, and caches it to a content delivery network (CDN) if possible.
The HubSpot CMS enables the creation of several types of content. The user interface for content creators is slightly different depending on content type, which has implications that you as a developer need to be aware of.
Website and landing pages are built independent of one another, but all pages are based on templates. For content creators, the process of building a landing page or a website page is nearly identical. The distinction between them is that website pages are made to present information that’s part of your website and designed to be found organically, while a landing page is generally associated with a specific marketing offer or campaign (e.g., linked from a marketing email sent to a specific list of contacts).
In the UI for marketers, the analytics and organization of these page types are also organized separately since landing pages often have specific conversion goals.
HubSpot blogs have two views—one for the listing page and one for the individual post page, then each blog post is populated into each of them. You can set a blog to share the same template for blog posts and listing pages, or have separate templates for the listing page and for blog posts. Blog posts must share the same template. Learn more about blog template markup and how to create and manage blogs in HubSpot.
Emails can be built in a few ways in HubSpot:
- Classic email: The classic email tool is built on the CMS platform, so you can build email templates and modules in a similar way to website and landing pages. You can also build coded email templates to have full control of the markup.
- Drag and drop emails: emails built with the drag and drop editor cannot use custom templates, but content creators will be able to build email layout and content using HubSpot's drag and drop interface.
In addition to creating page content through the in-app editors or hard-coding in templates, you can also use structured data sources to populate dynamic page content with HubL. You can use the following data sources to populate pages:
- HubDB: store data in cells of HubDB tables.
- CRM records: store data in CRM records, such as contacts, companies, or custom objects.
Building dynamic pages using structured content means that you can create, edit, and remove website pages and page content by updating the data sources directly. Similar to a HubSpot blog, a set of dynamic pages will include a single listing page to display the instances of your data source, then a separate page for each individual instance. Using HubL, you can fully configure the data that the pages display.
For example, you can create a HubDB table that stores a row of information for each member of a sales team. Using that HubDB table, HubSpot can then generate a listing page to display key details from each table row (such as a name and image for each sales rep), along with a separate page per sales rep to display more information (such as their bio and phone number). Should a sales rep later be promoted to a different team, you can delete their row from the HubDB table, and HubSpot will automatically delete their detail page and remove them from the listing page.
Behind the scenes, these files are mapped to entries in a database. This is why access to the developer file system is through the HubSpot CLI tools rather than direct SSH or FTP access, and some file system features you may expect, like permissions and symlinks, are not offered in the developer filesystem.
This differs from the approach of traditional CMS's, but means that broken references between file or syntax errors are caught at publish time rather than at runtime, providing you with extra insulation against accidental failures when live traffic is hitting a website.
The CMS will discover the templates in the file system and present them to content creators as they’re making new pages, so the structure of the file system is up to you. There’s no requirement that modules live in a
/js/ folder. However, it's recommended to organize your assets in a similar way to the boilerplate example code for the CMS.
Themes, templates, modules, and fields are the objects you’ll work with most in HubSpot CMS as a developer. Using these different objects effectively lets you give content creators the freedom to work and iterate on websites independently while staying inside style and layout guardrails you set.
Themes and modules contain fields, which are settings of specific data types, such as numbers, strings, rich text, and images. You can control how these are used in rendering these objects, as well as how they should be organized and appear in the WYSIWYG editor. Content creators can set values for fields in the WYSIWYG editor, which are applied to the theme or module at render time.
Inputs for content creators to control style settings for themes
Files that define the markup and style of various page types
Markup, CSS, JS
Reusable objects that can be placed as instances on pages, partials, and drag and drop areas
Markup, CSS, JS
Using themes, you can create a set of fields that content creators use to gain global stylistic control over a website without having to edit CSS. You can specify in CSS where these controls are applied, arrange controls to inherit from others, and manage how they are presented and organized to marketers in the Theme Editor. Content creators use the theme editor to modify theme fields, preview those changes against existing templates within a theme, and publish their changes.
These theme fields can be set either globally across a site or overridden at a page level.
- Building templates as part of a theme and using theme-level CSS, including theme fields, to do the majority of styling within a template. This’ll make it easy for content creators to make global and local style changes in a consistent way without needing to get into editing CSS.
- Using modules for the majority of components on your page, which allows them to be rearranged and reused across a website. Learn more about modules below.
- Using drag-and-drop areas where possible for core page content, especially on internal pages. Drag-and-drop areas let you set a default layout for the modules that comprise a page but give marketers flexibility to edit layout and style independently.
- Using global partials to contain shared content like headers and footers that you want to look consistent across a website.
Templates can be built either with HTML + HubL or with a drag and drop interface in the Design Manager. However, it's recommended to coded templates as they provide more control and functionality than drag and drop templates do, such as supporting drag and drop areas.
The controls for a module are defined in fields, so building a great module means considering both the resulting appearance on a page, as well as the editing experience for content editors.
The HubSpot CMS includes common default modules like headers, rich text, images, buttons, and CTAs that you’ll use as fundamental components. You’ll also likely want to build out elements that can have more interesting layouts that fit into your theme and templates. Some common examples of modules you might want to build are accordions, sliders, and tabbers.
Modules may also be included in themes, which allows you to use theme fields to manipulate the look of modules and ensure they’re prominently displayed in the page editor so content creators can have easy access to modules that’ll look great with the designs you’ve built.
Learn more in the modules overview guide.
Fields are the controls that content creators use to adjust the parameters passed into your themes and modules. Fields are typed, including simple types like boolean, text, URL, choice, and file, but also have more complex fields like font with styling as well as HubSpot-specific fields like links to other pieces of content or forms in the HubSpot system.
Fields can also be placed inside repeaters that’ll pass an array to the module—an example of this could be an image carousel where you want a set of images with associated `alt` text passed in. Rather than creating a number of image and text fields, you can create one of each and put them in a repeating group.
Fields of a module are specified either inside the design manager or with this syntax in a fields.json file. Fields for a theme must be specified in the
fields.json file at the root of the theme.
HubSpot’s CMS uses the HubSpot Markup Language or HubL (pronounced “Hubble”). HubL is HubSpot’s extension of Jinjava, a templating engine based on Jinja. HubL uses a fair amount of markup that is unique to HubSpot and does not support all features of Jinja. It’s executed completely on the server-side when a page is rendered.
HubL has the features you’d expect of a simple templating language like variables, for loops, and if statements, but also supports more complex rendering macros, data fetching, and mapping with tags, functions, and filters.
If you reach the limits of what's possible with HubL, HubSpot provides APIs for creating more customized solutions. CMS Hub Enterprise accounts can use serverless functions, enabling more sophisticated server side programming.
As you continue to build on the HubSpot CMS, you can refer to the HubL language reference for more details on specific language features.
Thank you for your feedback, it means a lot to us.