How do I allow editing sitewide content rendered by a master page?

Bryan Drenner asked on February 19, 2014 14:07

All of my page templates refer to a single master page. That master page has content that is rendered to every page of the site, such as the site header and footer. I refer to this as "sitewide" content. I want content editors to be able to update sitewide content in the CMS Desk. I envision a form with fields for each bit of content data. The master page would somehow render the data from this form. Beyond that, I am uncertain how it's best to implement this process.

  1. How should I store sitewide content? Should I use custom tables? Or perhaps a node of a custom document type stored just under the root?

  2. How should I render sitewide content on the master page? Should I use a web part? Should I call the Kentico API?

Correct Answer

Bryan Drenner answered on February 21, 2014 09:45

Thank you both for your answers. I want to mark both as the correct answer, so I'll summarize here:

  1. Create a document type to hold the sitewide data in its form.
  2. Create a document of that type in a dedicated location in the tree.
  3. Use either a Repeater, or a StaticText web part with macro, to render content from the document.

If you use a Repeater, then you have to create a transformation for each field on the document type. If you use a macro, then the rendering overhead is slightly greater.

0 votesVote for this answer Unmark Correct answer

Recent Answers

Brenden Kehren answered on February 19, 2014 23:59

You're thinking on the right line. What I typically do is setup a content folder node that has "header" or "footer" specific document type content in it. Then place your repeater(s) on the master template where you need them. Then tell your users to add content in the specified area and use the publish to and from dates to magically hide and show content when they need it published.

There should be no need for any API calls or custom code. Its all depending on how creative you are when setting up your templates and visual inheritance.

0 votesVote for this answer Mark as a Correct answer

Milan Kačurák answered on February 20, 2014 04:58 (last edited on December 10, 2019 02:30)

  1. Create a custom document type in CMSSiteManager.
  2. When creating check "Show template selection" and "Behaves as Page (menu item) type".
  3. Define fields for your data you want to have on your master page.
  4. Set all doc types you need as "Child types".
  5. Then go to the CMS.Root doc type and set your custom doc type as allowed "Child type".
  6. Then go to CMSDesk and create document based on your custom document type under the Root.
  7. The point is - This document becomes your new Root (or some kind of virtual Root) and you do not need the default Root any more.
  8. Then create a new Master page template which does not inherit any content and assign it to your new virtual Root.
  9. Now you are allowed to render your sitewide content via macros e.g. {% Documents[“/SitewideContent”].YourCustomField |(identity)GlobalAdministrator%} in your Master page template. Where /SitewideContent is NodeAliasPath to your new virtual Root.
0 votesVote for this answer Mark as a Correct answer

Bryan Drenner answered on February 20, 2014 09:31

Thanks guys! It's strange that you can't comment on people's answers, so I'm commenting as an answer:

@BRENDEN KEHREN: Thanks for verifying my idea. I have a couple followup questions:

  1. For the documents under the special "sitewide content" folder, do I just assign them a blank page template? The sitewide-content document type should never be served. Are there further steps I can take to prevent it from being served?

  2. A repeater (with a transformation) seems awfully heavy and complex just to render a single form value from one document onto another. Is this what you're recommending?

@MILAN KAČURÁK: What is the advantage of creating a new root?

0 votesVote for this answer Mark as a Correct answer

Milan Kačurák answered on February 20, 2014 16:30

The advantage is that it follows your scenario which requires a form with fields for each bit of content data. There is no clean way how to add additional fields to the CMS.Root document type. So I recommend you to create a new virtual root. We use this kind of virtual Roots on connection.kentico.com for each conference subsite and it works perfectly.

0 votesVote for this answer Mark as a Correct answer

Bryan Drenner answered on February 20, 2014 16:47

@MILAN KAČURÁK: What is the advantage of making the sitewide-content-holding document the root, instead of just making it a special document elsewhere in the tree as Brenden recommended?

0 votesVote for this answer Mark as a Correct answer

Milan Kačurák answered on February 20, 2014 17:29

The advantage is that you have data in the same location as a your root. But there is no clear advantage. Brenden's solution based on repeaters could better be from performance point of view because my solution relies on macros which requires data to be processed by Kentico macro engine. But Brenden's solution requires data source, repeaters and transformations...

There is no winner. Certainly you can combine these solutions by creating separate document and feed data via macros to your master page template.

0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on February 21, 2014 06:41

@Bryan take a look at who will be performing the content updates on the site. If you believe the user base is technical enough to use macros then by all means, I like Milan's idea (although never used it) and it would be great to implement. What I suggested is a more straightforward, out-of-the box solution which new or non-technical users typically understand better.

Regarding your questions: 1. I simply point a redirect on the folder to the root of the site, this way users won't get to that folder. I also set the folder and items in that folder to not show in nav or sitemap.

  1. When you compare using a repeater w/transformation vs. macro (custom or not), they are both running a query, the macro will typically have additional logic behind it. If you're at all concerned with performance, I'd suggest turning on debugging and compare which one might be faster. I use this on many sites and clients don't complain about performance at all. In fact, if you have your properties set properly (limit columns returned, include WHERE, use TOP 1, etc.), the repeater will be very fast.
1 votesVote for this answer Mark as a Correct answer

Lance Keay answered on September 18, 2014 08:54

As an alternative of using using a custom document type, you could use Kentico UI strings. It's not as pretty an interface as the forms tab, but you do have the advantage of the resources being quite performant, and multilanguage.

So to set up your 'sitewide' content - create a masterpage and header and footer controls, either aspx or portal and use UI strings for content that won't change very often, but may change from time-to-time.

You can improve usability if you use string key names that explain their location and use - eg: 'homepage.top.header.loginlink.text', 'homepage.top.header.logoUrl', etc

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.