Best practices for multi-brand site

Pages
1

I’m creating a Pages site that will be used for 2 domains in one account, both with the same page sections, the only differences being branding colors and header/footer. The entities for both domains are all Location type.
I can create saved filters for the locations that will appear in each domain. What would be the best way to set up the stream in the repository so that only the intended set of entities gets published for each site?

2

Hello @Michael_Woon1

Since location entity you are using, you must have same stream for both domains.
It should be fine using individual saved filters only and you also will be able to use stream for controlling the information that you want to display on respective page as per need.
The saved filters you can create having a field which can be filled with brand/domain name. In content you can manage it using Folders

If there is any other use case that need to consider here, feel free to share.

3

Hi Tosh!

Thanks for the quick response. Since I will have to use the same stream for both domains, is there a way to prevent an entity from having a page generated on both domains?
Example: EntityBrandA is in the locations saved filter, and I would like to only generate a page for DomainA. But if the same saved filter and repo are used on both DomainA and DomainB, will a page for that entity be generated on both?

5

Hi Michael,

Is there any specific use case to consider using same repo for both domains.?

Because, It should be 2 different repo individual for each domain for performing actions like:

  • You will be able to perform the needed branding changes.
  • Entities will be segregated using saved filters and Managed via folder facility on platform.
  • Streams will be independent for each domain. So while generating pages, only those entities would be processed that comes under the saved filters.

Hope it helps.

6

I had thought of using the same repo for both domains since the pages will look very similar, having the same page sections. If there is no way to prevent entities from being published on both, then I’ll have to make a copy of the repo and use it for the second domain.

7

Thank you for Sharing the information @Michael_Woon1

Since both domains would have differences in branding including colors Header and footers, use of individuals repo would be the recommended solution to proceed with since that will also let to make branding changes easily. On other hand, use of different streams with individual repo will solve the page generations concern.

8

Here’s how our starter’s organized, the entry point in src/templates: pages-starter-react-consulting/src/templates/entity.tsx at main · yextconsulting/pages-starter-react-consulting · GitHub builds the stream config using a function imported from src/layouts: pages-starter-react-consulting/src/layouts/entity/configBuilder.tsx at main · yextconsulting/pages-starter-react-consulting · GitHub.

To support multibrand you can copy the entry point file into subfolders for your brand (src/templates/www.brand1.com/entity.tsx, src/templates/www.brand2.com/entity.tsx for example) and pass a different argument to the configBuilder function to control the scope of the stream for that brand. You could hardcode the appropriate filters in the entry points or you could have them come from a site environment variable in the account.

9

Hi Michael, this is something that’s both possible and recommended to manage within one repo if only small amount numbers of assets and templates are changing between your implementations. Ben gave some good examples but I want to expand a bit more on his answer.

There are two main ways that this can be accompanied: environment variables and sub-foldering. We have some documentation here which describes the two approaches however do note that it uses the pre-1.0.0 Pages configuration in its examples so there may be some differences. We will be working to update that documentation to include 1.0.0 examples as well.

Using environment variables is the recommended initial approach as it is the simplest. All that would be need to be done would be to configure your two saved filters in the platform and set them as environment variables on your site. Any assets or template differences would need to be configured based on additional environment variables.

If there are significant differences in templates across your implementations then subfoldering your templates by domain in the way that Ben described above provides more flexibility at the cost of a more complex directory structure within the repository.

Please let me know if you have any additional questions here and I’d be happy to expand on either option.

1 Like
10

Thanks for all the options guys! Another related question - I’d like to have separate directories for each saved filter, when running the directory manager can I use the same state/city/root entity types or do I have to make new ones for the second directory?

I can change the base entities in the directory manager using the savedFilterId, but if they all use the same cities and states that might cause issues

11

Separate DMs will create separate DM entities, even if both are e.g. “Virginia”. You can reuse the same entity types. Just note that if a base entity ends up in both DM sets, that will causes issues as we don’t currently support overlapping directories.

2 Likes