13 Aug 2007
Link to this post
24 Oct 2012
in reply to
Well there's not much of an argument, you're right its a big issue and Tim's right that its 'broken' :)
1. Create a masterpage called 'parent' and put a content block in the footer and a menu in the header.
2. Create 5 masterpages which inherit from 'parent' and name them 1-5 and put a content block in the body to identify them.
3. Create 6 pages, each one utilizing one of the templates.
4. browse all 6 pages.
Everything works as you'd expect it, the footer content block appears on all the pages correctly.
Now edit the 'parent' masterpage and change the content block and hit publish.
If you browse all the pages again, you'll see 5 pages still showing the old content, and just one (the one utilizing the parent masterpage) showing the new content. Meaning I'd have to re-open and re-publish every inherited masterpage to get the changes reflected.
At least that was the issue right up until 5.1.3270 where I last tried it :) Nice sneaky fix there :) But unfortunately .Master changes aren't reflected upon the inherited ones still.
But that's only one third of the problem, the second part of the problem lies in the content-abilities of content blocks.
Although both are html-field only by design their functionality is different.
A template content block, is sort of a 'strict' html-field, where it strips out spans and only stores xhtml valid markup.
Where as a page or shared content-block can store html5 valid markup and doesn't strip out spans.
(FYI: The ability to set which contentfilters apply to a contentblock is broken atm)
Why is this important?
Let's take an actual example of displaying a company's address. Since its 2012 we want to mark-up our address with some microdata.
<div itemscope itemtype="http://schema.org/Organization">
<span itemprop="name">Google.org (GOOG)</span>
<div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
<span itemprop="streetAddress">38 avenue de l'Opera</span>
<span itemprop="addressLocality">Paris, France</span>
The thing is, you simply can't. Copy-paste that on a template editor and it won't store it and strips out in a weird fashion.
Truthfully, the only idiotic way to re-use a marked-up address is to write a usercontrol with that as the markup, save that as a widget and then drag-n-drop it on the templates.
Here's a quote from a support ticket:
"...but the instance of HtmlField in page tempaltes is not affected by the mapped template it will always remain the default html field in sitefinity. This is behaviour done by design as the html field in templates shouldn`t be customized "
Meaning by design, we're working with a CMS system that forces us to adhere to a 1999 (yes more than a decade ago and in the previous century) standard.
And the third issue with inherited templates vs shared content is perhaps not so much technical as it is permission related.
Sometimes you simply don't want to allow certain users to have template editing capabilities.
But when they should be able to edit a certain re-appearing content block say some quote/announcement/banner you have to compromise.
Either you take the risk and hope every day that a novice user won't remove or accidently drop something on a template.
Or you don't take the risk and force the client to drag-n-drop that content block on every single page (s)he creates.