Multiple Sites Sharing Pages/Posts

Communities ContentBox CMS
1

I’m working on a new ContentBox CMS project where I will have multiple sites. Initially there will be just one, but when we start adding “child” sites I would like them to be able to share some of the content from the main site. So, if I have some info pages, call them Info 1 and Info 2 and Info 3 on the main site, and Info 1 & Info 2 pertain to the child site, I’d like to be able to have them show up there as well without having to duplicate them.

Currently, if I set up another site, a page I create on the main site doesn’t show up on the other site.

Is there a good solution to this? Or am I going to need to do something manually when rendering the menu and not include the site in finding the published content:

pageRecords = pageService.findPublishedContent(
parent : “”,
showInMenu: true,
properties: “contentID,slug,title,numberOfChildren”,
sortOrder : “order ASC, publishedDate ASC”
) />

The built in one looks like this:

pageRecords = pageService.findPublishedContent(
parent : “”,
showInMenu: true,
siteID : site().getsiteID(),
properties: “contentID,slug,title,numberOfChildren”,
sortOrder : “order ASC, publishedDate ASC”
);

2

Hi @reynacho

This is a good use case. Right now the hierarchy is flat. Meaning the multi-sites are completely isolated from each other. There is no concept of child parent sites.

However, I think we might want to explore this capability and maybe brainstorm a solution here.

Some questions and thoughts:

  • If we go down a route of child-parent, do we do just one level, or a completely hierarchical tree? If we do, then this really complicates the entire approach to content, since we have to be constantly getting content from the parents all the way to the root node. Doable, but not sure if it’s worth the squeeze.
  • Introduce a new content store type that can be globally accessible. This basically means updating the contentstores to be optionally attached to a site. This would allow a separation of site based content store and a global content store.
  • You can’t do that with pages, because pages are rooted on a site map and automatically available to a site. Content Store is really a detached piece of content.
  • Not only is it content, but also menus, which can be encapsulated at a site level.
  • Another option could be just one level of hierarchy. Meaning, you can create top-level separation of sites, and then just do sub-sites. But then we would have to establish the rules of engagement for a sub-site.

Comments, suggestions, thoughts?

3

I should preface all this by saying that this is my first ContentBox site. I used to do CMS Stuff with Farcry CMS a while back and I’ve used Coldbox for years on an admin toolkit mainly for MVC and Wirebox including ORM. So, I haven’t dug that deep into ContentBox stuff yet.

In my case, I don’t think a full parent-child relationship would be needed. To me that implies that we’d inherit more than content, but also layouts, theme settings, site settings, etc. I want to keep the sites separate still. They will have similar but different layouts, so if we use the same theme, I’ll make sure to have the ability to override a bunch of it in the theme settings.

I think what I was thinking more than anything is some kind of site-level categorization. For example, if Site 1 has an About Us page and a Contact Us page and Site 2 also has those, but the About Us is different, I don’t want to display both, just the relevant one, but Contact Us could be the same on both. So, using a site level selection, I would select Site 1 and create both the About Us and Contact Us pages. Then on the sidebar, we’d have related data similar to categories:

Site Selection

  • Site 1
  • Site 2

Site 1 would be pre-selected and probably grayed out because the page is being created on site 1 so obviously it would be available there. However, for the Contact Us page, I would also check “Site 2” indicating that 1 page is available on both. But then, in Site 2, I have to create that About Us page since it’s unique and then maybe I want a Gallery page. That would get created under Site 2 so would only be available there. So for the Menu:

Site 1:
Home | About Us | Contact Us

Site 2:
Home | About Us | Contact Us (from Site 1) | Gallery

Some gotchas right off would be anything looking at file system paths, for media, Content Store items, etc. If Contact Us had a nice image on the top, that image is stored in the content for Site 1 since that’s where it was created, but when you are on Site 2, it’s looking for that content in Site 2’s folders. That would need to be amended to allow for the site where the content item was created (if that’s not already what it does). And the root menu generation would have to stop using the siteID for which site you are on, but a combination of the siteID you are on and the site selection.

This is the part of the change that I’m lease familiar with because it’s all deep in the ContentBox code and I don’t know what changes might affect what other things. Plus, I don’t want to change core code if I can change it because then upgrades will be painful.

My initial thought right now is to create categories for each site and then in the header for the theme, I can change the default call to rootMenu to something like this:

<cfset pageService = application.wirebox.getInstance(“pageService@contentbox”) />

<cfset args = {
excludes = “”,
type = “data”,
typeClass = “”,
separator = “”,
levels = “2”,
elementClass = “”,
parentClass = “parent”,
activeClass = “active”
} />
<cfset args.pageRecords = pageService.findPublishedContent(
parent : “”,
category : “Site 2”,
showInMenu: true,
properties: “contentID,slug,title,numberOfChildren”,
sortOrder : “order ASC, publishedDate ASC”
) />
<cfset menuData = cb.buildMenu( argumentCollection = args ) />

(buildMenu in CBHelper.cfc has to be made public for this)

Then most of my changes are just localized to my theme and I can manipulate the data how I need. I was just hoping for something more built-in that I could leverage.