Let me start off by saying: I like Umbraco a lot. I find it easy to set up and manage. However, I think there's a misconception regarding having a Master page and a Home page, which I hope someone can shed some light on.
I currently have these Document Types:
Master
Home
News
About
I allow Home at root, so when I visit / it will show my home, instead of going to /home. Then I create a new Content for Home. That means my Content/page layout looks like this:
Home
News
About
Since I want all my pages to be /news and /about, but still have / be my Home, I therefore allow News and About to be children of Home (in the permissions tab). This is great and all, because I can then create properties on my Home Document Type, which the other document types will inherit (such as SEO).
Well, both great and bad. If I want my Home page to have properties that none of the other pages will inherit, I cannot do that now, because all the other pages inherits from my Home Document Type.
How am I supposed to achieve this:
Have a Master.cshtml file, which has @RenderBody()
Make a property on Home which will not be inherited by all the other Document Types
Make sure / is my Home content page
The only way I can think about this, is by allowing my Master Document Type at root, then replace my Home Document Type with Master and have the same structure as now, but basically have Home as a child of Master (in the content page). This would mean / is set to the Master content page, which I do not want. However, URL rewriting /home to / should solve my issue, right?
Is there a better way? Is this the way to go? Let me know how you guys would structure a page like this, so I can create properties for all pages and while separating Home from the rest of the pages.
Basiclly, try to avoid inheritance and use Compositions and you will save yourself a lot of problem. Since Umbraco 7.2 was released, there is a build in feature called "Compositions", that Blake Clerke wrote a great post about: http://letswritecode.net/articles/document-type-compositions-in-umbraco/
So in your case, you would have theses document types, without any inhertitance:
Home
News
About
And you would allow Home at root, then allow Home to have children of type News and About. Then you would have a Composition called SEO that could look like:
SEO
- Page Title
- Page Description
- Page Keywords
Then you would apply this composition to all you docuyment types, and they will all get these SEO properties.
Now, you can easily add extra properties to you Home doctype, without them beeing inhertied to you News and About doctypes.
And then you can set up your content in the same way as you did in your post:
Home
News
About
That way, your Home node will get url / and News /news and /about.
You should still have a Master.cshtml view, that hold all your global code such as your header html, meta data etc and also the @RenderBody(). Just make sure that your Home.cshtml/News.cshtml and About.cshtml all have this master set in the top:
@{
Layout = "Master.cshtml";
}
Unfortunatly, you cannot "un-inherit" document types, so you would have to re-do your entire backoffice setup, but I promise it will be worth it in the long run.
Best of luck to you. Let me know if you have any more question.
Hello, Dennis! Yes, I have heard compositions is the new thing to use (for a few months or even years now).
If I follow your example, News and About would inherit from Home, which is what I already have now. This cannot work, as I have properties on Home I only want to have on Home. That could be properties like all the content, but content none of the other pages has.
I get the whole idea of compositions and how great they are, but I can't see this work without having the Master at root, then redirect (internal redirect without redirecting through umbracoInternalRedirectId) to Home instead, so my / is now /home. Either that or allow every page at root, but I'm sure that's going to go bad.
No, your News and About doctype should not inherit from Home.
You could still use a Master document type if you want to, that holds SEO info (if you dont want to use Compositions), just make sure that News and About does not inherit from home. And you dont need to create a Master content node at root, you create a Home node at root that will get the url /.
So the Master doctype is just a container of properties for all you other doctypes.
Then you connect your Home/About and News views to the Master template.
Does this make sense or do you want me to make an example with some screenshots?
That's inheritance, right? News and About would inherit from Home. Unless we're talking about the Content section and not the Document Types. If this example is in the Content section, I completely understand it would not inherit.
All your different document types inherit base properties from your Master doc type and can each also add their own unique properties. I have renamed the Document Types to make them distinct from the content nodes in my example, you can keep them the same in reality if you wish.
You then have this as your content structure (again, I have named them to be different to the example above):
HomeContent
NewsContent
AboutContent
Instead of relying on the inheritance of document type properties based on the parent/child relationship you could also use composite types. As an example you could then create a document type for SEO, and another for Branding and add these to your primary Document Types as necessary via the Compositions tab.
This gives a more flexible Document Type and keeps parent/child inheritance for when it's actually what you want.
Misconception regarding Master and Home document types
Let me start off by saying: I like Umbraco a lot. I find it easy to set up and manage. However, I think there's a misconception regarding having a Master page and a Home page, which I hope someone can shed some light on.
I currently have these Document Types:
I allow Home at root, so when I visit
/it will show my home, instead of going to/home. Then I create a new Content for Home. That means my Content/page layout looks like this:Since I want all my pages to be
/newsand/about, but still have/be my Home, I therefore allow News and About to be children of Home (in the permissions tab). This is great and all, because I can then create properties on my Home Document Type, which the other document types will inherit (such as SEO).Well, both great and bad. If I want my Home page to have properties that none of the other pages will inherit, I cannot do that now, because all the other pages inherits from my Home Document Type.
How am I supposed to achieve this:
@RenderBody()/is my Home content pageThe only way I can think about this, is by allowing my Master Document Type at root, then replace my Home Document Type with Master and have the same structure as now, but basically have Home as a child of Master (in the content page). This would mean
/is set to the Master content page, which I do not want. However, URL rewriting/hometo/should solve my issue, right?Is there a better way? Is this the way to go? Let me know how you guys would structure a page like this, so I can create properties for all pages and while separating Home from the rest of the pages.
Thanks!
Hi Morten.
Basiclly, try to avoid inheritance and use Compositions and you will save yourself a lot of problem. Since Umbraco 7.2 was released, there is a build in feature called "Compositions", that Blake Clerke wrote a great post about: http://letswritecode.net/articles/document-type-compositions-in-umbraco/
So in your case, you would have theses document types, without any inhertitance:
And you would allow Home at root, then allow Home to have children of type News and About. Then you would have a Composition called SEO that could look like:
Then you would apply this composition to all you docuyment types, and they will all get these SEO properties. Now, you can easily add extra properties to you Home doctype, without them beeing inhertied to you News and About doctypes.
And then you can set up your content in the same way as you did in your post:
That way, your Home node will get url
/and News/newsand/about.You should still have a Master.cshtml view, that hold all your global code such as your header html, meta data etc and also the
@RenderBody(). Just make sure that your Home.cshtml/News.cshtml and About.cshtml all have this master set in the top:Unfortunatly, you cannot "un-inherit" document types, so you would have to re-do your entire backoffice setup, but I promise it will be worth it in the long run.
Best of luck to you. Let me know if you have any more question.
All the best / Dennis
Hello, Dennis! Yes, I have heard compositions is the new thing to use (for a few months or even years now).
If I follow your example, News and About would inherit from Home, which is what I already have now. This cannot work, as I have properties on Home I only want to have on Home. That could be properties like all the content, but content none of the other pages has.
I get the whole idea of compositions and how great they are, but I can't see this work without having the Master at root, then redirect (internal redirect without redirecting through
umbracoInternalRedirectId) to Home instead, so my/is now/home. Either that or allow every page at root, but I'm sure that's going to go bad.Hi!
No, your News and About doctype should not inherit from Home.
You could still use a Master document type if you want to, that holds SEO info (if you dont want to use Compositions), just make sure that News and About does not inherit from home. And you dont need to create a Master content node at root, you create a Home node at root that will get the url
/.So the Master doctype is just a container of properties for all you other doctypes.
Then you connect your Home/About and News views to the Master template.
Does this make sense or do you want me to make an example with some screenshots?
When you do:
That's inheritance, right? News and About would inherit from Home. Unless we're talking about the Content section and not the Document Types. If this example is in the Content section, I completely understand it would not inherit.
Exacly, this is your Content structure:
And this is your Doctype structure:
Or, Document Type structure with Compositions:
I think we´ve misunderstood each other a few times in this thread due to the mixup of Content / Document Type. Easy mistake.
Hope you are on the right track now and that you get the result you wanted. Best of luck with your revamping!
Have a great weekend! :)
Hi Morten,
I think you're getting Document Types and Content Nodes mixed up here.
There's no reason why you cannot have this as your Document Type structure:
All your different document types inherit base properties from your Master doc type and can each also add their own unique properties. I have renamed the Document Types to make them distinct from the content nodes in my example, you can keep them the same in reality if you wish.
You then have this as your content structure (again, I have named them to be different to the example above):
Instead of relying on the inheritance of document type properties based on the parent/child relationship you could also use composite types. As an example you could then create a document type for SEO, and another for Branding and add these to your primary Document Types as necessary via the Compositions tab.
This gives a more flexible Document Type and keeps parent/child inheritance for when it's actually what you want.
Regards,
Tim
That is most definitely what I am thinking about. I call my Content Nodes and Document Types the same thing, so that's probably where I got it wrong.
This is definitely the way to go. Now comes the tough part: Revamping everything.
is working on a reply...