We have a website that uses static content from Tridion published to the filesystem. We are working on changing it over to a DD4T website with content from Tridion being published to the Database. There are 26 site publications and 100’s of components and pages in them. Most of the sites publications are language specific with translated content in them.

We plan to do a phased in migration of the website, so that a portion of the website is migrated to DD4T while others are still served by the filesystem (within a given publication). We will handle which parts are served by the filesystem and which parts are served by the database via web server configuration that will direct the request appropriately. But we have an issue: How can we publish the updated pages to the DB while still keeping the old page in the filesystem for a particular publication?

Since our existing content broker is still serving the pages from the filesystem to the customer while we are developing them in DD4T and publishing them (before redirecting the URL to go to the DD4T application that will serve them), we need a way to publish the updated pages to DB while still keeping them in the filesystem. But if we simply update the cd_storage.xml for the publication to change it from the filesystem to the database and then publish content, the content will be removed from the file system while being added to the database.

So again, the question is: How can we publish the updated pages to the DB while still keeping the old page in the filesystem for a particular publication?

  • Every-time you publish, its reference where to publish is taken from Storage_config. so if you change the storage config and remove the reference of FileSystem from config for that publication, it should not remove your existing pages.
    – Raj Kumar
    Oct 17 '14 at 15:38
  • The binary files like images will still be written to the file system even for the publication thats being migrated. Oct 17 '14 at 15:47
  • i think for images you should write the code to publish the binaries to different folder/structure group.
    – Raj Kumar
    Oct 17 '14 at 16:00
  • You mean create a new storage type pointing to a different folder in cd_storage_conf.xml and use it in my publication. Umh it might work, let me try it out. Oct 17 '14 at 18:01
  • i mean you can, publish images from updated pages to different folder. via creating separate c# tbb e.g engine.PublishingContext.RenderedItem.AddBinary(img, sgroup);
    – Raj Kumar
    Oct 18 '14 at 10:03

If I have understood your question correctly, then you want to have parts of your site served via DD4T (from the broker database), whilst other parts will continue to be served from your existing (mainly file system based) site.

Assuming that there is no issue with the content being duplicated on the filesystem as well as in the databases (and it sounds like this is sometimes desirable (e.g. for images)), then you should consider setting up another Deployer, dedicated to the DD4T sections, that writes Pages and Components to a new Broker database.

You can update your existing Publication Target(s) to write to both the existing Deployer (that serves the old file system sections), and to the new DD4T deployer (that writes everything to the new Broker database).

Then (assuming that your two parts of the site are served by separate web applications) you can then configure the DD4T part of your application to read the DD4T XML from the Broker database, whilst the older parts of your site continue to have their cd_stroage_conf.xml file configured to read from the file system.

Everything that your editors publish will then go to both locations.

As you move your site over to DD4T, you will serve less and less content from the filesystem.

Once your whole application has moved over to DD4T, and all of your content has been published in to the DD4T Broker database, you should be able to remove your old filesystem deployer (and remove it from the Publishing Target(s)).

  • @johathan: her existing pages could be html/aspx pages, if she republish a page after DD4T change, those old pages on file system would be replaced with new DD4T xml/format page. which i think would not be desired. if i interpret your answer correctly
    – Raj Kumar
    Oct 20 '14 at 13:57
  • @RajKumar That's a good point, and something I'd not considered. I'll update my answer shortly. Oct 21 '14 at 9:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.