• RedDot CMS Blog
• 16.01.2017
• EN

rdb: That Parent/Child relationship explained

In other words… we’re finally going to answer one of your many burning questions, the whys, the wherefores and the whatnots of Foundation projects. I know, I know… we’re so slow!

The most important part of any project is the careful planning of everything, not just the design of the final site. You need to be comfortable in the knowledge that what you build now will be easy to maintain, update and expand. Sometimes it will be obvious at the start of your project that you’re going to need more than one version of the site, other times you’ll be assured that this will be the only one. Whatever they say… go for a parent/child project setup… it will save your sanity in so many ways!
 

So what is this Parent/Child thing?

RedDot gives you the ability to share content folders between projects, cunningly called Content Class Sharing. This allows you to use the same content classes, media items, style sheets etc.) in a number of projects, which will mean it’s quick to create a new copy of that website they insisted was a one off. (Do you get the feeling that I’ve been bitten by this before?). It’s important to note that workflows and publication targets can not be shared out, it’s only Folders and, at times, content.

The idea behind the Parent/Child configuration is that you have your main project, the Parent, only holding your templates. Content should never go into the Parent, this should effectively be your development area if you don’t have the luxury of a separate Dev server. By having all your content classes in one location, you can dramatically reduce the length of time it takes to update some code as it only needs doing once, rather than in every project. If you’re clever you can also use the foundation project as a testbed for every possible combination of content classes; I’ll cover that later.
 

Setting up the Children

Once you have your Parent project all sorted, you can start on your Child projects. Our first new project we’re going to call the Template Child. This project will be set up with our workflows, default permissions and some basic structure; ideally the homepage and one or two general pages that every version of this site will need, such as Sitemap and Contact. The idea behind the Template is to have everything set up, so that creating a new project is simply a case of copy/reset share/set user access

This new project need to  be configured to inherit the folders from the Parent. How do we do that?

In the Parent project you will need to go to the Folders and Administer Content Class nodes and use the Edit Content Class Sharing option for each folder/content class. Tick the name of your Template project each time and we’re done. this is a little repetitive, but will save you time in the long run.

Back in the Template project we need to go to the Folders node and create all the folders we want to inherit. During the creation process it will ask where you want this content to come from. There should, if the sharing has been done, be a drop-down list with all the shared folders from your Parent. Choose the right one… rinse and repeat until you have all the shared folders. You will notice that as you create each folder and assign one of the shares, the share vanishes from the option list next time around. This is to prevent you inheriting two lots of the same content.
 

Why have we done all this?

By creating the Template project, creating a new site simply becomes a case of copying the Template project and adding it to the list of shared projects in the Parent (remember where we set up the folder sharing a minute ago?).

Apart from the Template and live Child projects, we also had a Sandbox site, which was basically used for training purposes. The editors had access to this site so they could try out new Content Classes without worrying about breaking the live site.

Occasionally you’ll find that someone wants a new Content Class for their project. Just because you are inheriting from the Parent doesn’t mean you can’t create additional Content Classes in a Child project along the way. While it’s not the best solution, it’s doable. I would still suggest trying to create all new Content Classes in the Parent regardless of where they will be used, just in case someone comes along and asks for it elsewhere.
 

Using the Parent project for testing

As you’re not going to be using your Parent project to store live content, you can make the project work for you in other ways.

It’s tempting to just have a few random pages and dump whatever content class you’re testing onto the front page for a quick look. We fell into this bad habit and it wasn’t very efficient for testing. Lesson learnt ;)

The design agency that we worked with had come up with all sorts of content blocks and had decided where each item could or couldn’t be used. If someone put the news list into the wrong column everything went a little weird, so it was important to test content classes wherever they should be used. Try to take your time and assemble example pages in your Parent project that use your content classes in the containers they are allowed in. It’s even helpful to have them in multiple times to help identify padding/margin issues in the CSS as well as variable name clashes.

Before you go pushing out any new updates, make sure that you have all the elements named correctly with their default values set, if they have any, plus the pre-assignment of Content Classes to containers. By doing this you’ll save yourself lots of heart ache. It’s never fun to have to go through 12 Child projects and reassign a value to an element that you forgot. If everything is managed from the Parent your life will be so much simpler!

By setting all this up, you simply need to glance at each page to make sure everything still displays correctly.

Once you’re done with the testing you can push the content classes out to all the child projects in one go, safe in the knowledge that it works. If something in one of the child projects breaks… duplicate any special cases in the Parent so you can test it again next time.
 

There’s a catch in using the Foundation for development…

When you share Content Classes between projects you’re sharing it out as a full folder, rather than individual templates. This means that before you can push out any changes you need to be 100% certain that all the Content Classes in that folder are ready to go. If there’s only one or two of you working on the same site it shouldn’t be much of an issue.

For the most secure development environment, we’d suggest setting up a copy of the Parent and exporting the templates into the live Parent when they are complete.
 

One last thing…

To save duplication, and server load/space, we’d suggest placing your media folders on the server, rather than in the database as it will give you much faster response times as well as easing the database load. It’s never a great idea to store binary files in a database.