CMS Development

PatrickEng
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

Edit: The CMS Hub AMA is now closed. Thank you to all those who participated! If you continue to have questions about the CMS Hub, please log in to your HubSpot account, click on the Help button in the bottom right, and reach out to our Support team at any time. Cheers!

 

Hey HubSpot Community,

 

My name is Patrick, I’m a member of our onboarding team here at HubSpot. Welcome to our 2nd CMS Hub AMA! We loved answering all your questions in the last AMA and we hope to provide even more information on the ins and outs of CMS Hub. We’ll be available to answer questions from April 5 - April 9, so please feel free to ask us anything.

 

If you’re not sure where to start, try some of these:

  • How can I gate pages behind a social media login?
  • How do I build my own theme using the local development tools?
  • How do I add structured data to a page? Is it worth it?
  • I want to host my website on a root domain, not a subdomain. Can I do that?

 

We have members of the HubSpot product, developer, and services team here to answer any questions you might have. 

 

Luke Summerfield (@Lukesummerfield) - CMS Hub Go-To-Market Lead, Product

Jon McLaren (@jmclaren) - Senior CMS Developer Advocate

A.J. LaPorte (@AJLaPorte) - Senior CMS Developer Advocate

Madelyn Simmons - Customer Success Manager

Allison Nichols (@anichols) - Principal Onboarding Specialist

Justin **bleep** (@jtit) - Senior Customer Onboarding Specialist

Patrick Eng (@PatrickEng) - Customer Onboarding Specialist

Ernestina Spinu (@eSpinu) - Senior Customer Support Specialist

Camila Rovalino - Content Product Expert

Cathal Hopper (@CathalHopper) - Customer Support Specialist

 

Feel free to drop in your questions below. We’ll start answering questions at 11 AM EDT on April 5th, until 3 PM EDT on April 9th.

 

Look forward to hearing from you all soon!

82 Replies 82
PatrickEng
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

Hey @BTaylor ,

 

It sounds like you're probably using the CRM Extensions API, which you are correct in saying that it has to be in the right sidebar. My other thought would be leveraging the Timeline API as that would allow that to live in the middle section (i.e., timeline) but it would appear chronologically and not as a box in the sidebar.

06723
Participant

[Closed] CMS Hub Ask Me Anything (April 5)

@PatrickEng Hi, 

 

Does HubSpot automically add 2 hreflang tags if you have more than one domain. I have a German and English domain. I do not want to have 2 hrelang tags on one Single english domain for example. Can you help me remove one of the two on idividual pages. 

 

Below is a screenshot of what i am referring to

 

 Screenshot 2021-04-05 at 20.09.51.png

I need one hreflang per domain.

 

2nd Question 

 

Are there any actions we take to ensure our websites passes the Google Core Web Vitals Update. I know HubSpot handles most optimisation tasks, however Google Search Console still reports that there are URLs that fail to pass Core Web Vitals test

 

Your assistance would be greatly appreciated. Thanks 

breichenbach
HubSpot Product Team
HubSpot Product Team

[Closed] CMS Hub Ask Me Anything (April 5)

Hey @06723!  I'm happy to speak to both of these! 

 

1) For hreflang tags, we do automatically add a rel="alternate" hreflang tag for each language variant within a multi-language group. Our decision for doing so is rooted in Google's dev docs outlining how multi-language content should be treated, which you can find documented here. That said, this should only be populating automatically if you're using our multi-language functionality. So, any page that has an English and German translation and is identified as a multi-language group will have this type of hreflang setup, but a single page that is not part of a multi-language group should not have hreflang tags automatically generated. If you're seeing anything to the contrary, feel free to DM me with a link to the page where you're seeing it! As for the standard functionality with multi-language groups, we don't currently offer the ability to omit hreflang tags. 

 

2) Core Web Vitals opens a whole can of worms! There's a ton that you can do, stuff you probably should do, and stuff you could do if you had the time and resources to do so. At a very basic level, we have ongoing initiatives to make and keep HubSpot fast, including the tasks documented here. Additionally, our default templates and themes are mobile responsive and tend to do pretty well for things like CLS (cumulative layout shift) and TTI (time to interactive). One of the interesting challenges of being a CMS, however, is that we also want our customers to be able to customize and modify their content so that it best meets their business' needs. This means that there are a lot of variables that can be brought in during the dev and customization processes that we don't really have much control over. If you're seeing specific pieces of content encountering errors with Google's Core Web Vitals reports, I would definitely recommend partnering with a partner agency or developer who can do a thorough evaluation of your content setup and make specific recommendations as to what to improve. Depending upon when your site was set up, it's quite possible that you could make huge wins in the CWV department by implementing a lazy loading mechanism to defer off-screen images and removing or minimizing jQuery dependencies– those tend to be the two areas where I see the most recurring opportunities for improvement. 

Ntbrown
Contributor

[Closed] CMS Hub Ask Me Anything (April 5)

Any plans to add no_wrapper options to DnD areas? No idea why these weren't added when they're available on all other rendering tags. It's a ton of bloat nobody wants or needs on their page. The bloat that gets added from this is larger than the entire main JavaScript file for most HubSpot sites....

 

Any plans to improve performance considerations prior to the update in May from Google directly reflecting page experience to users via web metrics in SERP? Per the multi year old threads in this community performance is.... bad. In part due to platform level problems and just poor coding practices that's ubiquotous on most Hubspot websites I see. The latter you can't fix and isn't HubSpots job... the former you can and is.  It's going to be amusing when clients with a HubSpot website are marked as being a "poor" experience, potentially, in SERP after sinking so much money into this platform for something that is no fault of their own and is virtually impossible to fix in the platforms current state without a lot of hacky work arounds. There are ways to get near perfect scores stripping out all of HubSpot's "junk", but I won't detail them here.

 

Any plans to reduce / optimize the massive bundles of JavaScript served? Pull down any HubSpot website.... Analyze the weight by content type. >60-80% JavaScript due to the incredibly heavy bundles for forms, etc for a simple marketing website. Now, most websites are "light" especially with optimized images so that's not too unusual in and of itself, especially with modern JS frameworks, but in the context of these types of sites and the weight of these bundles for what they are.... They're extremely heavy.

 

Moreover.... being a platform that touts international capabilities / multi-language variations you should know that many regions have significant data problems.

 

What is the current CMS development roadmap / what improvements are being made? People can be charged thousands per month, dependent on products, just to realize they've not only spent a ton of money for little gain, but ended up with a product that is subpar in almost every metric due to performance and other problems... Per this and similar threads it's always "we're improving" and that's nice.... But, how? When? Why? A public timeline for these things should really be the bare minimum considering the amount of money your clients are spending when a $10 host and plugin beats you. Not to mention the time to development / completion isn't even in the same ballpark. A recent example of a bad timeline.... are theme breakpoints that were "released" 6+ months ago, still haven't been completed, and were "coming soon". Don't get me started on themes. 🙃

 

Do you plan on allowing more flexibility for developers not marketers within the CMS? Again, this is often stated that things will "improve". But... How? When? Track record doesn't give me confidence in this. File structures, meta, sitemaps, etc. All of these are basic things to edit and it's remarkable these aren't already exposed. I can't imagine being a client and paying that much money and not even controlling my own sitemap or having a way to interface with it. Beyond this... You've also inadvertenly caused problems with development patterns that require sitemap configurations. Third party feed integrations, Yandex, etc. List goes on. Morever, as a developer I would never suggest that to a client knowing full well that I can't fix any of it. 

 

Do you plan on adding an actual programming language for CMS developers to interface with? Not a templating language. There's only so much you can do with this and doing logic in a templating language is inherently poor programming to start with.... 

 

Do you plan on adding other event types to workflows? Page events. Hooks prior to publishing.

 

Lot more, but these would be a good start. Frankly, I don't see how a multi-million dollar company has had such remarkably poor progress with such basic web features over multi year timelines whilst having the gall to charge people such exorbitant sums of money.

jmclaren
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

Hey @Ntbrown,

 

Thank you for taking the time to ask those questions. Apologize for this being a bit long but there were a lot of good questions and I wanted to make sure I thoroughly answered them.

Any plans to add no_wrapper options to DnD areas?

In the short term no. While it's understandable to want as much control of the underlying code as possible the page editor experience depends on those wrappers existing. If you had the ability to remove it, you would need to handle every state a module could be in manually, and ensure the drag and drop functionality continues working on into the future. If new page editor functionality came out months after a site was implemented, but the developer opted to use their own HTML/CSS structure - that customer may not be able to use it because the developer never accommodated for it. So what temporarily is a great experience for a developer can easily become a bad experience for the marketer.

We hear you though, we're looking at a lot of different solutions to give developers more control over the code and also how developers can use frameworks of their choice. Additionally though I'd love to hear your thoughts about how we could give you as a developer more control in this regard without hurting the marketer's experience. It's harder to achieve but we think we can strike the right balance.

Any plans to improve performance considerations prior to the update in May from Google directly reflecting page experience to users via web metrics in SERP?

While we are always actively working on improving performance - we are looking deep at every aspect of the performance equation to squeeze every ounce of speed out that we can.

 

Specific changes you may have already noticed:

  • We’ve been iterating on our theme boilerplate to improve loading speeds for it. It consistently scores 90+ on Google page speed. Basically meaning if you manage to get below 90+ on Google Page speed it’s due to something you added on top of the boilerplate.
  • Images, we’ve added lazy loading to image fields.
  • require HubL functions async defer enhancements.
  • Updated the related blog post listing function so that you can trigger a JS callback ensuring faster....
  • automatically resize images that have height and width attributes. 
    • We generate srcsets for these images as well.
    • Side benefit this encourages a best practice for preventing CLS
  • automatically serve webp images when webp is a smaller file size and the device/browser supports it.
  • minify all of your CSS and JS.
  • Using HubL you can combine your CSS or JavaScript files together using the HubL include tag.
  • Pages and files are cached both on the server and browser level to ensure the quickest delivery of all page assets, when a page or dependency of the page changes we automatically expire the server cache for that page.
  • Automatic domain rewriting.
  • image editing functionality baked in so you can resize/crop images when adding them.
  • We provide developers full control over the image resizing functionality, through resize_image_url, which you can use in your theme’s stylesheets and module.html
  • We dropped the requirement of jQuery meaning you don’t need to load that library at all for HubSpot functionality to work. For sites that were built using jQuery, we created a guide for how to upgrade to the latest more efficient version of jQuery.
  • When using require_css or require_js your stylesheets and javascript are only loaded when that content is actually on the page. Similarly module CSS and module JS only loads when the module is on the page.
  • All assets are served via our worldwide CDN.
  • We encourage developers to follow best practices by continually updating our developer documentation, and encouraging fixing problems we find through the Code Alerts tool, and our SEO tool
  • HubSpot sites are served via HTTP2 with GZIP compression. All HubSpot hosted sites include IPv6 addresses.
  • HubSpot blogs support AMP.
  • CMS Hub Enterprise supports serverless functions, enabling you to write back-end code to retrieve data via APIs and dynamically update the front end without a page load, which can enable you to build single page apps.
  • To make the experience of building single page apps faster/easier, we created a page with recommendations for how to work with them within CMS Hub. https://developers.hubspot.com/docs/cms/guides/js-frameworks
    • we created boilerplates for Vue and React.
  • We encouraged theme developers in the marketplace to build performant themes through the recent theme challenge, where one of the categories judging criteria was website performance.
  • On the back-end every week there are changes that make our platform more secure, reliable, and faster going out.
  • We're removing the “magic” where we can so developers can build their own modules like menus and whatnot without relying on our code, then where we can we show you exactly how to do it using the boilerplate. This gives you control over the output code and performance.
  • Integrated lighthouse into our website grader tool and are perpetually updating it to provide deeper and deeper insights.
  • Our APIs also got a lot of improvements recently and other APIs are catching up to also have those improvements. Improvements like supporting batching. Reducing API calls.


The web and what different entities consider "fast" never stops changing. There's more we're working on, and we will continue to release improvements to make it easier and easier to build fast websites. 

 

Any plans to reduce / optimize the bundles of JavaScript served?

You specifically mentioned forms. Forms are unique in that they require a lot of state management, error handling, and we have features like progressive fields, dependent fields, you can even place images in your form, we have all of the underlying input field types. It's a lot and it's critical that it's backwards compatible to a lot of different browsers otherwise folks could lose out on sales. The forms team for awhile now has been looking deeplly into the code they render and control, I don't have specific details to share at this time. I'll pass this feedback on to the forms team. In the meantime if you are dissatisfied with the performance of the forms you are welcome to use the form submission endpoint to roll your own form, just understand you then must handle the error handling, dependent fields, etc.

If you see another opportunity for something we can do to improve performance even further definitely submit it to the idea board. We're always looking for more ways to make CMS sites even more blazing fast.


What is the current CMS development roadmap / what improvements are being made? 

As a publicly traded company we're limited in our ability to share our full roadmap, but we can give you a good taste. We have a public roadmap page that if you scroll down toward the bottom you can see a little bit of what's in store for each HubSpot Hub.

 

Do you plan on allowing more flexibility for developers not marketers within the CMS?

We have many big things planned specifically for developers. Some are noted specifically in the public roadmap page.

We think that the CMS should have both an excellent developer experience, and an excellent marketer experience. What that generally means is we're constantly balancing what's better for the developer, and what's better for the marketer. It's a very hard balance to achieve, and our competitors have often simply picked one audience or the other. We want to be different in that regard.

Specifically regarding sitemaps, we have a built-in tool for managing your sitemap. If it's missing a feature you'd like please do share it in the idea forum.

 

Do you plan on adding an actual programming language for CMS developers to interface with?

In a way we have actually. We added Node.JS support through serverless functions. There are a lot of advantages to serverless functions for doing functional code. A few good ones though actually are tied to your previous questions. By doing functional type programming in the serverless function instead of at the template layer you can more easily deliver more real-time data to the page. The page also can be fully cached, making it load faster. That said, we know Node.js may not be your preference. What languages would you like to see us support?


Do you plan on adding other event types to workflows? Page events. Hooks prior to publishing.

Do you mind elaborating with some use-cases you're thinking of? "Page events. Hooks prior to publishing" makes me think of possibly 2 completely different things and I want to be sure I understand your intent.

Jon McLaren

Sr. CMS Developer Advocate

Get started developing on the HubSpot CMS Developer Changelog
How to optimize your CMS Hub site for speed

If my reply answered your question, please mark it as a solution, to make it easier for others to find.

Ntbrown
Contributor

[Closed] CMS Hub Ask Me Anything (April 5)

@jmclaren As a publicly traded company we're limited in our ability to share our full roadmap

Ironically, I've done a lot of trades on HubSpot's stock... No idea why I didn't realize that sooner. That's fair.

 

Do you plan on adding other event types to workflows? Page events. Hooks prior to publishing.

Do you mind elaborating with some use-cases you're thinking of? "Page events. Hooks prior to publishing" makes me think of possibly 2 completely different things and I want to be sure I understand your intent.

Sure this is fairly straightforward. Page events that allow a "hook" into how things become "spit out" by the template rendering engine / prior to being cached would be immensely useful and imo goes a very long way to fixing the vast majority of problems with HubSpot sites and development problems overnight were this released. All you really need is to open up the page events API / files via the webhooks flow. You should have most of the items available to do this already without too much technical debt.

 

I'll give you very clear use cases with utility:

 

1) Critical CSS

2) Injected table of contents 

3) Injected meta / schema if the page is able to be parsed via workflow hooks / shoot off some webhooks -> re-inject things prior to publishing.

4) Events for push notifications on publish (new posts, ...)

 

 a million other use cases....

 

Currently doing simply things like this is very contrived and even impossible for 3). To do 2) you either need javascript which is a horrible solution for this or to track an entire registry via hubl and inject it at the end of the template / rendering process amongst other things. Critical CSS is an automated process... nobody should be doing critical css on a case by case basis.  Dependnet on level of control... you could even do name manging and splitting.

 

My point here is a lot of the problem with HubSpot development is this lack of control and ability to interface and do things that are incredibly easy on other platforms. The reason all of this is possible on wordpress and other platforms is simply because their developers have the ability to use PHP and other languages at this level. It's not intrinsic to the platform itself or anything that's "magic".

 

This goes back to 1) about programming languages and the ability to interface with the CMS on a lower level and do this and 2) performance problems. So, with the lack of this page events would essentially open up a "plugin" ecosystem that could fix some but not all of this. Really most of the things I've listed are part of the same problem.

 

But even that's still not good enough. You really need the ability to use a language / lower level interface to do the vast majority of things that are actually useful. As stated previously, sitemap management, feeding, and a plethora of other use cases. Let's reframe this also if you're not seeing it:

 

I as a client pay $$$ to use the platorm to inevitable inherit the problems below, but beyond that I also don't even control my own site map, can't manage my syndication, and can't even hire someone to do it or me.

 

What if I had a russian audience? What i I wanted to target Yandex and needed to manage the way my feeds and sitemap are constructed per their requirements. What I have a big target audience that uses, say Feedly, and I can't target that?

 

So what are you supposed to do? Do I pay for screaming frog / pay for multiple different services to manage all of this to fix platorm imposed problems at which point why am I wasting all of that money to just pay more money to "patch" all the problems I have?

 

See my point? What value is there in a platform that requires fighting such an uphill battle constantly from every development aspect - in the platforms current state. 

 

Obvious problem: Determinism / locks. But, there are ways to handle this. If there's a single feature that should be added.... It's this one.

 

Re: Performance list. Not going to quote that behemoth wall of text.... Yes all of those are available and some of them have been for quite some time. But, many of those features are masking underlying problems. Others I wouldn't really consider an "improvment" rather than the "bare minimum" according to standards. Yes, there are complex and in many cases convoluted performance optimization techniques you guys can't achieve reasonably - within a bundled CMS - but there's still room to improve here... You guys are going to run into a big problem when HDR specs are completed and HDR is feasible on the web fyi.

 

Re: Fast pace of evolution. Entirely correct. This is also why themes need to be opened further for developers and my final point here are required. There's no way you guys can keep up and even if you could.... It's still suboptimal. In fact, I'd go so far as saying most of the recent product "improvements" have actually been steps back. So, I'm not confident in this nor would I suggest other to be.

 

You specifically mentioned forms. Forms are unique in that they require a lot of state management, error handling, and we have features like progressive fields, dependent fields, you can even place images in your form, we have all of the underlying input field types. It's a lot and it's critical that it's backwards compatible to a lot of different browsers otherwise folks could lose out on sales. The forms team for awhile now has been looking deeplly into the code they render and control, I don't have specific details to share at this time. I'll pass this feedback on to the forms team. In the meantime if you are dissatisfied with the performance of the forms you are welcome to use the form submission endpoint to roll your own form, just understand you then must handle the error handling, dependent fields, etc.

If you see another opportunity for something we can do to improve performance even further definitely submit it to the idea board. We're always looking for more ways to make CMS sites even more blazing fast.

The real problem with forms is CLS shift, same with CTAs, due to their asynchronous nature - naturally. Currently if you want to fix that it's a case by case basis.

Beyond that... coming back to the original question, I believe between this, the cta, and other scripts loaded it's roughly a half megabyte worth the javascript....

 

Edit: Actually the v2 forms alone is 500 KB.... Let's reframe this.... To load a few forms on my site... I need to load a script that's the equivalent of loading dozens -to hundreds of optimized images (ranging from webp to small svgs).

 

A lot of this has to be bloat. I cannot fathom any JavaScript file that is 500KB doing something as simple as rendering forms regardless of their complexity or dependencies. Bundles styles, i18n, etc are included within the JavaScript bundle for forms regardless of need. That alone would significantly trim the size. What website, outside of external embeds, doesn't style the forms and necessitates bundled styles?

 

Especially with themes..... Obviously, not familiar with the stack or what happens on a lower level, but at a glance I fail to see how this necessitates being bundled outside of third party integrations. If it's not international.... why the i18n? Sure, maybe you have one form on the page that's embedded and one isn't.... But, that's extremely rare and obviously erroneous if someone is using both and even then you could just grab the split in that case.

 

There are plenty of techniques here and most companies employ them. I'm surprised you guys aren't already doing this. It's incredibly common to do code splitting in this manner by serving `/localized/` paths to assets with only the necessary bundling. And that's just a start...

 

This is common amongst all HubSpot assets served to clients. Poor code splitting. Last time I looked at the CTA file I believe there were redundancies being served that could be trimmed, but it's been a while. Regardless the bigger problem with CTAs and these assets is dragging out the waterfall and clogging it by injecting per element.

 

Let's reframe this also....500 KB to load a ew orms on a platform that touts i18n in which many of these regions are still 2G connections.... Also just a lot of data for little gain.

  

In the meantime if you are dissatisfied with the performance of the forms you are welcome to use the form submission endpoint to roll your own form, just understand you then must handle the error handling, dependent fields, etc.

This is actually my main point of the entire thread.

 

Currently - and actually for the multiple years people have been bringing this up - the "solution" has always been "well don't use it" in which case what value is this providing / does the platorm intrinsically have to anyone if every platform feature, supposed to be providing value, necessitates having to not use it in order to have a website that's on par with expected standards? That's rather paradoxical.

 

For modules: Critical chaining requests -> kills web metrics -> just don't use it! Use a modules css ile or a main bundle.

For CTAs: Use tracking links or the API instead

For forms: See above

List goes on....

 

I even have wordpress / other clients that try to use hubspot forms via 3rd party and eventually have to drop them because it mars their websites so badly.

 

It's a very hard balance to achieve, and our competitors have often simply picked one audience or the other. We want to be different in that regard.

Yes it is, but that balance is exactly what's stunted the CMS and will continue to do so. At some point you're going to have to pick - and you guys are already very behind your competitors. Realistically, who builds everything? The devs. I cannot count the number of people that cannot do even basic text editing much less actually managing their site to any reasonable level and if I, as a dev, have to come in when a marketer finally gives up and hires someone to do the hard stuff... well at that point I shrug my shoulders, go "this is a mess", and don't bother. These approaches severely over estimate peoples capabilities.

 

This leads into various discussion threads across the forum - can track down if you want.  To summarize, from the marketing side.... I see your point it's a hot sell to marketers and a "good" feature to have, as a company you need that, but it's horrendous in the long run. 1) Simply because it empowers the wrong people due to the previous and 2) it causes client websites to become an asset that inherently loses value and gains entropy because marketers don't know what they're doing - no offense to any that's not a jibe but a simple statement that it's not their domain of expertise - and as we very well know the web is complicated with complex standards. Especially with all the new web tech coming out.

 

Here's a way to reframe this:

 

Is this approach actually valuable or provide anything of value to anyone - developer or marketers? It doesn't - at all in my opinion - quite the opposite.

 

For the developers it's horrible on every facet due to 1) lacking control due to trying to balance this and ending up with something that's halfway there or both parties and 2) always inherting a mess when marketers eventually break down and hire someoen to do the hard stuff.

 

For the marketers... looks great on the surface as described.  But, again lacking experience and no idea what the implications of their edits are, so eventually marketer / owner goes "wow this is bad, we have no good web metrics, ..." and ends up hiring a dev anyways. Much less wanting to add anything even remotely modern.... color schema etc. So, with all their free-form editing provided to them they build a subpar site with significant problems they're not even aware of. Then, the dev has a very limited feature set to work with for improvement and can barely improve anything despite their skillset, because of the restrictions.

 

None of these things, on any platorm that has ever tried to do this, has ever worked. It's why people still hire "divi" developer, "wix" developers and all of these developer "types" for the simple reason that it's too complicated for people to handle that aren't technical - even your platform in it's very basic state is too complicated for marketers. And, to be frank, Wix and other editing interfaces are not even in the same league as you guys. So, i people can't handle a very smooth modern editing interface there's little chance there handling HubSpot's much harder to use variant.

 

So, as a client here's where I'm at in this process: I start off with hubspot -> buy their packages / cms, etc -> pay loads of $$$ -> everything looks good or the first few months -> I start noticing problems when I start paying attention to search console and actual metrics -> try to hire someone to fix it pay laods more $$$ -> they can't or achieve it in a subpar fashion, because that's all they really can -> maybe I try this or months on end paying $$$ and lots of time and effort to achieve something so basic / minimal that would have taken < 2 hours on WordPress -> eventually give up bite all the $$$ I've wasted and move elsewhere to rebuld my entire site to achieve what I couldn't.

 

That's incredibly problematic and disheartening.

 

I have had countless clients go through this process - inherited projects where they have - etc and every last client eventually goes "hubspot... yikes" let's move to platform X due to this. Beyond this, as stated, no developer can reasonably recommend this. A large problem with client outcomes and "developers" on HubSpot is it's marketing.... It's marketing agencies that aren't development shops - despite what they may think - and tend to pump out subpar quality technical assets for their clients in some "bundled" package with severely lacking standards and nobody in house that has a relevant skillset.

 

So, 1) bad interface, 2) bad control, 3) bad dev. experience, 4) bad assets for clients, 5) bad technical resources / agencies compounding all the previous. A developer focus also helps "wash out" all of these so called "developers" and subpar outcomes. It's harder, but in the end everybody wins except maybe said marketing agencies - which I'd personally consider a bonus. But, this comes full circle with who exactly HubSpot's client base is 😉

 

Bonus: Editing interace / rich text editor is incredibly annoying to use sometimes. Example being automatic insertion of <p>'s when used as a image insertion block. Yes, I agree that's a poor usage, but again marketing standards not dev standards.... so it happens. And it immediately breaks the nice flow / alignment of the grid. Obvious solution would be something like p:has(> img) + p:empty but that's not the best way to go about this. Adding some safeguards here would be helpful.

 

Beyond that.... Developers really need a way to hook into the rich text edtior beyond removing things. We need to be able to add things. Footnotes, references, stock tickers, etc possibilites are endless. Being a dev... obviously I see the technical limitations here and the JSON representation is already massive for what's already included in terms of feature sets, but regardless.

 

@jmclaren 

 

Edit: Extra bonus.... i18n **bleep** for various reasons the least of which being the size of bundles... But, also in terms of hreflang and other writing system / path management.

 

You don't always want to denote hreflang / alternate language variations according to languages... Look at Apples homepage as one example. Their approach is incredibly common. They target english as it's spoken in latin america via `/lae` paths mapping to `en-(REGION)` variants. There are similar approaches people very commonly us

 

You can actually do this through some hacky methods... And in this case it's actually a bonus you guys don't do anything of value in the sitemap such as indicating alternate langs otherwise this wouldn't work 🤣

 

I touched on the highlights here.... So, while you guys are attempting to "strike a balance" what you're really doing is providing nothing of value or to a degree of utility. 

rohansdeeson
Top Contributor

[Closed] CMS Hub Ask Me Anything (April 5)

One thing I would really like team HS to look at with CMS hub is pre-prod --> prod pricing.

It would be great if it was possible to pay a nominal licence fee for CMS enterprise until it has a domain applied to it then you pay the full licence.

On a large Enterprise CMS site, there can be months of development and content creation before you are ready to go live. And during this time you are generally paying your existing costs, so to pay $900 per month while developing is very costly.

An easy solution would be for there to be say a $50 per month cost while building then once the domain is added you pay full price. Our client is likely to have 4months of development and content creation meaning almost 4k of costs before going live.

lukesummerfield
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

HI @rohansdeeson - This is a great observation and very understandable. If the website isn't live, your business isn't seeing any value... so why pay?
We felt the exact same way a few years ago and knew there had to be a better way. 

We now offer free developer sandboxes that can be used to build the website for free - you only pay when you're ready to launch the website (and connect a domain). 
Additionally, if you look at our CMS Hub public roadmap, one of the features we're actively working on is to launch an even more robust development experience including dev/sandboxing/prod environments. 

Let's connect: https://www.linkedin.com/in/lukesummerfield/
rohansdeeson
Top Contributor

[Closed] CMS Hub Ask Me Anything (April 5)

Hi Luke the developer sandbox doesn't really cut it, there is no way to work on membership features in the sandbox, or video and there is no way to automate content migration from a sandbox to a live portal. 

lukesummerfield
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

Thanks for clarifying @rohansdeeson - We have work to be done here to make this smoother.
Sounds like this is a website being built onto an existing HubSpot portal?

As mentioned in our CMS Hub Public Roadmap, we are actively working on a true dev/sandbox/prod environments for developers that can be added to a portal. This will allow you to fully build the website in a staging environment on an existing portal while being able to take advantage of that portal's data, assets, etc. 

We do not have a release date set at this time but it's actively being coded. I would recommend following our Developer Changelog and product blog for beta and release notifications. 


In the meantime, I would recommend: 

  • If it's a new-to-HubSpot customer, start with the existing Developer sandbox and add any additional Hubs onto that. 
  • If it's an existing HubSpot customer, contact your HubSpot rep to add a CMS Pro/Ent trial onto the existing portal and then ask them to extend the trial. It's not uncommon trials are extended 60, 90, even 120 days for these types of situations. 
Let's connect: https://www.linkedin.com/in/lukesummerfield/
Jake_Lett
Guide | Partner
Guide | Partner

[Closed] CMS Hub Ask Me Anything (April 5)

For an existing customer, what is the preferred way to convert a site built with drag and drop templates to a theme?

cathalhopper
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

Hey @Jake_Lett !
Good question! We have a guide that walks through creating themes and converting your drag and drop templates to HTML/HubL which is required for themes templates - you can view that here: https://developers.hubspot.com/docs/cms/guides/add-theme-features-to-existing-sites

Once that is done, if you have access to content staging you could make use of content staging to stage your pages and transfer them across to the new templates that way!

This would be the best way to convert your current templates from drag and drop to Themes!

Thank you 🙂
Cathal

bendonahower
Guide | Diamond Partner
Guide | Diamond Partner

[Closed] CMS Hub Ask Me Anything (April 5)

When do visitors see personalized content? When might someone who is in the contact database not see personalized content? 

Ben Donahowers HubSpot community signature
cathalhopper
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

Hey @bendonahower !
Great question! Visitors will see personalized content anywhere it is shown provided they have taken an action to link their current cookies in browser to their contact record and is a tracked visitor.

For example this could be through a form submission or clicking a tracked link in a marketing email which lands on your HubSpot site!

 

By the same virture a contact will not see any personalized content on your site if they:
 - Have not taken an action to link their contact record and cookies

 - Or they have but are blocking or clearing their cookies

They may have something in place which refreshes their cookies regularly, a common example of this is incognito which, unless set to do so, will refresh your cookies with each new browsing session.

Another example you may see is of a contact that you have created manually in your database, and has not yet submitted on a form with their email - even if they are browsing your site we can't tell which visitor's cookies is linked to this email so they won't see personalized content!

Once a contact makes an action to link those though they will see personalized content from there!

bendonahower
Guide | Diamond Partner
Guide | Diamond Partner

[Closed] CMS Hub Ask Me Anything (April 5)

What are the most common things that slow down a HubSpot CMS site? 

Ben Donahowers HubSpot community signature
lukesummerfield
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

Agree with Patrick's response - wanted to also drop in this developer resource to help, "Optimizing your CMS Hub site for performance".

Let's connect: https://www.linkedin.com/in/lukesummerfield/
PatrickEng
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

Hey @bendonahower , awesome question that I think could have tons of different answers!

 

Generally speaking, the biggest culprits to look out for when it comes to slowing down website page load time are going to be:

  1. Oversized Images or unoptimized image types
  2. Bloated or uncessary CSS or JS, jQuery files
  3. General overuse of loading assets in the Head HTML when not needed

For example, using SVG images are great for both qulaity and scalaibility. PNG's, while great for transparency, are notoriously bulky image files. Hosting on the HubSpot CMS also leverages other page speed tools like automatic file minification and loading assets over a Content Delivery Network (CDN). Something like implementing lazy loading is also a great way to serve up images on your site without sacrificing load times.

 

For those interested in learning how else HubSpot can help decrease load times, we have a great checklist of things you can do!

bendonahower
Guide | Diamond Partner
Guide | Diamond Partner

[Closed] CMS Hub Ask Me Anything (April 5)

What is on the CMS's roadmap that you are most excited about (and can share)?

Ben Donahowers HubSpot community signature
lukesummerfield
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

Last week we updated our public roadmaps - I'd encourage everyone to check out the CMS Hub one. 

In general, I'm most excited about the work we're doing to bring the POWER of CMS+CRM together. 
Today we see this in our "Smart Content" feature, but this is just the tip of the iceberg of what's possible... the team has a big vision here. 
What's New in HubSpot's Software 2021-04-06 09-54-43.png

More tangibly, I'll give you two ... 
1) Smart Content in Custom Modules - LONG time requested feature is in beta and rolling out to all soon. 

2) Content Decoupling - Although still being planned, the vision here is magical. It brings the power to developers to extend content across the web, while keeping the marketer management/creation experience uber-user friendly (this is where traditional headless CMSes fall flat). 
What's New in HubSpot's Software 2021-04-06 09-54-13.png

Let's connect: https://www.linkedin.com/in/lukesummerfield/
jmclaren
HubSpot Employee
HubSpot Employee

[Closed] CMS Hub Ask Me Anything (April 5)

Hey Ben,

I love this question, 

We're very passionate about the content creator experience and enabling content creators to do more and more efficientlly. We believe the developer and content creator experience should complement each other. We're working to bring even more power to both developers and content creators in ways that balance power and flexibility for both types of user.

You've seen lately we've been rolling out a lot of updates to show the power of having your CMS be an extension of your CRM.  CRM objects in the CMS, smart content for all modules, memberships... I think we might have the first CRM that your customer's actually can log into, interact with your business, and you can build deeply tailored experiences for them because of it. There's some serious power in that, the future of that connection is very very exciting.

When it comes to developers specifically, a big focus for us right now is really nailing the CMS development workflow. We want every step of the process to feel smooth from starting a new project to going live with a new website. We have multiple angles we're tackling this from and are very excited about it, some pieces you will see in the short term, and some longer term.

There has never been a better time to be a HubSpot developer.

Jon McLaren

Sr. CMS Developer Advocate

Get started developing on the HubSpot CMS Developer Changelog
How to optimize your CMS Hub site for speed

If my reply answered your question, please mark it as a solution, to make it easier for others to find.