CMS Hub: Lunch, Learn, and AMA for Developers

Welcome everyone, to the CMS Hub Developer Lunch. Learn and ask us anything. We're really excited to get started. We're trying to do more of these touch points with our developer community, and we're really excited that you've taken the time out of your busy days to spend some time with us and learn a little bit more about the CMS developer experience at HubSpot. So, without further ado, I'll go to our agenda. For the first few minutes, we'll just be doing some HubSpotter intros and we'll walk you through a little bit of housekeeping. We have some great REACT boilerplate demo as well as some exciting developer news that's coming up right after that. Then we're going to go into some of your submitted questions. So thanks to all of you who submitted questions in advance. And then we're going to block off the last 10 minutes for live questions. So first things first. As you all are aware, we are recording, so just keep that in mind. We encourage you to actively use the chat tool within Zoom Webinar to connect with your peers. If you have direct questions for us for the live Q and A period, please use the Q and A tool at the bottom of your screen and we'll be able to ask those questions live and of course in chat and in your questions. Just be awesome, be cool, be kind, as you all are, and we're going to make this a really fun 45 minutes. Before we jump in to these two awesome talks that we're going to get, I would love us to spend spend some time doing a little introductions of the hubspotters that are on the call right now. So I'll kick it off and I'll kind of nominate folks as I go. I am S.J. morris. That's S.J. stands for Sarah Jane. I lead our developer programs and a lot of our developer community initiatives. And I'm gonna be your host for this event and I will hand it over to Will Spiro.

Cool. Hello everybody. My name's Will Spiro. I'm the Product manager here at HubSpot who works on a few of the teams that build out the tools for CMS developers. So thank you all for joining and looking forward to talking more.

Thanks. How about Will Murray, you jump in now.

Sure. Hi everyone, my name is Will Murray. I'm another Will on the CMS developer team. I work as a product designer and I'm looking forward to presenting some updates today.

How about you, Gregory?

Hi, everyone. Greg. I'm Gregory, musician turned developer turned Engineer. And yeah, I'm going to share some cool stuff.

We have AJ.

Hey, I'm AJ.

I am a developer advocate here on HubSpot's team and you guys have probably seen me in the slack a lot of times if you're on the developer slack.

All right, Matt Coley Hi, I'm Matt.

I'm the tech lead on the CMS Developer Infrastructure team. Everything that I touches, the Design Manager.

Awesome. John.

Hi, I'm John and I'm one of our CMS Developer advocates. I work a lot on our documentation.

And tutorials and we can see Micah's handsome picture there lurking. But I think we're gonna leave him on the down low for now just because he's watching our audience come in and things like that and less of a question response panelist role there. All right, so I'm going to kick off with the demo and some exciting stuff from both Will and Gregory. I will stop sharing my screen now and hand it over to you, Will.

Awesome. All right, well, good afternoon everyone. As I mentioned earlier, my name is William Murray. I'm product designer on the CMS Developer Experience team. And today I'm going to cover a few updates that are available today or coming soon, and I hope you're excited to hear about them. For starters, we'll be listing themes in the HubSpot asset marketplace beginning on June 1st. And filling the Marketplace with artfully crafted themes will ensure that CMS Hub customers building websites using Marketplace assets have the best experience. So if you want to build a theme for a marketplace, we encourage you to review the updated requirements and ensure that your submission meets them. And speaking of new themes, we'll soon be adding the ability to create a theme in the Design Manager. You'll have the option to start with a blank theme that contains all of the required JSON files, or you can use the boilerplate theme as a starting point. And the boilerplate theme really represents our recommended best practices for themes. And it meets all the requirements I mentioned for Marketplace theme submissions, so it's well worth a look. I'd also like to note that in the same vein, we're working to bring the ability to create serverless functions to Design Manager. We'll have more info on that in the future. That's not all we're bringing Design Manager. You'll soon be able to view and clone all the default modules and HubSpot themes via new HubSpot folder, so there's no more searching for modules by name. To reveal them in the finder would be just a Few clicks away. The boilerplate theme isn't the only open source project we've been working on either. The new event registration app uses all the CMS Hub's latest features to bring event registration functionality to your website. And you can check it out at the GitHub repo link. Another open source project I'd like to introduce today is the CMS React boilerplate app. This project will build an app for modules on CMS Hub. I'll turn things over to Gregory now for a quick demo.

All right, I hope everyone is doing well now. It's some demo time, which I always love, to be honest with you. I think I'm more excited right now than I've been and maybe at least a month. So yeah, so with that let's get started here. So with the launch of CMS Hub and over the course of the last year we've been working really hard to create a really great local development experience. And one of the reasons for that is so that we can, so that you, those providers, developer community can take advantage of the rich ecosystem that's available to us as web developers and front end developers. And you know, one of the hot libraries that has lots of traction is React. And so we've been playing around with that internally and I thought it would be cool to share a little boilerplate so that others can quickly spin up a little React app and use that inside of your CMS website. So yeah, let's do that right now. So the CLI has this Create command and you know, we've added a new feature. So if you update to the latest version of cli, you'll have this, you can do HS Create React app and today we're going to create a little TO DOS app to do zap. And the React world is kind of like the hello world of React. So I'm going to go ahead and run that. It's going to go ahead and create a project here and I'm going to go ahead and just open that project in my favorite editor, which happens to be bim, longtime user. Okay. So yeah, so this looks like a pretty standard front end project. It has a package JSON that has its dependencies. We're using webpack to build the project. I need to install those dependencies. I'm going to run YARN Install, which is very similar to NPM install and it's going to go ahead and install those dependencies. While that's happening, we're going to go ahead and start making some modifications to the boilerplate to build this to and unfortunately I'm going to do these modifications pretty fast and not go into the super fine points of it because we have limited time and I want to make sure we have plenty of time for all of your questions. So to start off, I need to rename some stuff because I'm building a to DOS app, not a little boilerplate app here. So I'm going to change the the names of the files that I'm creating and the destination of the files in the Design Manager here to DOS app. So this is going to upload all the files to the TODOS app directory in the Design manager and I'm going to be creating a Todos app, JavaScript file and CSS file. OK. Inside of this boilerplate, we're focusing on modules at this stage, but you can use it for other things as well. It comes with just a simple little module here and I'm just going to tweak it a little bit. I'm going to rename the module folder to TODOS app because that's what this is. I'm going to go in and modify the label of the module. So one of the features that we've added is the ability when you're working locally with building out a modules to have a label which is shown in the page editor and elsewhere that is distinct from the name of the folder. Just makes things better, basically. So we'll do that. Then we're going to go into module HTML, which has our HTML and Hubble and rename the two require calls here that are bringing in our CSS and JavaScript. Yeah, and so at this point I'm sure that we're done installing all of our dependencies and we're ready to start really coding this to DOS app and get it into HubSpot. So in the package JSON there's a start script that's going to build the project using webpack and once everything's built, it's going to automatically upload the files that are built up into HubSpot. So at this point it's building the project and uploaded everything into HubSpot. I can go into the Design Manager and the. Oh yep, I have my TODO stash app CSS to do stash app js. I have my module. I can also just go ahead here, go ahead and lock this folder so that other folks know that really this is something that is being built outside of HubSpot and pushed in. So we have that there. Now let's go ahead and use that module. So we'll create a page using one of the default themes that come with CMS Hub. I'm a pretty big fan of Vitality, so we'll go with that. And we're going to call this page to dos. Okay. So all of the default themes are make heavy use of drag and drop areas, which create a drag and drop page building experience. Very key feature of CMS Hub and themes. And so we're going to go ahead and take advantage of that. We're cleared out. We're going to find our TO DOS app. This module we have, we're going to drop it in here and voila, we have this little React app that's been inserted, that's bundled up into a module and available for someone to put onto a page in HubSpot. And yeah, it's running, but that doesn't look at all like a TO DOS app, so let's change that now. Okay, so we'll flip back over to the editor here and at this point I want to edit my React app and the CSS that's involved there. And to do so, I'm not going to write all this code on the fly. I'm going to take advantage of having written it beforehand and doing a lot of copy and paste. We'll take our app js, which is the main React component that has our app, and we'll replace that with a version that does this little TO DOS thing. I also need a to do component here, so we'll grab that. And you know, every time I am saving and whatnot, it's automatically rebuilding the project. There's probably some errors because I don't have all the pieces I need just yet, but that's just happening in the background. I'm not even thinking about it. So I got that. Ok. And then the last piece is I need some CSS or sass. Whoops. Okay, and boom, boom, we got that. So at this point we'll flip back over the terminal, make sure everything's built. Yep, we've built this thing out, it's been automatically uploaded. I can reload that. And we got a little to do. Zap inside of a page here. Let's just flip over to the preview here and try it out. Finish my demo. Be happy to click complete on that one. Demos are stressful anyway. At that point I've got this React project. I'm able to use React, I can pull in other libraries. There's all kinds of cool stuff that I can do. And I can create modules that then integrate with the rest of the CMS in a seamless way. I think that that's pretty cool. One thing we really want to better understand are what are the recipes that will be helpful for you. We want to be able to help all of the developers get up and running with the projects that they're looking to build on the CMS as fast as possible and also continue to increase the capabilities. At this point, this isn't saving the data anywhere. If you are using CMS Hub Enterprise, you could save the data using serverless functions and save it into Hub DB or even some third party service that will allow you to save the data and then we could really retrieve it and pull it in. There's really so many possibilities here and we want to make sure that. Yeah. Help you achieve those. So this is an open source project in terms of the code, both the code and the CLI by the way, and the Webpack plugin. So feel free to check them out. If you hit issues or whatnot, you can open issues. Yeah, so that's my demo. Sorry it was so fast, but we really wanted to make sure that there was plenty of time for questions.

Thank you so much Gregory. That was awesome. Definitely check out the chat. People seem to be really excited, so that was fantastic. So we're going to jump into the questions portion now. So as I mentioned earlier, a bunch of you sent in some fantastic questions. So we're to going going to start in with some of those pre submitted questions and then we'll move to the live portion. So we're going to start with the first question and Spyro, we'll hand this one over to you. How do I get started with theme? Local development Themes and local development.

Yeah, great question. So I know a lot of developers are hearing a lot about themes and the new local development tools and we wanted to make a really easy way to get started with all of it. So we built a brand new getting started guide that gets you up and running with the new local development tooling. It scaffolds out a boilerplate theme based off of the open source theme boilerplate and then gets that uploaded into a CMS developer sandbox account or an existing CMS account if you already have one. So I would definitely recommend going through that quick start guide. It only takes about five minutes to get up and running with the CLI themes and the boilerplate and it will give you a great taste of how you can get started with these new concepts and then also a great jumping off point for extending the theme to actually meet the requirements of a project you're working on. So definitely check out that Getting Started tutorial. I think John and AJ just sent it out in the chat there, but that's definitely the best place to get started.

Yeah, it was posted in the chat. We're definitely going to send this to all of you via email as well. Next question. Also for you, Will, when can we expect smart content and custom modules? Personalization is a huge reason people love the cms, but you can't harness its full potential when you can't use it in custom modules.

Yeah, this is a great question. I also wanted to say thank you to everyone for the persistence on this question. I think people have been asking this question at every single developer event for the past few years, and it's probably the number one idea on the Ideas forum right now for CMS development. And probably for the first time, I'm really excited to tell you all that this is actually something we're actively working on. We heard you. We've been hearing you for the past few years and it's finally something that we are prioritizing. And the team that works on building the content editors have finalized all the designs for it, and now they're actually working sort of on the implementation phase of adding this in. So while I don't have an exact timeframe for you all, I will let you know that this is actively being worked on and I hope very soon we can start to deliver that to you all and your customers. So thanks for the persistence and keeping letting us know that you wanted it. We heard it and now we're working on it.

Awesome. Thanks, Will. Third question. Is there any chance of allowing Hubble to be used in CSS or JS sections of modules? This would be useful. Matt Coley, do you want to jump in?

Yeah, this is a great question. I actually had the same question when I joined the developer infrastructure team about a year and a half ago, and the answer is a little bit more subtle than I initially realized. So it all comes back to how HubSpot optimizes your assets in the CMS. If we look at regular JS and CSS files, when you publish changes to those, we kick off a process that reinterprets the Hubble and then uploads those files to the cdn that allows these files to be cached and served efficiently using newer technologies such as HTTP 2. Now, when we look at like module JS and CS, the same thing happens when you publish a change to the content there we do the same thing where we interpret the Hubble and then statically push that up to the cdn. What that means is that JS or CSS has to be applicable across all module instantations. So even if the HTML of the module changes based on the fields of the module, the CSS and JS is just one file that's uploaded to the cdn. When we talk about using Hubble within css, there's sort of two use cases that I see. One is generating CSS and the other one is using module fields in css. Because of the static generation, it's not really possible to use module fields directly in css. But I definitely think it's possible that in the future we would allow you to use Hubble to generate CSS more efficiently using things like variables that aren't natively included. Hubble provides a lot more additional functionality than is natively available in css. So we could see you being able to use Hubble to generate CSS, but not necessarily be able to use module fields directly in the module css.

Great. Thank you so much. Next question. I think I'll let John McLaren answer this one. Can you please elaborate on the limitations on using the new features and themes, such as drag and drop areas? For example, I would like to see why we should still evaluate custom module development to have a module in two columns rather than making it possible by drag and drop. How about the existing sites?

The new D and D area feature makes it so you can empower the marketer to create tons of layouts. So one way that I kind of think of it is there's kind of this. I don't mean to coin a term, but sometimes people build what are what I would call super modules, where they make a module that has a lot of features and a lot of options and can create a bunch of layouts. And that might be good for a certain customer and a certain user, like end user. But at other times it may make sense to make smaller modules that then the marketer and the end user can then rearrange and create sections that create a styled appearance for them through the drag and drop editor. The difference between D and D and flexible columns, which is also sort of hinted. This question is that instead of it being a one directional vertical positioning of these modules in a flex column with drag and drop areas, they actually have horizontal control. They can make a module take up two columns and another module next to it take up multiple columns. So really it depends on what the requirements for your project are as to whether you should go the route of having a bigger module that should be, say, full width and has a lot of options or if it makes more sense to build smaller chunks that can then be rearranged and duplicated by the marketer to create dozens of extra layouts that you couldn't offend already do without a lot of extra pre preparation and development.

Thanks, John. Question 5 I think we'll give this one to Gregory. Are there any cookbook projects that we can mess around with to get a code base of a practical application?

Yes. So when it comes to the practical application cookbook project, I think that the best one we have right now is this event registration app. And you know, the idea of the event registration app is that it pulls together all the key features of CMS Hub Enterprise. It takes advantage of serverless functions and the ability to use serverless functions to write data back to HubDB. It takes advantage of HubDB for storing all of the events that you want to display on a website. It takes advantage of memberships to create a private area to be able to give customers the ability to see events that they've registered to attend. And then it also takes advantage of our local development workflow. And so I think it's a good example of all of these things kind of coming together and building a project. We also all of the default themes are available to check out, so if you go into the Developer Docs website, there's a section on the default themes that has information on how to pull them down using the cli. And those are also really interesting to take a look at. But I think that we're just getting started as far as these kinds of projects go. So we're definitely interested in hearing what kinds of things would be helpful for folks so that we can. Yeah. Help everyone get a head start.

Yeah, great, thanks. Sixth question, I think we'll give this one to Will Again, it would be very beneficial to set custom options and styles in drag and drop sections. For example, a Boolean that can allow you to add an anchor link, etc. Is this in the cards?

Yeah. This is a really great question and I think someone in the Q and A section asks something very similar. So yeah, we. For those of you who don't know what this is talking about, we recently introduced the new D and D area Hubble syntax. Maybe John or AJ could share out a link to that. And it's a new syntax that supports the sort of brand new page editing experience that allows marketers and content creators to make layout and style and content tweaks all within the content editor and bring that drag and drop layer right to the Page editor. And one of the elements in that new system is a concept called sections. And a lot of developers have been expressing the need to be able to put more customization into sections, such as adding fields for sections or classes or IDs to sections. And this is definitely something that we're actively thinking about. So we've been thinking about this concept of pre built sections as part of the building blocks on the cms. So something sort of in between modules and templates where a developer could pre configure a series of modules and you know, some D and D area syntax to basically pre configure this full width section of a page like a hero section or a form section. And similar to modules, these pre built sections could also have fields that go along with them and any specific configurations that a developer might want to add to that section. So this is something that we're thinking about. I'd love to continue to hear about all of the use cases you'd like us to cover. We're definitely going to continue to flesh out the D and D area Hubble syntax and sort of the various building blocks that go along with it. So definitely continue to share your use cases and what you'd like to see out of that. But this is definitely something we're actively thinking about to try and see how we can make things more powerful developers and ultimately allow you to create the design system that you all want to create for the content creators you're building for.

Awesome. Next question. We've got a bunch of legacy templates in various states from various design manager revisions over the years. What is the migration story for CMS Hub? John, do you want to take that one?

Sure. So when it comes to themes, all of the functionality is additive, so the themes is a package concept which ends up permeating. When you're creating a new page. It'll show up as a. You pick a theme and then you pick the template that you're creating. That sort of functionality is added when you add the theme JSON and fields JSON to a folder which then creates a theme when you want to do things like adding theme fields themselves. If you are upgrading old website that's pre existing, you may not need to go super in depth with theme fields. This will depend on your project. But what I'm meaning with that is say you you already built a website and it's all styled up exactly to the brand standards of that company, then you probably don't really need the fields for changing colors or fonts, but you can add Them if you want them, and then global partials. Global partials are huge. So the concept of go partials is that when a content creator is in the content editor or page editor, they can actually hover over say your header, your footer, or like a sidebar, these areas that are used globally throughout a website. And then when they hover over it, it'll say, hey, this is a global piece of content. They can click it and then they can edit that portion and they are made aware that those changes will affect the rest of the website. When it comes to drag and drop areas, again, this is an additive sort of feature, so you can create new templates that utilize D and D areas. You can also clone an existing. If you had old drag and drop area templates. Sorry, old drag and drop design manager templates, you can clone those as HTML and create D and D areas in them that way. There's some documentation on our D and D areas page about doing that. Yeah, I think I've covered almost everything. Feel free to chime in if anyone caught anything.

I didn't anyone. I think that was pretty thorough. John, thank you so much. This is the last submitted question and then we're going to open up to live questions. I see there's a bunch coming in, so we'll try to get to them all. Final question. Is there any consideration for two way sync instead of just uploading changes used in Watch? This could be especially useful when a field is added to a module in the cms. The meta JSON and fields JSON do not update update locally. This will cause issues. You do not fetch your changes periodically. If not, is it safe to fetch your entire project before continuing local development? Believe Gregory, you wanted to answer this one?

Sure, yeah, sorry. I was in the process of answering one of the QA questions. Yeah, so it's a good question because, you know, at this stage we were really focused on a, essentially the local first experience where all of your code, your source of truth for your code, is your local computer or a version control system. If you're collaborating and making sure that work, I think over time it does make sense for us to expand the sophistication of that local development set of tooling and provide more sophisticated synchronization between your machine and HubSpot. The thing that we just have to keep in mind though is that like not everyone is working for a company where there's only like one developer working on the files. And so, you know, if you are in a situation like that, it can be useful to use Source control as a mechanism for collaboration and exploring.

All right, thanks. So we're going to hand it over now to Live Questions. So there were a few that came in earlier. We'll start with the first one from Larry Barker. How are we handling staging and production environments? Does anyone want to jump in?

Yeah, I can talk about this. I see there's like a duplicate question below asking about test in dev environments. So right now the only real way to stage changes is using the buffer and then you have to deploy out each buffer change individually. What my team has been looking into is the ability to provide like a QA or a test or a dev environment and then be able to atomically deploy all those assets between environments. So this is something we've been thinking about for a long time and we're continuing, continuing work on that. But we definitely recognize the need to be able to push your changes up to HubSpot and not affect any live content and be able to view and validate those changes before those go live. And when they do go live, you should be able to push them all live at the same time as well as be able to roll back any changes just in case anything goes wrong. So we've been thinking a lot about this problem and have been working towards that, making that a lot better.

And just one other thing that I'll add that quite a few developers do and even some internal web development teams that HubSpot do is they use the CMS developer sandbox accounts as sort of staging environments. So the CMS CLI makes it really easy to send your local code to different HubSpot accounts. And with everything being sort of path based references, it's really easy to ship code between multiple accounts and developers can have as many, or each developer could have their own sandbox account as sort of a staging environment. And then some teams of web developers will keep sort of a master in source control and then don't ever make changes actually in the live production portal, they'll set up continuous integration with a GitHub repository. So basically master as what's live on a website.

Awesome, thanks. Next question is From Randy Milanovic. HubSpot sites tend to load a lot of scripts that slow page loads and can have short header expires. Is there a way we can speed this up and extend expire times?

Yeah, unfortunately you don't have engineers that specifically work on site speed improvements here. So I'm not entirely sure what our caching policy on default assets are, and it's hard to tell because there's so Many different places that you could potentially include a script on your page. It could be an external source, it could be from the file manager, it could be from the design manager. So I have to look more into that before responding.

Well, I will say that we did recently publish a post on our blog all about or on our developer blog all about site speed and page load time. So if one of someone on the panel can drop that link right now, that would be awesome. But feel free to check it out@developers HubSpot.com blog and it won't be too far down the page. Next question. And I see this one coming up a ton in the chat as well. I know we went through a react app boilerplate. Is there any plans in the works for Vue js?

So I can. I can take this one. One thing I saw in the chat, right, was there's a huge amount of interest in Vue and having essentially a boilerplate for Vue, and while it can make no promises, sounds like a really good idea. Right? So, yeah, so I think that's definitely something that I would add to our to do list.

Cool.

And I will say, you know, like, what we're trying to do is make it possible that you can. So that you can use really any library that you can when it comes to JavaScript and CSS and be able to use it effectively inside of the cms. And yeah, so, like, if there are stumbling blocks that you hit, like, those are things we want to be able to address.

Cool, thank you. Another great question came in from Christopher Mathieu and I said that correctly because I'm from Montreal. We're going to be switching out workflow to leverage themes soon. Seems great. From what I've seen, my main concern is manually generating JSON for feedback. How has this gone for people so far?

First of all, hey, Chris, I think if people, for, you know, folks who have been working with themes locally, why don't you post in chat? Sort of. If you have any suggestions for how to best approach that. For those of you who don't know, developing theme fields can currently only be done through a JSON file similar to the local module fields JSON file. We've definitely heard that this can sometimes feel a little bit cumbersome for developers who don't want to be working with the JSON files. So one suggestion that I have is definitely check out all the code is available for the default themes. So that's a good place to get started from if you're looking for some sort of boilerplate options to get started from and you could even develop your own boilerplate of fields that work really well for you all. But one of the things we're definitely going to be thinking about is how we can continue to make the local or file based approach to a lot of these new concepts as intuitive and easy to pick up and use as possible. So we're definitely going to continue to refine what the local development experience for modules looks like, the local development experience for themes looks like. So keep us posted on any ideas you have and we'll definitely be sharing any proof of concepts or thoughts that we have with you all just to make that as easy as possible.

Great. A question from Jamie Welch. Using themes or the new D and D editing experience, is it now possible to append another section to a webpage instead of having to create a separate template just to append another similar section? I find this is one of my largest templating limitations right now if I'm building from the design manager directly.

Yeah, this is a really great question. I think it's actually one of the best benefits of the new D and D area Hubble syntax. So one of the things that it opens up is sort of a one to many relationship from template to pages, as opposed to in the old world with drag and drop layouts, you sort of need to create a new drag and drop layout for a specific page you want to create. What's great now is you can basically have almost a header and footer and a drag and drop area body, and content creators and marketers can create any pages and layouts that they desire from that single template. So we're definitely moving towards a world where a single template can have a one to many relationship with the pages across your website. So I would definitely check out the brand new D and D area Hubble syntax. It sounds like it'd be great for sort of the pain point you're expressing there.

Great question from Daniel Rivera. Can we access Contact Properties using Hubble inside a React app module?

The answer is essentially yes. It's a little bit awkward, but it is possible. In fact, actually the React boilerplate has an example of how you can essentially serialize JSON, which then your React app can load and use. Yeah, so it is possible. It's a little bit awkward, but it's possible.

Okay, we only have a couple minutes left, so I'm just sort of sorting through if anyone on the panel sees any questions that we feel like would be really great to get to before the hour winds up. I know there's a Ton here. I'm going to go with George Thomas's question. Will we ever be able to add a CSS class or ID to a drag and drop section or column? It is a must for so many reasons.

Yeah, this is a good question. I think I touched on this a little bit earlier to a certain extent with this concept of reusable sections that developers create. One thing that I will note is you can add classes to the D and D area tag in the template, but I'm guessing this question might be a little bit more geared towards being able to do it in the editor, or something in the editor that allows marketers and content creators to add classes or specific sort of like chunks of css. Yeah, it looks like George confirmed that that's the case. Yeah, this is definitely something we're thinking about. You know, like I said, the reusable sections feature that we've been thinking a little bit about to a certain extent, I think addresses this a little bit where basically developers could add their own fields to this section sort of building blocks. But this is definitely an ongoing conversation we're having right now. We want to make sure that there's sort of parity between what developers can do and what marketers can do, and also want to make sure we don't introduce things to the page editor that might be confusing or aren't clear what a marketer should do with them. So we're definitely continuing to talk about this and flesh out exactly what the experience is going to look like for both developers and marketers. But let's definitely touch base. George, I'd love to hear more about your use case and hopefully we can continue to iterate on things and make it work for the use case there.

All right, thank you so much, Will. I know there was a ton more questions, and I'm really sorry that we didn't get a chance to get to all of them. We will be doing more of these, so please stay tuned to our blog. We'll be announcing future events there, as well as our developer newsletter that we're sending out monthly. We're still in pilot mode trying to sort of figure out the best modalities for these community events. So if you have any feedback on what you'd like us to provide for you, our community, we'd be more than happy to hear from you. You can email me directly, that's sjmorrishubspot.com or you can reply to, you know, participate in our Slack or forums. I've included some of those quick links here. We're gonna send out an email of the recording with all of the links that we referenced. And we really, really appreciate your time. Thank you so, so much for joining us today. And thank you to our panelists as well.