Looking for a little advice / a pointer in the right direction..
I want to build a site, say a restaurant site that has common nodes to all child nodes of a particular type e.g:
-Home
-Meet The Team
-Food Menu
-Drink Menu
-Restaurants
-Restaurant 1
-Restaurant 2
-Restaurant 3
What I'm after is a way to change the URL structure so that a customer would see: www.example.com/restaurant-1/the-team/
as 'The Team', 'Food Menu' & 'Drink Menu' would be common to all restaurants.
I don't want editors to have to add each of those nodes every time they add a new restaurant, their content would be driven by another node picked at restaurant level.
I know there is the URLProvider/ContentFinder which I have used before for more simple things like injecting a language to each URL, but I'm struggling to think of how I would go about this?
You could potentially hook into the Save and Publish event when adding a new restaurant node and then automatically create the required child nodes for 'The Team', 'Food Menu' & 'Drink Menu'. You could then automatically set the value of the node pickers on each of these child nodes by looking under the homepage for direct descendants with a specific node type alias and grabbing the Id's.
On the restaurant document type you can add an umbracoUrlAlias property which will allow you to override the url so you do not see /restaurants/restaurant-1/ but /restaurant-1/.
I'm actually already creating child nodes on save (if it's a new "restaurant" node), but I was (perhaps foolishly) hoping for a cleaner/lighter structure in the backend for the editors, rather than having dozens of repeated identical nodes, even if they are auto-created.
As for the URL, the way I have it structured with the top "restaurants" node at the root, it doesn't show in the URL, so that part is fine..
Well, for now I'll work with it this way as I know it will work, and just maybe I can come up with a more "editor friendly" tree later on..
Thank you for your thoughts, they are appreciated :-)
Alternative site structure
Hey guys,
Looking for a little advice / a pointer in the right direction..
I want to build a site, say a restaurant site that has common nodes to all child nodes of a particular type e.g:
-Home -Meet The Team -Food Menu -Drink Menu -Restaurants -Restaurant 1 -Restaurant 2 -Restaurant 3What I'm after is a way to change the URL structure so that a customer would see: www.example.com/restaurant-1/the-team/ as 'The Team', 'Food Menu' & 'Drink Menu' would be common to all restaurants. I don't want editors to have to add each of those nodes every time they add a new restaurant, their content would be driven by another node picked at restaurant level.
I know there is the URLProvider/ContentFinder which I have used before for more simple things like injecting a language to each URL, but I'm struggling to think of how I would go about this?
Any help would be appreciated.. Thanks!
Mark
You could potentially hook into the Save and Publish event when adding a new restaurant node and then automatically create the required child nodes for 'The Team', 'Food Menu' & 'Drink Menu'. You could then automatically set the value of the node pickers on each of these child nodes by looking under the homepage for direct descendants with a specific node type alias and grabbing the Id's.
On the restaurant document type you can add an umbracoUrlAlias property which will allow you to override the url so you do not see /restaurants/restaurant-1/ but /restaurant-1/.
Matt
Hi Matt,
I'm actually already creating child nodes on save (if it's a new "restaurant" node), but I was (perhaps foolishly) hoping for a cleaner/lighter structure in the backend for the editors, rather than having dozens of repeated identical nodes, even if they are auto-created.
As for the URL, the way I have it structured with the top "restaurants" node at the root, it doesn't show in the URL, so that part is fine..
Well, for now I'll work with it this way as I know it will work, and just maybe I can come up with a more "editor friendly" tree later on..
Thank you for your thoughts, they are appreciated :-)
Mark
is working on a reply...