Expanding on the foundation
The 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 post instead.
Can everything be shared out?
Unfortunately not everything can be shared out from the foundation project. The process is limited to media folders, content classes and the element properties as far as I know. Things like workflows and publication targets can’t.
This is where good planning and the template child project comes into play. If you ensure your template project is fully configured with all the settings, including workflows and common security groups, you’ll save yourself time setting up each project.
Content can also be shared to other projects. I’ll try and cover this in another article (or update this one at a later date)
How do you cope with shared content classes and QA testing?
With the foundation/child setup you will always have to return to the foundation project to make changes to your content classes. It is also advisable to make any changes to element properties in the foundation, it’s a real pain to have to go through all your child projects and make the same changes over and over.
When doing QA testing there are a couple of important steps to remember.
1) Don’t forget to test changes in a child project as well as in the foundation project. We’ve encountered the occasional blip where scripts work perfectly in the foundation, but not in the child.
2) When pushing a content class out for testing you will need to remember to temporarily adjust the project sharing to only include the test site. You will need to return the setting to include all child projects as components are unavailable for creation whilst the sharing is broken.
That sounds too easy. What’s the catch?
There are issues doing the whole development/QA within the foundation project. Because you can only share out items at a folder level, you need to make sure that everything is in a signed off state before you push out any updates to the children.
The easy way arond this issue is to set up another copy of your foundation, specifically for developing and testing in. Once you’re happy with the template you can do an export and bring this template into your “live” foundation. This development foundation can even be on a separate server; we have a complete development environment to make sure that nothing interrupts the live projects. Given the amount of scripts we have, this is probably a wise thing.
How do you link up projects to share out content classes
The final question dealt with the “how” for sharing. This will be a separate “How To…” type post tomorrow.
|
|
|
|
|
 |
[...] This article has been expanded upon [...]
Paul, good elaboration. Thanks and I think you answered everything I was curious about in terms of your approach and practice in sharing content.
Your “re-importing Foundation project back from the QA copy” idea is pretty inspirational approach and it should be applicable to scenario whereby a lot of change is anticipated in QA.
Thanks for a good round of converation!
We find having a development foundation project essential as we have a team of developers working on the same project. This approach stops any untested/unapproved templates being pushed out.
I’m mostly done with your other question, so that should be up over the weekend… with pictures this time
One of the nastiest foundation/child content-sharing issues in the current CMS version relates to Asset manager folders and related image/media elements.
Unfortunately, a current limitation of RedDot CMS is that it requires an asset manager folder to be assigned to all image and media element placeholders. In other words, there is no way to select a “Null” folder setting (or select a: “[Local folder]” alternative).
Since the Asset manager folders are typically shared from the foundation project, this results in all asset content (potentially from multiple child projects) being loaded into common asset manager folders by default…and that’s potentially disastrous (especially if your users are poorly trained) with users from different projects either:-
mistakenly overwriting each others content or
creating multiple versions of the same content, bloating your Asset libraries in the process.
The best solution to avoid this would be to have all child projects use their own local Asset Manager folders…but that’s where we hit a problem. because although the “Folder” option for each element can be manually amended to point to a local asset folder, it appears that everytime you update a content class in the foundation project and roll out the change to all child projects, your local settings are over-written!