Page Types confusion
Permalink
Hi,
I had an understanding of C5 page types (and their relationship to themes), and I have read many stuff in forums and help about that... but when I started to put my understanding to work, I realized that I should be right...
Here's what I thought:
1. Page types are for semantic grouping and providing default blocks in pages
2. Themes provide layouting
3. Page types link to themes via handle property.
So, I created a theme with multiple page layouts (one sidebar, two sidebar, no sidebar, etc.) and started to create age types.
I wanted to have two page types that both display the same layout, example: Home page and Article page both use no-sidebar approach.
Creating both page types, I was trying to use the same handle (to tell C5 which PHP in the theme I'm interested in this page type).
But it didn't let me create the second one, telling me that the handle can't be duplicated.
So, the graceful fallback to default.php in the theme aside, do I have to copy php files for each page type I have? What have I got wrong?
I had an understanding of C5 page types (and their relationship to themes), and I have read many stuff in forums and help about that... but when I started to put my understanding to work, I realized that I should be right...
Here's what I thought:
1. Page types are for semantic grouping and providing default blocks in pages
2. Themes provide layouting
3. Page types link to themes via handle property.
So, I created a theme with multiple page layouts (one sidebar, two sidebar, no sidebar, etc.) and started to create age types.
I wanted to have two page types that both display the same layout, example: Home page and Article page both use no-sidebar approach.
Creating both page types, I was trying to use the same handle (to tell C5 which PHP in the theme I'm interested in this page type).
But it didn't let me create the second one, telling me that the handle can't be duplicated.
So, the graceful fallback to default.php in the theme aside, do I have to copy php files for each page type I have? What have I got wrong?
I'm now thinking about having a single default.php page in my there, which handles all different layout variations, and specifying variations using page attributes. (Checkbox for enabling left / right sidebar in page properties window)
you do have to have a unique handle for concrete5.
you were totally on the right track tho.
How about making a template file in your theme that simply includes the other one?
so home.php exists with all your layout.
but article.php just includes home.php.
tada.
you were totally on the right track tho.
How about making a template file in your theme that simply includes the other one?
so home.php exists with all your layout.
but article.php just includes home.php.
tada.
That's true, it works. If I were to do that, I'd put all my php in elements folder, and use php in themes folder one-to-one with page types, including the underlying php files.
But it's not clean. The fact that you are defining the same concept (like article, home, etc.) in two places (one in PHP files, and the other in page types) is a sign of that something's not right.
If I'm on the right track, it means that the same PHP in theme should be able to be assigned to more than one page types.
As I understand, themes are supposed to be portable, reusable packages that concentrate on the visual appearence. That is, having 2column, 3column, and singlecolumn pages in theme is logical, cause it's related to the visual arrangement of the elements in the page.
Page types, on the other hand, are dependent on the site in context. As an example, I want to have an 'article' page type, and a 'post' page type, both displayed in 2 columns.
If I need to go add a php file for that to work, why do we have a web-based interface for defining page types? You can just infer that from the list of PHP files in the themes folder.
In my opinion, there should be a field in Page Type definition, that specifies which php in the theme to use.
Remember my post about the relationship between page types and php files being under defined? It's in here:
http://www.concrete5.org/community/forums/customizing_c5/page_type_...
Following that, here's my current conclusion till now: suppose we have a new concept, called 'layout'. Layouts are defined separately in the database (like single-column, left-sidebar, right-sidebar, etc.) and they specify which areas should the theme file declare and semantically specify their location and looks.
Layouts can be 'supported' by themes. Each theme supports a defined set of themes. Also, page types 'consume' layouts. They specify which layout the page should be in. Theme selection for the page can then be limited to those which support the layout specified by the page type definition.
Wow... I talked a lot. I hope it can be useful.
But it's not clean. The fact that you are defining the same concept (like article, home, etc.) in two places (one in PHP files, and the other in page types) is a sign of that something's not right.
If I'm on the right track, it means that the same PHP in theme should be able to be assigned to more than one page types.
As I understand, themes are supposed to be portable, reusable packages that concentrate on the visual appearence. That is, having 2column, 3column, and singlecolumn pages in theme is logical, cause it's related to the visual arrangement of the elements in the page.
Page types, on the other hand, are dependent on the site in context. As an example, I want to have an 'article' page type, and a 'post' page type, both displayed in 2 columns.
If I need to go add a php file for that to work, why do we have a web-based interface for defining page types? You can just infer that from the list of PHP files in the themes folder.
In my opinion, there should be a field in Page Type definition, that specifies which php in the theme to use.
Remember my post about the relationship between page types and php files being under defined? It's in here:
http://www.concrete5.org/community/forums/customizing_c5/page_type_...
Following that, here's my current conclusion till now: suppose we have a new concept, called 'layout'. Layouts are defined separately in the database (like single-column, left-sidebar, right-sidebar, etc.) and they specify which areas should the theme file declare and semantically specify their location and looks.
Layouts can be 'supported' by themes. Each theme supports a defined set of themes. Also, page types 'consume' layouts. They specify which layout the page should be in. Theme selection for the page can then be limited to those which support the layout specified by the page type definition.
Wow... I talked a lot. I hope it can be useful.
look, websites are weird animals. I can't say there's an absolute "right" way to do anything on em, just a number of wrong ways...
Pagetypes and themes are a pretty powerful combination right now because you can use them in so many ways. I will be the first to agree with you that there should be some more case studies on what those ways are.. benefits, drawbacks, etc.. What I'm not down with is pretending that we can sit here and architect a perfect solution to everyone's problem in the abstract. The fact that you have one php file including another isn't unclean or not-right, it simply is one of many ways to approach it. Another might be to use the default.php layout for this standard two column layout and then just make NO file for the page type you've defined through the web interface.
the power of making a page type through the web interface is strong. If I want to create some new page type for a data model reason, I can do so without having to touch a file if I'm using the default.php template.. that's nice..
Shi-dunno. Perfect? No, I agree it is not. "Not-right" as in bad approach? Nah, its just fine.
Adding a new layer like "layouts" strikes me as a really good way to make things even MORE confusing for the new developer. I know there's another thread going on, perhaps in beta, about a "Grid builder" type tool that would let you define content centric layouts that still had blocks in em.. that's interesting and hints at this same underlying issue..
I guess what this really comes down to is who are we building for? I feel like what we have today is more than enough for any php developer who knows what they're doing and takes the time to explore around a bit here and ask a question like you have. Including one php file from another feels like a long way from a "hack" to me - PHP was designed to do this just fine.
My concern with all of this page layout discussion is it is very easy to lose target of who it's for... Is it easy for my mom to come in to a concrete5 site and define a new layout? Nope. Is that a goal of mine? not today..
there's a balance, and while i do think this stuff will get tweaked out a bit come version 5.4 - it's not going to involve adding a lot of new concepts, we'll find an elegant way to make things a bit more clear.
Pagetypes and themes are a pretty powerful combination right now because you can use them in so many ways. I will be the first to agree with you that there should be some more case studies on what those ways are.. benefits, drawbacks, etc.. What I'm not down with is pretending that we can sit here and architect a perfect solution to everyone's problem in the abstract. The fact that you have one php file including another isn't unclean or not-right, it simply is one of many ways to approach it. Another might be to use the default.php layout for this standard two column layout and then just make NO file for the page type you've defined through the web interface.
the power of making a page type through the web interface is strong. If I want to create some new page type for a data model reason, I can do so without having to touch a file if I'm using the default.php template.. that's nice..
Shi-dunno. Perfect? No, I agree it is not. "Not-right" as in bad approach? Nah, its just fine.
Adding a new layer like "layouts" strikes me as a really good way to make things even MORE confusing for the new developer. I know there's another thread going on, perhaps in beta, about a "Grid builder" type tool that would let you define content centric layouts that still had blocks in em.. that's interesting and hints at this same underlying issue..
I guess what this really comes down to is who are we building for? I feel like what we have today is more than enough for any php developer who knows what they're doing and takes the time to explore around a bit here and ask a question like you have. Including one php file from another feels like a long way from a "hack" to me - PHP was designed to do this just fine.
My concern with all of this page layout discussion is it is very easy to lose target of who it's for... Is it easy for my mom to come in to a concrete5 site and define a new layout? Nope. Is that a goal of mine? not today..
there's a balance, and while i do think this stuff will get tweaked out a bit come version 5.4 - it's not going to involve adding a lot of new concepts, we'll find an elegant way to make things a bit more clear.
Seems like there are lots of people swarming around similar topics relating to themes, page types, and layouts.
I don't have a better solution for themes and pagetypes, but I was experimenting with an interface for allowing site-owners to customize the layout of a page (as Franz mentioned above). It's probably on a different track than the discussion at hand, but I thought I'd add it to the mix since there's a little bit of overlap here. It's still just a very rough prototype (still stores grid data in sessions instead of the db at this point), but if anyone's curious, they can check it out here:
http://c5sandbox.inneroptics.net/grid_prototype_v2/...
Login with u: sandbox p: sandbox and put that page in edit mode.
The goal of it is to be able to create more complex layouts like:
http://mayans.particlebook.com/page_id/97/Uxmal/?noTB=1...
Still brainstorming here, so chime in if you have any thoughts or recommendations.
I don't have a better solution for themes and pagetypes, but I was experimenting with an interface for allowing site-owners to customize the layout of a page (as Franz mentioned above). It's probably on a different track than the discussion at hand, but I thought I'd add it to the mix since there's a little bit of overlap here. It's still just a very rough prototype (still stores grid data in sessions instead of the db at this point), but if anyone's curious, they can check it out here:
http://c5sandbox.inneroptics.net/grid_prototype_v2/...
Login with u: sandbox p: sandbox and put that page in edit mode.
The goal of it is to be able to create more complex layouts like:
http://mayans.particlebook.com/page_id/97/Uxmal/?noTB=1...
Still brainstorming here, so chime in if you have any thoughts or recommendations.
I can think of some uses that this would come in handy.
Well, I have to confess that the term I used as "not right" is too much for what I meant.
What I see in Concrete 5 has proven to be really "Concrete" to me, you've actually done a very great job. What I mean is that the approach to page types' relation to themes is a single point that it doesn't seem concrete enough. (not the themes, not the page types, they are both very great and useful things, nothing wrong with them. I'm only sharing my thoughts about the relationship in between.)
Let me put it in another way:
When I get a theme and install it on my website, there is a way to have multiple page types linked to 'default.php' in the theme, I can only link one page type to any other php file, unless I modified the theme.
I don't mean that this is a big problem! Just been contributing and sharing what I think about the model, because as a software architect I can't turn off my mind... it keeps thinking and modeling! And of course you know a LOT more than me about your audience and your system, I've been using it only as a simple user for my own personal web site.
And the layout suggestion was just a dump of my brain. The solution to what I have in mind can simply be adding a text field to page type definition that if specified, directs the cms to a file in the theme other than default.php.
What I see in Concrete 5 has proven to be really "Concrete" to me, you've actually done a very great job. What I mean is that the approach to page types' relation to themes is a single point that it doesn't seem concrete enough. (not the themes, not the page types, they are both very great and useful things, nothing wrong with them. I'm only sharing my thoughts about the relationship in between.)
Let me put it in another way:
When I get a theme and install it on my website, there is a way to have multiple page types linked to 'default.php' in the theme, I can only link one page type to any other php file, unless I modified the theme.
I don't mean that this is a big problem! Just been contributing and sharing what I think about the model, because as a software architect I can't turn off my mind... it keeps thinking and modeling! And of course you know a LOT more than me about your audience and your system, I've been using it only as a simple user for my own personal web site.
And the layout suggestion was just a dump of my brain. The solution to what I have in mind can simply be adding a text field to page type definition that if specified, directs the cms to a file in the theme other than default.php.
i didn't mean my reply to sound snappy - although on re-read, perhaps fighting a cold and launching 5.3 wasn't the right time to write that..
I get what you're saying that the page type theme relationship is .... shall we say.. "flexible"? ;)
I just think this is one of those tricky sticky points where you have to balance what a developer wants, what a designer can understand, what a site owner can deal with...
like if we gave you the choice of WHICH php file to point to for every page type - sure that'd be functionally easy.. but it's an extra step to explain in the already confusing explanation of how they go together..
the one overarching thing I am learning through the concrete CMS experience in life is it really isn't about how many features or functions you have, its about the learning curve.. right now we're doing an okay job of presenting concrete5 like a onion.. makes sense at a glance, and as soon as someone says "well i need it to do X and it cant" it's almost always just a training issue..
an interesting example is permissions.. we acutally had advanced permissions FIRST.. or YEARS we've had that... its the simple permissions model that was new with version 5...
as this debate continues (and i really do want it to!) and as it merges with the grid layout debate (because they're both pointing at the same need) i'm gonna keep poking at it with this attitude... "who is it for, does it makes sense to a noob"
anyrate... carry on, and thanks for speaking up! ;)
I get what you're saying that the page type theme relationship is .... shall we say.. "flexible"? ;)
I just think this is one of those tricky sticky points where you have to balance what a developer wants, what a designer can understand, what a site owner can deal with...
like if we gave you the choice of WHICH php file to point to for every page type - sure that'd be functionally easy.. but it's an extra step to explain in the already confusing explanation of how they go together..
the one overarching thing I am learning through the concrete CMS experience in life is it really isn't about how many features or functions you have, its about the learning curve.. right now we're doing an okay job of presenting concrete5 like a onion.. makes sense at a glance, and as soon as someone says "well i need it to do X and it cant" it's almost always just a training issue..
an interesting example is permissions.. we acutally had advanced permissions FIRST.. or YEARS we've had that... its the simple permissions model that was new with version 5...
as this debate continues (and i really do want it to!) and as it merges with the grid layout debate (because they're both pointing at the same need) i'm gonna keep poking at it with this attitude... "who is it for, does it makes sense to a noob"
anyrate... carry on, and thanks for speaking up! ;)
