Switching HubSpot Themes: Module Reassignment Challenges

[Biancau]

Our company has revised our HubSpot workflow after discontinuing development in Umbraco and realizing that HubSpot lacks a robust beta → staging → live safe environment for updating modules. Our new approach involves maintaining duplicate themes—one for live use ("Theme Live") and one for staging ("Theme Staging"). We actively develop on the staging theme, using its templates and modules to create content staging pages. Once we’re satisfied with the result, we open a pull request from the staging branch to the main branch on GitHub. This triggers a GitHub action that removes all instances of " Staging" from the files using hs deploy, and then uploads the files to Theme Live with hs upload.

While this process works well overall, there remains a significant challenge: simply switching the theme template from Staging to Live and publishing the staging pages results in a live template that still references staging modules.

We explored several approaches to resolve this:

1. Bulk Updating via API:
   We attempted to use the API to update pages in bulk by identifying those with template paths starting with "Theme Live" and swapping their module IDs using data from a JSON file. Unfortunately, this method failed because the module_id property is read-only.

2. Cloning Pages via API:
   Next, we tried fetching the JSON for a content staging page and cloning it while omitting any read-only properties. The idea was that specifying the module name (e.g., "Hero") would allow the CMS to initialize the correct module with the provided inputs. However, this approach produced unexpected results: the edit page failed to load (this is not a one-time thing, all creations through this proccess cannot be edited in the page editor), and when published, the module selected wasn’t from Theme Live or Theme Staging but rather from a third in the protal —even though the content was correct.

Given these challenges, we’re looking for suggestions on how to:

• Specifically target a desired theme for the modules, or
• Implement an alternative method to switch a page from one theme to another, ensuring that the modules (assuming the new theme has an identical variant in terms of fields) are sourced from the new theme.

Any insights or solutions would be greatly appreciated.

[Anton · Accepted solution]

Hi @Biancau, 

from personal experience I can say, that relaunching a page without the content staging function in HS can get out of control real quick. Since you will end up with quite a few road blocks like "weird" URLs, at least double the amount of pages in the (landing) pages list and in worst case an almost not hadlable workflow(you have to rename the new pages, you have to keep track of already finialized transfers somewhere like Google sheets/Excel...) 

My recommendation:

1. Clone all pages you'd like to "redesign" to the Content Staging
2. Change the templates from "Theme Live" to "Theme Staging" of every page in the staging
3. Develop your Staging theme
4. Once a page is ready, publish it in the staging environment
5. Once all pages are published, replace existing ones with the staged ones. 

AFAIK, there's no Content Staging API, so (content) changes to the pages would need to be done manually.

Also - unless it's the exact same module, HS most likely won't match the content while switching themes. So I'd recommend to try clonding the module from "Theme Live" to "Theme Staging" and see if this works. If so - great, but for the best/cleanest result, I'd do it manually. 

Another options for handling content without relying on modules/themes could be:

- creating HubDBs for storing content and "calling" it from specific modules

- creating vars files(can be html with {% set XYZ %}, JSON...) and select the content from specific modules. 

hope this helps

best, 

Anton

[Biancau]

Hello Anton!
We're totally fine using content staging, but it seems as if I'm either missing something or content staging is lacking. We used content staging for our last redesign  and I ended up having to do double workload - I created the pages as they would be with the staging theme, set up with the modules from staging theme to ensure the design matched the specifications and got them approved. When we were ready to go live, i changed the theme to live theme and then I had to replace the content of the page with identical modules that were now available with the new theme. This had to happen before we uploaded the staging changes to live (because we wanted the global module changes to go live at the same time as a domain change, at which point the content staging needed to be complete). Given that the modules ARE in fact identical, I sort of expect HubSpot to have figured out a method to do this without all the manual labour, or at least take it as a suggestion to update their CMS to be halfway decent for redesigning larger webs.
Thank you for your suggestion though. I think you're right in that there's no content API that can handle this sort of thing, but the only thing I'd actually need is for the pages API to accept a theme input to select its modules from, in which scenario i could run the API to clone the staged pages with a different theme but the same content. This does require the modules to have the same field names (or for the API post to have updated field names where applicable), but given how we work with our themes this is a non-issue. Live will be identical to staging when it comes to modules at the point of cloning. 

[Jnix284 · Accepted solution]

@Biancau if you built all of your pages in Content Staging using the new theme and published them to staging, all you would have needed to do is the final publish via content staging for the staged pages to replace the live pages.  Maybe I've misread something, but you shouldn't have had to replace modules if you "staged with blank page" and used the new theme/modules to recreate the content. If you used a clone of the existing page, then yes, you'd be using the old modules and each would need to be replaced on the page.

[Anton · Accepted solution]

Hi @Biancau, 

from personal experience I can say, that relaunching a page without the content staging function in HS can get out of control real quick. Since you will end up with quite a few road blocks like "weird" URLs, at least double the amount of pages in the (landing) pages list and in worst case an almost not hadlable workflow(you have to rename the new pages, you have to keep track of already finialized transfers somewhere like Google sheets/Excel...) 

My recommendation:

1. Clone all pages you'd like to "redesign" to the Content Staging
2. Change the templates from "Theme Live" to "Theme Staging" of every page in the staging
3. Develop your Staging theme
4. Once a page is ready, publish it in the staging environment
5. Once all pages are published, replace existing ones with the staged ones. 

AFAIK, there's no Content Staging API, so (content) changes to the pages would need to be done manually.

Also - unless it's the exact same module, HS most likely won't match the content while switching themes. So I'd recommend to try clonding the module from "Theme Live" to "Theme Staging" and see if this works. If so - great, but for the best/cleanest result, I'd do it manually. 

Another options for handling content without relying on modules/themes could be:

- creating HubDBs for storing content and "calling" it from specific modules

- creating vars files(can be html with {% set XYZ %}, JSON...) and select the content from specific modules. 

hope this helps

best, 

Anton