How to avoid finding yourself in the middle of a RedDot project apocalypse

Albrecht Dürer: The Four Horsemen of the Apocalypse (Detail) After reading a thread on the RedDot Google Group today, the first thought that came to my mind was “If I had to administer this project, I would shoot myself right in the head”:

  • 70 hosted websites in 1 single CMS project
  • 21,000 web pages (5.75 GB) / 13,266 images (4.01 GB)

Say good-bye to performance: This is a complete standstill system. I know, projects are often growing and evolving, but it’s always a good idea to plan a bit ahead – just in case.

Don’t jam everything in one single project

License fees are money, I know. Same is true for the nerves and overall mental state of you CMS administrator. As your demands are growing for your web projects, it also may be a good idea to have a little more scope than the “three projects basic license”.

Share resources wherever you can

Create a technical master project for the development process. Your “live” website should be a child project using shared content classes from the master project. This also allows you to develop and test content classes without playing around with your live website where the editors are working. If the development of a new feature is finished, you can update your live project with a single click. For several similar projects (like country specific websites) I also create an empty template project with basic settings (e.g. resources, project setup, publication settings, common workflows). So setting up new child projects really becomes a snap. What’s good for content classes can’t be wrong for assets: If your projects all use the same look and feel, you can also share parts of the assets like layout pictures (e.g. icons, background images, images used in CSS files), mood and teaser images or common downloads. This reduces redundancy, increases clearness of the file structure and editors can easily re-use files. If you are hosting projects as ASP, you can apply these methods as well: Share common content classes and files as described above and store only the differences in the child projects:

  • Content classes like teasers, download modules, FAQs and image galleries often stay identical whereas only their design is adapted using style sheets.
  • Create customer specific templates in the child project
  • Plan ahead: Which templates you have already build can be adapted for other projects? Maybe one or two additional fields have to be applied or you can use some Active Scripting to make content classes more flexible.

Check your server hardware

Running projects on a single virtual server with your database stored on the same machine will get you in trouble way faster than you can say “Smart Edit” – trust me. The same setup on a physical machine won’t do a good job either. So keep track of your CPU horsepower and RAM. For large projects a server cluster is always a good idea: You can have several editorial servers and/or publishing server. This is also important if you have editors from around the world working on your CMS server: A full publication just before closing time in your U.S. office can be the reason for the massive frustration of your colleagues in Europe. With a cluster you can also avoid performance issues due to user peaks by assigning them to different editorial servers. This can also be changed on already running servers, which brings me to the last point:

Already in a mess and now hell breaks loose?

It’s never too late to hope for salvation – most of the tips above can also be applied to already running projects. Of cause then you’ll have to be extra careful, so you don’t blow up everything. (Hint: Backups of projects and databases are your friends!) For example you can split an existing project while using content class sharing quite easily:

  1. Create a copy of the project (make sure all editors are logged of and all tasks are closed).
  2. Choose one project to be the master
  3. Share all needed asset folders and content classes to the newly created project (check for folder dependencies!)
  4. Create the shared folders in the child project – you should have by now two versions of the asset and content class folders: one local version and a shared one.
  5. Go through all local content classes, pick an instance (select the content class in Smart Tree, choose an instance from the list and click “Show in project structure”) and exchange the content class with the identical shared version. This can be a bit fiddling if you preassigned content classes on links or containers.
  6. When you’re done, check if no instance remained and delete the content class afterwards. If you deleted all local content classes from a folder, you can remove the folder completely.
  7. Check you project, do a test publication, etc.

Set you plan first, check all the steps necessary, do all the backups (and make sure everything can be restored) and remember to communicate maintenance windows early to the users. Always calculate some extra time so you can restore a backup state in the worst case.

About the author:
Frederic Hemberger lives in Cologne, Germany where he works as a technical consultant and senior RedDot developer. After years of studying the ancient and mysterious ways of content management, he acquired the black belt of RedDot-fu.

1 Star2 Stars3 Stars4 Stars5 Stars (11 votes, average: 4.27 out of 5)
Loading ... Loading ...

6 Reaktionen zu “How to avoid finding yourself in the middle of a RedDot project apocalypse”

  1. Ezra

    Nice post, and extra thanks for posting it in English!

  2. Irina Krasteleva

    This is sounds great in theory, but has some limitations as well. RedDot offers very little functionality for sharing content and links across project.

    So if I simply need to add to navigation a link from another project, I cannot do it in RedDot.

    If I need to pull a content from one project to another, with links and navigation working properly - I cannot do it in RedDot.

    We have over than 120,000 pages website. But since this is a single website with intensive cross links between sections, we weren’t able to split it into multiple projects

    Please correct me if I am wrong. I will be very glad to hear that I am wrong about RedDot cross project content sharing functionality.

    Thank you!!

  3. Markus Giesen

    I would say it depends on the agency which develops your project(s). If you now these requirements from the beginning it’s the same with every system. You can but of course have to build a solution for every case on your own.
    You can build a navigation in a way, that you can link to external projects/pages. Even content sharing over multiple projects is possible, my first agency developed an extension for the system to realize such requirements.

  4. Irina Krasteleva

    You mentioned that your agency developer an extension for content sharing. This sounds very interesting and promising!! Is there any possibility we can view/download/ purchase this extension?

    Technically all we need to do, is to link pages from project A into the navigation menu (list placeholder) of project B. RedDot support told us that this is not possible… than we coded “Bridge Page” template to link pages from a different project. However, those bridge pages still don’t fully meet the project requirements. What if page from project A was renamed, or deleted… How the navigation in project B will be updated?

    Once again, response from RedDot support was that this is not possible, and the only way to solve it, is to put everything in one project. Which I really don’t want to do!

  5. kelly

    Actually this post is about my website. The reason it had to be developed this way was:
    1) We’re using CMS 6.5
    2) We needed to share content across different mini-sites
    3) Before 7.5 there was no way for RedDot to do this except to have one very large project

    Yes it’s a bit of a nightmare to administer but mainly due to slowness/performance issues - esp for end users. We’re upgrading to 7.5 now and hope to see our performance issues resolve.


  6. Frederic

    “We’re upgrading to 7.5 now and hope to see our performance issues resolve.”
    Belive me, they won’t. I would recommend to wait for Release 10 which is announced for May … the PageBuilder is rewritten in .NET and is supposed to run 3-5 times faster than in 7.5.