Avoiding creating too many page types like for homepage?
Permalink
Hi,
Am I right in thinking that best practice is to create page types for existing content types i.e. news, press releases and products etc rather than using them as a design tool i,e, full width layout, no sidebar etc.?
If so, I'm wondering if there's an easy way to avoid creating too many page types as sometimes design 'page types' are necessary and are only used once like for the homepage.
Considering 'Home' is already in the sitemap, I'm assuming creating a single page specifically for the homepage isn't a good option?
Thanks for any clarification,
osu
Am I right in thinking that best practice is to create page types for existing content types i.e. news, press releases and products etc rather than using them as a design tool i,e, full width layout, no sidebar etc.?
If so, I'm wondering if there's an easy way to avoid creating too many page types as sometimes design 'page types' are necessary and are only used once like for the homepage.
Considering 'Home' is already in the sitemap, I'm assuming creating a single page specifically for the homepage isn't a good option?
Thanks for any clarification,
osu
Hey osu,
I recall seeing a thread about this issue a long time ago (probably stumbled on it because I had the same exact question as you did -- should I use a single_page for the home page?).
The consensus was basically "you can't use a single_page for the home page". It kind of makes sense conceptually that you would do that since it's the only page that has that specific design, but it doesn't work in C5 because: 1) you only get a single view.php per theme so you couldn't style any one single_page differently than any other single_page, and 2) the home page is kind of "special" and you can't just delete it, and there's no way I know of to tell C5 that you want some other page (e.g. the new single_page you'd have to add) to actually be the home page of the site.
What I think a great solution would be (both to this problem and to the problem of "too many page types for the user to choose from") is if you could check a box on each page type in the dashboard to either show it or hide it from users when they're adding new pages. That way you as the designer could make a lot of one-off page types for things like the home page or blog index or whatever, but not burden the user with a ridiculous list of page types they'll never actually use.
-Jordan
I recall seeing a thread about this issue a long time ago (probably stumbled on it because I had the same exact question as you did -- should I use a single_page for the home page?).
The consensus was basically "you can't use a single_page for the home page". It kind of makes sense conceptually that you would do that since it's the only page that has that specific design, but it doesn't work in C5 because: 1) you only get a single view.php per theme so you couldn't style any one single_page differently than any other single_page, and 2) the home page is kind of "special" and you can't just delete it, and there's no way I know of to tell C5 that you want some other page (e.g. the new single_page you'd have to add) to actually be the home page of the site.
What I think a great solution would be (both to this problem and to the problem of "too many page types for the user to choose from") is if you could check a box on each page type in the dashboard to either show it or hide it from users when they're adding new pages. That way you as the designer could make a lot of one-off page types for things like the home page or blog index or whatever, but not burden the user with a ridiculous list of page types they'll never actually use.
-Jordan
By using advanced permissions model that "great solution" has been available as long as I can remember. It has pretty good documentation here:
http://www.concrete5.org/documentation/general-topics/simple-permis...
http://www.concrete5.org/documentation/general-topics/simple-permis...
Hi Jordan,
I think your solution would be excellent, there are many instances when this would be useful.
Just my pennies worth.
Cheers
Bruno
I think your solution would be excellent, there are many instances when this would be useful.
Just my pennies worth.
Cheers
Bruno
Thanks Bruno,
This is definitely on my todo list of things I want to contribute to the core system. Hopefully I'll have time to get around to it soon (can't promise that though).
In the meantime I've been using a halfway-decent workaround of putting an underscore in front of the page type names that I don't want the user to see (for example, instead of "Home", I do "_Home_"). That pushes the page type icon all the way over to the right of the list, which usually makes it disappear from the first page of icons. Just make sure you're only changing the page type Name, not the Handle.
-Jordan
This is definitely on my todo list of things I want to contribute to the core system. Hopefully I'll have time to get around to it soon (can't promise that though).
In the meantime I've been using a halfway-decent workaround of putting an underscore in front of the page type names that I don't want the user to see (for example, instead of "Home", I do "_Home_"). That pushes the page type icon all the way over to the right of the list, which usually makes it disappear from the first page of icons. Just make sure you're only changing the page type Name, not the Handle.
-Jordan
Hi Jordan,
It would be great to see that contribution! Thanks also for the suggestion, will defo use that one.
Cheers
Bruno
It would be great to see that contribution! Thanks also for the suggestion, will defo use that one.
Cheers
Bruno
I'm not sure if I just don't get the real problem here, as I'm just repeating that the solution has been there all the time.
http://www.concrete5.org/documentation/general-topics/simple-permis...
"Sub-Page permissions. A grid of every groups/users and all the site page types is displayed allowing you to choose which groups can add what types of pages."
http://www.concrete5.org/documentation/general-topics/simple-permis...
"Sub-Page permissions. A grid of every groups/users and all the site page types is displayed allowing you to choose which groups can add what types of pages."
The problem is that turning on advanced permissions just for this one feature is total overkill. Also, from a more philosophical point of view, this doesn't necessarily have anything to do with permissions (rather it's strictly a UI enhancement), so why should it be tied up in permissions settings?
But you're absolutely correct that if you have advanced permissions turned on then there is no need for another solution.
But you're absolutely correct that if you have advanced permissions turned on then there is no need for another solution.
Hi Orisinal,
We do not manage a lot of the site we create so teaching every customer how to use Advanced Permissions is not always feasible.
While I agree that this solutions works if we where going to be the Super User, but we deliver the whole site to the customer to manage themselves and very often Advanced Permission is a step to far, but thanks for the suggestion :)
Many thanks
Bruno
We do not manage a lot of the site we create so teaching every customer how to use Advanced Permissions is not always feasible.
While I agree that this solutions works if we where going to be the Super User, but we deliver the whole site to the customer to manage themselves and very often Advanced Permission is a step to far, but thanks for the suggestion :)
Many thanks
Bruno
Well, I think it depends.
I think the "Best Practice" is to make the page type hold as much information as possible, so if you have LOTs of similar "Product Pages", yep, make a "Product" page type and fill it with products.
Now what I got curious about is: Can I "nest" page types? Like... The "Products" page type gets everything from the "Main" page type PLUS its own specifications?
This way we wouldn't need to manually add navbar, login etc. to all pages OR to the Theme. The theme would be the design, the "Main" would contain navigation, login link and all the crap you have EVERYWHERE, and then all other page types would have their own specifications. There would be a master page type taking care of that. (Of course, possibly a lot of pages nested within each other. There could be a level or something. I think this could be useful as you go building sections and more sections with a lot in common but still a lot of differences.)
If there isn't a way, I think this could be implemented, 'cause it would make work a lot easier.
Or, of course, I just need to study custom attributes a lot more.
I think the "Best Practice" is to make the page type hold as much information as possible, so if you have LOTs of similar "Product Pages", yep, make a "Product" page type and fill it with products.
Now what I got curious about is: Can I "nest" page types? Like... The "Products" page type gets everything from the "Main" page type PLUS its own specifications?
This way we wouldn't need to manually add navbar, login etc. to all pages OR to the Theme. The theme would be the design, the "Main" would contain navigation, login link and all the crap you have EVERYWHERE, and then all other page types would have their own specifications. There would be a master page type taking care of that. (Of course, possibly a lot of pages nested within each other. There could be a level or something. I think this could be useful as you go building sections and more sections with a lot in common but still a lot of differences.)
If there isn't a way, I think this could be implemented, 'cause it would make work a lot easier.
Or, of course, I just need to study custom attributes a lot more.
What you want to do can be achieved but in an "inside-out" way from what you describe. Instead of nesting underneath a master template, instead you have "elements" which are smaller portions of html that you bring in to each template.
So all of the things in the "Main" page type that you also want in the "Products" page type should be moved out to a separate file (for example, let's call it "primary_layout.php" and put it inside the "elements" directory of your theme). Then in both your main template and your product template, you would include that element like this:
So all of the things in the "Main" page type that you also want in the "Products" page type should be moved out to a separate file (for example, let's call it "primary_layout.php" and put it inside the "elements" directory of your theme). Then in both your main template and your product template, you would include that element like this:
<?php $this->inc('elements/primary_layout.php'); ?>
God you're a genius! How the did I not consider that?!? PHP includes, obviously. Thanks jordan, the easiest solution is (almost) always the best.
I used to do a lot of Ruby on Rails development which works more in the way that you described. When I started working in some other frameworks it took me a while to wrap my head around this "inside-out" method, so I totally understand how it didn't cross your mind at first -- just takes going through it a few times.
-Jordan
-Jordan
Yeah. I never did Ruby, though I want to learn it sometime. But I never did much PHP either. Just a few edits (More precisely, one Mail Form and two or three image galleries trying to find the best one). It's funny 'cause usually we have problems with the syntax, writing the logic. When we fail at deciding the logic in our heads it's quite more frustrating.
Anyways, since we're at it, do you use many includes in your sites? I was thinking about how to structure them so a include could deal with a lot of things and things get messy, probably because of the many editable areas on my Theme.
I'd need at least one include per area, right? When I put that over all the PHP that is gonna be included, even though it is quite less work, I really think there should be an easier way of doing that. I mean, it's quite hard to ask for a client to personalize a PHP to work with the include...
Anyways, since we're at it, do you use many includes in your sites? I was thinking about how to structure them so a include could deal with a lot of things and things get messy, probably because of the many editable areas on my Theme.
I'd need at least one include per area, right? When I put that over all the PHP that is gonna be included, even though it is quite less work, I really think there should be an easier way of doing that. I mean, it's quite hard to ask for a client to personalize a PHP to work with the include...
I use a combination of lots of things to put a site together (page type templates, elements/includes, areas, scrapbook blocks, hardcoded blocks, Global Areas addon, Designer Content addon, custom templates for the page_list block, page attributes, page defaults, and custom blocks and packages). I put a lot of thought into how the theme and site will be structured in terms of manageability for the client. In fact, I would say that the thing that truly sets C5 apart from all the other CMS's is that when you build a site with it, you're designing the editing experience as much as the front-end.
To answer your specific question: I generally won't have more than a few editable areas and maybe one or two includes per page type template. How many editable areas do you have? If you have a lot (more than 5 or 6 I'd say), it probably means there is a better way to structure your layout -- the Designer Content addon (http://concrete5.org/marketplace/addons/designer-content... ) can be very helpful in these situations.
And what do you mean by "ask a client to personalize PHP" -- why would the client ever need to see the php code?
-Jordan
To answer your specific question: I generally won't have more than a few editable areas and maybe one or two includes per page type template. How many editable areas do you have? If you have a lot (more than 5 or 6 I'd say), it probably means there is a better way to structure your layout -- the Designer Content addon (http://concrete5.org/marketplace/addons/designer-content... ) can be very helpful in these situations.
And what do you mean by "ask a client to personalize PHP" -- why would the client ever need to see the php code?
-Jordan
I was thinking about the includes, but if I want the includes to be customizable, things start getting harder and harder.
If I am bringing too many things through includes, well, the includes are including something. So I start messing with pure html and php. So how would I make it, for example, to have a include bring in my Navbar while at the same time having that navbar editable on the C5 Dashboard or something like that...? You get what I mean? If I include ONE block, I can customize it. If I bring 5 blocks on an Include, I'm setting all their parameters through PHP.
Either this or I got way too confused (Sorries if that's the case, I think my tiredness is getting to me, but I just don't get it.).
If I am bringing too many things through includes, well, the includes are including something. So I start messing with pure html and php. So how would I make it, for example, to have a include bring in my Navbar while at the same time having that navbar editable on the C5 Dashboard or something like that...? You get what I mean? If I include ONE block, I can customize it. If I bring 5 blocks on an Include, I'm setting all their parameters through PHP.
Either this or I got way too confused (Sorries if that's the case, I think my tiredness is getting to me, but I just don't get it.).
Using an include (whether php's built-in "include()" or "require()" functions, or concrete5's "$this->inc()" function) is basically like copying the code you're including and pasting it into that spot. So in the element you're including you just put the normal code like you'd have anywhere else in your theme, for example:
You're not bringing in blocks with an include, you're just bringing in other code which should really only have those editable areas in them (the user then adds blocks to the editable areas, but that should not be dictated by your theme). Of course there are rare exceptions where sometimes you do want a block in the template itself, like if it appears on every page and you do NOT want the user to edit it -- but I don't see how that would change anything in terms of the code you write.
-Jordan
<?php $a = new Area('Navbar'); $a->display($c); ?>
You're not bringing in blocks with an include, you're just bringing in other code which should really only have those editable areas in them (the user then adds blocks to the editable areas, but that should not be dictated by your theme). Of course there are rare exceptions where sometimes you do want a block in the template itself, like if it appears on every page and you do NOT want the user to edit it -- but I don't see how that would change anything in terms of the code you write.
-Jordan
Its useable anywhere in the site but it is very specific. You can apply any page type to the home page so it really depends on whether the design you want is achievable with the existing types.
Steve