Page Type Icons
Permalink
How do I add new Page Type icons to c5 without putting them in the /concrete/images/icons/page_types/ folder (so as to keep them out of the core for upgrade purposes)? I cant seem to find the answer anywhere.
Andrew, pardon me for pitching a noob ball. In my opinion the page type would be something that the theme delivers and not a global setting. In fact, there might be different themes delivering different page types.
What's your opinion on this?
What's your opinion on this?
I see your point and I agree with it but for a simple theme it might be too much effort to create a page type icon..
Wouldn't it be nice to have a bunch of default icons beside the possibility to add custom page type icons using a theme? this could be as simple as adding a sub-folder to the theme "pagetypeicons"..?
Wouldn't it be nice to have a bunch of default icons beside the possibility to add custom page type icons using a theme? this could be as simple as adding a sub-folder to the theme "pagetypeicons"..?
I totally agree. Having a couple more default icons (like 3 column layout) and being able to add them via the theme folder would be great. This makes the most sense. I attached 2 icons that I made for 3 column layouts if anyone wants to use them.
lets see:
1) yes, page type icons should live somewhere that doesn't get wiped by core, there should be an easier way to assign them.
2) neet! thanks for these page type icons we may indeed use them.
3) No. Page Types should not be defined by Theme.
In previous versions of concrete, we did have one page type = one template file.. Made sense at first, and worked okay for small sites. What ended up happening though is you'd get sites with like 40 page types.
Sometimes you need to define something unique about the data model. You want to add some attributes to make it a case study, or you only want to search pages of type: "discussion".
Sometimes you want to do something cosmetically different. Maybe your site has a US and a UK version - the have slightly different designs but the same basic information architecture. There's no differnece in the data model you're creating with a page type, you just want to apply some unique presentation to it.
Well both reasons can get you saying "lets just add a page type!" The problem is you do end up with one HUGE ass list of page types that becomes unwieldy and confusing to anyone who didn't build the site. That's a big no-no in our world - so we went to think of a better approach.
What we have now, from an architecture standpoint, IS a far better approach. You have the flexibility to do whatever you want. Since themes degrade gracefully (if you have a page type and no matching template in the themes directory it will use default.php) there's really no reason to worry that the site will die. We've basically gone from having a single array of 'flavors' to a multi-dimensional array (page types over themes.) I can't say this is always going to result in a simpler site owner experience, but I think it can if thought through correctly, and I know its already provided a lot more flexibility which I love.
That being said, yes - there needs to be a better job with the icons...
as much as anything because they're NOT really layouts.. That's very counter intuitive - you can use them that way, but I'm far more likely to have a page type of "documentation" or "discussion list" (both of which show up in this site) and use the same template as any number of other ones...
perhaps those icons should be more esoteric and descriptive of the page's function rather than layout...
1) yes, page type icons should live somewhere that doesn't get wiped by core, there should be an easier way to assign them.
2) neet! thanks for these page type icons we may indeed use them.
3) No. Page Types should not be defined by Theme.
In previous versions of concrete, we did have one page type = one template file.. Made sense at first, and worked okay for small sites. What ended up happening though is you'd get sites with like 40 page types.
Sometimes you need to define something unique about the data model. You want to add some attributes to make it a case study, or you only want to search pages of type: "discussion".
Sometimes you want to do something cosmetically different. Maybe your site has a US and a UK version - the have slightly different designs but the same basic information architecture. There's no differnece in the data model you're creating with a page type, you just want to apply some unique presentation to it.
Well both reasons can get you saying "lets just add a page type!" The problem is you do end up with one HUGE ass list of page types that becomes unwieldy and confusing to anyone who didn't build the site. That's a big no-no in our world - so we went to think of a better approach.
What we have now, from an architecture standpoint, IS a far better approach. You have the flexibility to do whatever you want. Since themes degrade gracefully (if you have a page type and no matching template in the themes directory it will use default.php) there's really no reason to worry that the site will die. We've basically gone from having a single array of 'flavors' to a multi-dimensional array (page types over themes.) I can't say this is always going to result in a simpler site owner experience, but I think it can if thought through correctly, and I know its already provided a lot more flexibility which I love.
That being said, yes - there needs to be a better job with the icons...
as much as anything because they're NOT really layouts.. That's very counter intuitive - you can use them that way, but I'm far more likely to have a page type of "documentation" or "discussion list" (both of which show up in this site) and use the same template as any number of other ones...
perhaps those icons should be more esoteric and descriptive of the page's function rather than layout...
This time I think I have to insist and stand on my point.
First of all, I am not sure I quite get your point about the "discussion pages". I believe we are mixing the concepts of "semantic type" and "layout type" of a page.
A discussion page (semantic type) can have a three or two columns layout (layout type). Additionally, my personal experience does not suggest me that admins are looking for "Left sidebar" pages - they look for "Discussion pages" instead.
Personally, I would address the semantic type by adding the possibility of "tagging" a page, in a similar fashion to blog entries but with a "page" scope rather than a "post" scope. This idea has also been suggested for the File Manager and does not sound like a bad one.
Having said that, let's get back to the layout types. Here I still have a different perspective: Theme are *indeed* responsible for delivering layouts - I am sorry, using a Page Type on a theme that does not support it is simply nonsense, no matter how gracefully contents will fall back on the default layout - this is NOT what the designer/content manager wanted.
To recap, themes should describe what kind of layouts they support (e.g., 2, 3 columns, etc.). When creating a new page, the CMS should display the layouts provided by the current theme only.
That's my idea, at least.
First of all, I am not sure I quite get your point about the "discussion pages". I believe we are mixing the concepts of "semantic type" and "layout type" of a page.
A discussion page (semantic type) can have a three or two columns layout (layout type). Additionally, my personal experience does not suggest me that admins are looking for "Left sidebar" pages - they look for "Discussion pages" instead.
Personally, I would address the semantic type by adding the possibility of "tagging" a page, in a similar fashion to blog entries but with a "page" scope rather than a "post" scope. This idea has also been suggested for the File Manager and does not sound like a bad one.
Having said that, let's get back to the layout types. Here I still have a different perspective: Theme are *indeed* responsible for delivering layouts - I am sorry, using a Page Type on a theme that does not support it is simply nonsense, no matter how gracefully contents will fall back on the default layout - this is NOT what the designer/content manager wanted.
To recap, themes should describe what kind of layouts they support (e.g., 2, 3 columns, etc.). When creating a new page, the CMS should display the layouts provided by the current theme only.
That's my idea, at least.
I see what you're saying.
You can do what you're saying with c5 now.
Give your client one theme
Make page types that do match layouts as you suggest.
Make icons that match the page types.
Enjoy.
You can even limit the types of pages that specific user groups can add to any one area, if that's of interest.
So unless I'm missing something, I think you have the power to do what you want to accomplish.
That being said, there's a lot of other ways you can put Themes and Page Types together to solve unique and interesting problems. I'm not excited about crippling the core c5 functionality around that because I feel like we've reached a pretty solid implementation of that today which gives everyone everything they could need.
Knowing that I can add a page type of "press release" quickly, and it will degrade gracefully and use default.php is fantastic for the problems that I face in running large sites. Now I can use the page list and search block to specifically look for pages of that type throughout the whole site.
Conversely, it strikes me, you might accomplish what you're talking about with themes instead of page types. Perhaps what you should be doing is making themes for the unique visual layouts, assuming they all have the same block areas in them. Your page types could be functional/meaning in type, and your themes visual.. So pick the Left Column or Right Column theme for this specific page of type 'product review'....
I guess my point is, why give up flexibility here. I recognize it's not obvious at a glance how that system behaves, but it doesnt break in a site owners face, and it's non-destructive (i can change Themes back, etc) what's the problem?
(beyond the very practical YES you should be able to upload a page type icon without getting into the backend, and YES they shouldn't be cleared out by an upgrade.)
You can do what you're saying with c5 now.
Give your client one theme
Make page types that do match layouts as you suggest.
Make icons that match the page types.
Enjoy.
You can even limit the types of pages that specific user groups can add to any one area, if that's of interest.
So unless I'm missing something, I think you have the power to do what you want to accomplish.
That being said, there's a lot of other ways you can put Themes and Page Types together to solve unique and interesting problems. I'm not excited about crippling the core c5 functionality around that because I feel like we've reached a pretty solid implementation of that today which gives everyone everything they could need.
Knowing that I can add a page type of "press release" quickly, and it will degrade gracefully and use default.php is fantastic for the problems that I face in running large sites. Now I can use the page list and search block to specifically look for pages of that type throughout the whole site.
Conversely, it strikes me, you might accomplish what you're talking about with themes instead of page types. Perhaps what you should be doing is making themes for the unique visual layouts, assuming they all have the same block areas in them. Your page types could be functional/meaning in type, and your themes visual.. So pick the Left Column or Right Column theme for this specific page of type 'product review'....
I guess my point is, why give up flexibility here. I recognize it's not obvious at a glance how that system behaves, but it doesnt break in a site owners face, and it's non-destructive (i can change Themes back, etc) what's the problem?
(beyond the very practical YES you should be able to upload a page type icon without getting into the backend, and YES they shouldn't be cleared out by an upgrade.)
Thanks for such a prompt reply. I will read it more thoroughly tomorrow, but the first thing that comes on top of my head is that page types do not get packaged with themes (in other words, I would expect page types to be in the themes/themename folder).
http://www.concrete5.org/help/documentation/developers/themes/
about half way down
about half way down
The provided link is broken (Page not found).
Well, although I'm rather new to C5 compared to you guys, but I think I'd share my perspective about the above issue.
The multi-dimension space of presentation x semantic is brilliant. Theme selection is responsible for presentation, and page type is responsible for semantics of the page.
Also, this is very much logical that the site admin decides the relationship between semantics and the layouts provided by the theme (by selecting the handle in page type) - example: "discussion" pages are displayed in two-column, while "article" pages are displayed in three-column. (even if the same semantic page should have different layouts in different page instances, there should logically be a semantic difference causing this, which leads to different page types)
The problem, in my opinion, is that the relationship between theme and page type is not obvious (you can use "inspect" and check the page type handles etc., but it's not immediate and easy for site builders) and more importantly, it is not controlled. This is caused by semantic x presentation space not being complete.
The graceful fallback is also a great idea, so that the site visitor never gets ugly error messages (he will lose some navigation functionality or a part of the page maximum, but not all) but the site editors should be notified of such a thing.
Examples that get to my mind:
1. In the "Design" window, somehow enforcing the relationship between themes and page types so that the user don't select a theme that does not support the page type.
2. Giving a warning when the graceful fallback happens to the admins (like in the top editing bar of the page, or a list of such pages in the dashboard)
I'm actually building my own theme for my site. The first thought getting to my mind about theme definition, is how simple, easy, clean and tidy it is, but I thought it is a little bit under-defined.
And another suggestion regarding above issue, is that in the default installation, change the page types so that they reflect the semantics rather than layout. This helps for new users.
Well, although I'm rather new to C5 compared to you guys, but I think I'd share my perspective about the above issue.
The multi-dimension space of presentation x semantic is brilliant. Theme selection is responsible for presentation, and page type is responsible for semantics of the page.
Also, this is very much logical that the site admin decides the relationship between semantics and the layouts provided by the theme (by selecting the handle in page type) - example: "discussion" pages are displayed in two-column, while "article" pages are displayed in three-column. (even if the same semantic page should have different layouts in different page instances, there should logically be a semantic difference causing this, which leads to different page types)
The problem, in my opinion, is that the relationship between theme and page type is not obvious (you can use "inspect" and check the page type handles etc., but it's not immediate and easy for site builders) and more importantly, it is not controlled. This is caused by semantic x presentation space not being complete.
The graceful fallback is also a great idea, so that the site visitor never gets ugly error messages (he will lose some navigation functionality or a part of the page maximum, but not all) but the site editors should be notified of such a thing.
Examples that get to my mind:
1. In the "Design" window, somehow enforcing the relationship between themes and page types so that the user don't select a theme that does not support the page type.
2. Giving a warning when the graceful fallback happens to the admins (like in the top editing bar of the page, or a list of such pages in the dashboard)
I'm actually building my own theme for my site. The first thought getting to my mind about theme definition, is how simple, easy, clean and tidy it is, but I thought it is a little bit under-defined.
And another suggestion regarding above issue, is that in the default installation, change the page types so that they reflect the semantics rather than layout. This helps for new users.
I'm not sure about 1.
Sometimes a theme doesn't need a relationship to the page type.
Sometimes it's just useful to have a page type to build a list of pages (like news). In that case, I create a page type "news" with some attributes and a custom page_list block template (not a theme!).
This is great because I can easily select all the news pages, have all the attributes on my page type, but not on all page types to keep it clean.
This isn't related to the theme, a news list can be useful in any theme.
Keep in mind that you sometimes need n-page types for 1-layout to handle more complex lists.
I agree that this might be a bit confusing, but it's necessary imho.
Sometimes a theme doesn't need a relationship to the page type.
Sometimes it's just useful to have a page type to build a list of pages (like news). In that case, I create a page type "news" with some attributes and a custom page_list block template (not a theme!).
This is great because I can easily select all the news pages, have all the attributes on my page type, but not on all page types to keep it clean.
This isn't related to the theme, a news list can be useful in any theme.
Keep in mind that you sometimes need n-page types for 1-layout to handle more complex lists.
I agree that this might be a bit confusing, but it's necessary imho.
I definately agree on that the fallback to default.php is absolutely needed. But it needs to be more defined. I need to know when it is falling back, so that I can be notified when the site is not behaving as I expect.
Although,... I am currently getting confused about the page types, and I am concluding that my understanding was not quite correct.
I posted my question here:
http://www.concrete5.org/community/forums/customizing_c5/page_types...
Although,... I am currently getting confused about the page types, and I am concluding that my understanding was not quite correct.
I posted my question here:
http://www.concrete5.org/community/forums/customizing_c5/page_types...
that link moved to:
http://www.concrete5.org/help/building_with_concrete5/developers/th...
will probably move again..;(
I agree with you on the page types issue - they're very powerful and the thumbnails we use to represent them today aren't really as clear as they should be.. in fact they kind of push you in the wrong direction.. not sure a simple list of block areas would help tho.. its tricky.
http://www.concrete5.org/help/building_with_concrete5/developers/th...
will probably move again..;(
I agree with you on the page types issue - they're very powerful and the thumbnails we use to represent them today aren't really as clear as they should be.. in fact they kind of push you in the wrong direction.. not sure a simple list of block areas would help tho.. its tricky.
Probably a dumb question (but couldn't find the answer reading this thread or searching the forum)...
Those additional icons that c5mix uploaded... if I want to use them on my site, I know where to place them, but how do I get them so they show when viewing page type attributes, or creating new page types?
Thanks for sharing those, c5mix!
Those additional icons that c5mix uploaded... if I want to use them on my site, I know where to place them, but how do I get them so they show when viewing page type attributes, or creating new page types?
Thanks for sharing those, c5mix!
just upload the pictures to
concrete/images/icons/page_types and they will be shown in the dashboard.
Please not that you must upload them to the concrete folder (someting you should never do).
@Core-Team: Why not add a lookup for images/icons/page_types in the "root" of the c5 site?
concrete/images/icons/page_types and they will be shown in the dashboard.
Please not that you must upload them to the concrete folder (someting you should never do).
@Core-Team: Why not add a lookup for images/icons/page_types in the "root" of the c5 site?
duplicate deleted
Remo,
After putting the icons into the C5 icon folder, what next did you do to associate them to their respective sidesidemain.php or sidemainside.php in the themes elements folder. BTW, I did create two such files, (alias of default.php with ID's so that I'd know they were selected) and created the page types and handles. Don't know what do after that. When selecting via dashboard "designs", all I get is the default.php
Really interested in doing a main-side-side layout.
Thanks,
Dennis
After putting the icons into the C5 icon folder, what next did you do to associate them to their respective sidesidemain.php or sidemainside.php in the themes elements folder. BTW, I did create two such files, (alias of default.php with ID's so that I'd know they were selected) and created the page types and handles. Don't know what do after that. When selecting via dashboard "designs", all I get is the default.php
Really interested in doing a main-side-side layout.
Thanks,
Dennis
@Remo: I also think that a new root folder would be the most logical way of handling this.
I found a solution here:http://www.concrete5.org/community/forums/chat/new_page_type_thumbn... It says you have to create a file album called Page Type Icons, upload your images and put them into this album.
Unfortunately, it does not work in my case. When trying to create a new file type, there is a message reading that the icons are taken from the Page Type Icons folder. But my new icons are not shown, only the standard icons.
I found a solution here:http://www.concrete5.org/community/forums/chat/new_page_type_thumbn... It says you have to create a file album called Page Type Icons, upload your images and put them into this album.
Unfortunately, it does not work in my case. When trying to create a new file type, there is a message reading that the icons are taken from the Page Type Icons folder. But my new icons are not shown, only the standard icons.
Hi Torsten,
I think I've got a solution for you: Guess that you are from germany (like i am) and your concrete5 has a language file "de_de"? In this case look for the exact descriptor that ist displayed in the page type menu! In EN it says "Page Type Icons" but when you are using a translated UI then you must use the translated descriptor because the original function uses the "t(Page Type Icons)" wich means it will use the translated spelling. In my case it was "Seitentypen Icons", just depends on the language file you use (there are a bunch of different files around in the community). Finaly you could use poedit to examine the translation file. After all it should work anyway, but curiously now the message line says "(Um eigene Symbole hinzuzufügen, Dateien in einem Set mit dem Namen"Seitentypen Icons" ablegen)"...something the core team could fix up in the future
greets, Marv
I think I've got a solution for you: Guess that you are from germany (like i am) and your concrete5 has a language file "de_de"? In this case look for the exact descriptor that ist displayed in the page type menu! In EN it says "Page Type Icons" but when you are using a translated UI then you must use the translated descriptor because the original function uses the "t(Page Type Icons)" wich means it will use the translated spelling. In my case it was "Seitentypen Icons", just depends on the language file you use (there are a bunch of different files around in the community). Finaly you could use poedit to examine the translation file. After all it should work anyway, but curiously now the message line says "(Um eigene Symbole hinzuzufügen, Dateien in einem Set mit dem Namen"Seitentypen Icons" ablegen)"...something the core team could fix up in the future
greets, Marv
Yes, Marv, I’m from Germany, too. You are right, it seems to have to do with the internationalization, as it does work with „Seitentypen Icons“.
The link to the Themes documentation is still broken (May 2010), but I found what might be the page here: http://www.concrete5.org/documentation/developers/pages/themes...
We will likely provide some kind of interface to choose a custom uploaded image as a page type icon.