Theme Customisation Variable Types
Permalink
Seen this:
http://documentation.concrete5.org/developers/designing-for-concret...
which lists Size, Type, Color and Image variable types for theme customisation. Where can I find a complete list of such types, or is that it? Ideally, I'd like to have boolean and enumerated types; eg, for selecting alignment left/centre/right.
http://documentation.concrete5.org/developers/designing-for-concret...
which lists Size, Type, Color and Image variable types for theme customisation. Where can I find a complete list of such types, or is that it? Ideally, I'd like to have boolean and enumerated types; eg, for selecting alignment left/centre/right.
You may need to set additional configuration types through a dashboard settings page for your theme, and from your theme files grab those settings and make decisions based on the saved config.
Yeah, I thought that might be the answer. That won't allow page-specific customisation; I might have to resort to a large hard-to-maintain family of page templates.
Can you give me a specific example of what you're trying to accomplish?
I'd rather not, because I think it will show that my original question wasn't well thought out! But since you asked...
I'm developing a family of page templates. Some are minor variations on others; eg, in one, a sidebar area moves ABOVE the main area when the grid shrinks; in another, the same sidebar area moves BELOW the main area. In a third case, it might not be rendered at all.
I've found that I can make a single template.php that can do all three things, dependent on the value of a constant. If I could expose that constant through the UI, I wouldn't need to make three separate template.php files, which would improve code consistency and maintainability. I think the user experience would be better too: a bewildering array of template combinations would be unfortunate.
The flaw in my original thinking is that the required constant isn't a CSS/LESS style. It needs to be visible and usable in php code. Ergo, your answer of a dashboard setting would work (site-wide). Alternatively, I may be able to make a 'magic block' that can manage the relevant settings on a page, and have the template.php obtain the settings from the block and adapt accordingly.
There's actually more than one setting involved, but the principles are the same.
I'm developing a family of page templates. Some are minor variations on others; eg, in one, a sidebar area moves ABOVE the main area when the grid shrinks; in another, the same sidebar area moves BELOW the main area. In a third case, it might not be rendered at all.
I've found that I can make a single template.php that can do all three things, dependent on the value of a constant. If I could expose that constant through the UI, I wouldn't need to make three separate template.php files, which would improve code consistency and maintainability. I think the user experience would be better too: a bewildering array of template combinations would be unfortunate.
The flaw in my original thinking is that the required constant isn't a CSS/LESS style. It needs to be visible and usable in php code. Ergo, your answer of a dashboard setting would work (site-wide). Alternatively, I may be able to make a 'magic block' that can manage the relevant settings on a page, and have the template.php obtain the settings from the block and adapt accordingly.
There's actually more than one setting involved, but the principles are the same.
Eh! Atleast its only your original question and not your entire life.. ahem, anyways...
If your talking about areas, you can set them up to not be displayed unless blocks are present within them or if the page is in edit mode. Have you seen how cloneamental does that in the header? By not showing the third column if its empty? Its one way I was able to start coding entire sites for clients with just one page template. In a packaged theme for a marketplace you obviously don't want to force one page template for everything, but the principle is there, where you don't display an entire area if its empty, but show it when in edit mode so it can be populated if user wishes.
If your talking about areas, you can set them up to not be displayed unless blocks are present within them or if the page is in edit mode. Have you seen how cloneamental does that in the header? By not showing the third column if its empty?
$as = new GlobalArea('Header Search'); $blocks = $as->getTotalBlocksInArea(); $displayThirdColumn = $blocks > 0 || $c->isEditMode();
Yes, I'm familiar with that technique. I suppose I could create heaps of areas that serve only to communicate preferences to the template.php, but it would be pretty cumbersome to use!
Alternatively, I could create areas corresponding to all possible template configuration options. There'd have to be rules about which areas would take priority over which others; eg, if you populate a pair of mutually-exclusive areas, only the first one will be shown.
I'll add this possibility to my list of options. Thanks!
Alternatively, I could create areas corresponding to all possible template configuration options. There'd have to be rules about which areas would take priority over which others; eg, if you populate a pair of mutually-exclusive areas, only the first one will be shown.
I'll add this possibility to my list of options. Thanks!
A common use-case I come up against is a global area, but some pages in a design are an exception and need a local area. Doing it with multiple page types and areas escalates, so I make an area that defaults to global, but will be local when an attribute or other config mechanism is set. Combining that with collapsing areas can reduce page-type and area escalation.
On the general problem of escalating areas, have a search back through the forums and github issues for "Page Type and Area Name insanity".
On the general problem of escalating areas, have a search back through the forums and github issues for "Page Type and Area Name insanity".
Attributes!! That's probably the thing I was missing!
I will have a look for info on area naming. I already saw a problem looming for me: I really don't want to use all the 'standard' area names as per Elemental (because they don't really apply neatly), but if I don't, I gather that pages won't get populated nicely when a user swaps themes or templates. Worse, some content seems to go into limbo when applied to an area that is no longer on a page.
You're worth more money, John.
I will have a look for info on area naming. I already saw a problem looming for me: I really don't want to use all the 'standard' area names as per Elemental (because they don't really apply neatly), but if I don't, I gather that pages won't get populated nicely when a user swaps themes or templates. Worse, some content seems to go into limbo when applied to an area that is no longer on a page.
You're worth more money, John.
The insanity threads included some discussion on recovering zombie content.
For the record, the insanity pages John mentioned are (probably):
https://www.concrete5.org/community/forums/5-7-discussion/page-type-...
https://github.com/concrete5/concrete5/issues/195...
https://www.concrete5.org/community/forums/5-7-discussion/page-type-...
https://github.com/concrete5/concrete5/issues/195...
Possible similar to what John is referring to, at times when a global area is the same except on a page or two, I would include a normal area right after the global area, and if the normal area had any blocks added the global area would not show.
Very cunning. I'll add that to the list of possibilities. Will have to balance intuitiveness of configuration versus number of templates.
