Setting the foundations
In any project you have to start somewhere and before anything else, even the naming schemes, the structure of your projects are always the most important thing to look at. You need to make sure you are going to be putting your projects together in a format that’s not going to cause you problems later down the line. Project names can be changed easily enough and, while not hard, it’s a lot more work to break up and reorganize your projects later.
When starting a project we’ve heard time and again that there will never be any other versions of the site, so you’ll probably be tempted to put all your templates and content into the same project. Don’t believe them. Ever. It’s in your best interest to ensure that your content classes don’t ever end up in the same project as the final content.
There are a number of reasons for this :
- You can never be 100% certain you’re not going to want another copy of this site. Trust us, we’ve been grateful for having taken the foundation/child route many times this year.
- You will probably want a sandbox version of this project to train editors on without disrupting the live site.
- You will want a way to do development/QA work without impacting the live project.
- Big projects will cause you speed problems if not properly managed.
So. Rather than trying to shove every last piece of project data into the one project we’re going to split it up into a number of projects before we even start with the data entry. We want to end up with three projects. One for the content classes, one for general project settings and a third for the actual live project
- The Foundation project
- Template site
- Live project
Reddot has a handy piece of functionality that was never covered in our training course, Content Class Sharing. This option allows us to easily share folders (content class, media, style sheet etc.) from one project to any number of other projects. This means that no matter how many sites with this design we have, they can all run off the same templates. If you get an update or a style change you only need to do it in one place and push out to all your projects. We are using this to great effect on our corporate internet and intranet sites.
You’re probably wondering what this Template site is.
To use this project breakdown efficiently, we want to set up an example project that has all of our workflows and permissions set up so we don’t have to redo it each time we create a site. As well as these project settings we’d also suggest setting up a bare bones site that has a couple of empty pages configured with the navigatio,n as well as linking in all the stylesheets and script files. This should be just enough for you to create a new site, but not too much that you’ll end up deleting loads before you can start work.
“I don’t get it… why go to all this trouble?”
The point of setting up this template site is to allow the creation of any number of child projects quickly and easily. By taking a copy of the template site and linking it up to the foundation we’ve already done all the hard work. The new project can then be given to your editors as it’s all ready for them to start creating their content 
What if one of my child projects needs a different template for something?
Occasionally you’ll get one child project that needs a slightly different stylesheet, or content class from all the others. Just because you’re inheriting templates from the foundation doesn’t stop you creating additional templates within a project. While not an ideal situation it is doable. I think we’ve only done this once… so don’t worry too much about it.
Media elements
One last thing before I finish. I’d suggest making all of your media folders point at the server’s disk drive, rather than the database. This has a two fold effect. Firstly it’s much simpler to share content between projects as they all look at the same files. Secondly you will be improving your database performance; it’s never a good idea to store binary files in a database.
Don’t trust us? Frederic Hemberger’s article covers this topic from another angle.
The only down side to this way of setting things up is the increased number of projects being used. When it comes to licensing you’re going to need to ensure you have plenty spare!
This article has been expanded upon
|
|
|
|
|
 |
Hi Paul,
Your post is a very insightful piece and I can really appreciate the foundation/template/ combo and the projects as off-springs approach.
I just came off the tails of a corporate extranet that leverages RedDot CMS and LiveServer. I wish I had the foresight of templatizing the project spun off a “QA” project alongside the live one. The gigantic mess a prolonged QA process created is something I would try to avoid at any cost.
Since I have not really tested this brilliant approach you have posted here, I would have to ask a few dumb question.
1)Suppose one has created a QA site and a live site based on the same shared foundation classes and template project settings. Along the process of QA, a workflow step needs to be revised. At this point, does one go back to the template site project and modify the workflow there and such change can be reflected in both the QA and live site projects? Or does one has to change the workflow in the QA site and manually replicate the same in the template site and live site projects?
2)The same question on content classes (page tempaltes) when accomodating QA-requested change. However, I think the answer here is that you can go back to the Foundation project and changes can be reflected in both QA and live site projects. Correct me if I am wrong.
3)Can you please elaborate the steps involved in “linking it up to the foundation” when duplicating the template site project.
Thanks
Henry
Hi Henry
Thanks for the great questions.
For question one, you would need to make the same workflow changes to all of the child projects. The only things you can share out are media folders, templates and template settings (such as preassigned content classes or default settings)
2) For content class changes you can go back to the foundation, that’s the whole point of the setup. Make the changes once and push out to the children. If you’re doing QA for updates you do have to be careful with the sharing though. There’s the potential to accidentally push content classes out to the live project as well as the QA one.
I think questions two and three actually merit their own posts on the blog. I”ll try and do these next week for you
[...] other day I got some interesting questions about the first Foundation post, so rather than answering them as a comment, I figured it would be more useful to write another [...]
Great post, Paul. Thanks for the insight.
I work for a Government Department and we just purchased RedDot. Being still in the planning phase, I am trying to figure the best path for us. From what I read, so far, I believe master/child project is the way to go.
I have a questions:
1. The department website has about 25 sub sections with approximately 6000 pages. Would you make one master and 25 children projects? One child project per sub section?
2. As we are ready now, we are going forward but something that we need to keep is the creation of one master all of Government websites. Is it possible to share content class between two master projects?
3. We are going to use FTP as the Publishing Target and keep ftp rights that we have them now. Ie. We are only ftp access to the department folder (off the root of the Government’s site) and not the root itself. So, if the sharing between the two master projects (Government Master and Department Master) is possible, do we need access of the
Thanks in advance.
Jamie
Hi Jamie
I’m glad you found the article helpful
1) When you say your site has 25 sub sections, are they separate, or do they share the same navigation? If it’s the latter it may be worth trying to stick to one child project as you will hit issues trying to bring all the navigation together.
I do have to say though that I’ve no experience of handling a 6000 page site, our largest is about half that. You will start to encounter speed issues with large projects, especially if you show multiple layers of navigation on one page like we currently are.
If you’re lucky, and they don’t share much of the navigation, then I would say yes to the 25 child projects as it will make your life so much easier.
2) The interesting thing about content class sharing is that you can have as many layers of sharing as you want. You will probably end up with a three tier setup, rather than a two tier one. Your generic templates that need to be in all projects can be in the master project, then you can have the first layer of children bringing in the styles and initial structures of your different designs. Then each projects of these can have children that have the actual content (in effect making them grandchildren of your master project).
Using the idea that you can have children inheriting from any level means that you can become more specific with your projects, templates, styles and permissions the further down you go… but still running from one core set of templates. (I hope that makes sense?)
3) By the time you publish out of Reddot, you don’t need to worry about the sharing… so your original FTP targets should be more than adequate
Good luck!
Paul
Thanks for your respond, Paul.
It sub-section will have it’s own navigation with some common link (contact page, feedback. ect..). So, not too much sharing.
What you are saying makes sense to me. I am still building my project, I will let you know how it turned out.
Thanks again,
Jamie
Hi Paul,
Two months later and I am ready to create a Child project.
I create a Master project that has everything I need. I am wondering how to create a Child project.
I tried to create the Child project as a copy of the Master and fresh project, without any success.
In the Master project, I selected the Content Classes nods and clicked on Edit Content Class Sharing (did the same for the Folders under the Project nod). I selected the Child project as the destination. Both the Project Folders and Content Classes have the green check mark on them.
Do I create a copy of the Master or start with a fresh project as the Child project? Is there anything else (other then Edit Folder Sharing and Edit Content Class Sharing) that I need to do to share the Master project?
Thanks,
Jamie
Sorry about the delay, the joys of being between jobs. Unfortunetely I don’t currently have access to Reddot to give precise instructions, so this may get a little hazy…
When creating your child project you will create a brand new, empty project.
You then do the content class sharing from the foundation project, as you already mentioned, but there’s one more step after that. In the new child project you need to create the content class folders as you normally would, but you have the option of choosing where the content comes from. You should see a dropdown list with the content class folders from the foundation project.
Have a look and see if you can find this, if not I start my new job next week and will try and look up the exact steps for you. I’m also in the process of cleaning up this set of posts for http://www.reddotcmsblog.com so will try and fit all this extra information into it.
Best of luck!
Hi Paul,
I got to work (with your previous help and RedDot support). I also figure out that it is best to start the Child project as a fresh project. Set up all the Content Classes sharing then the preasssign. Save that Child as a template project and copy it for another Child project.
Thanks for your help.
Jamie