Integrating the Kube Framework with the Concrete5 Grid System
Permalink
Hi, I'm trying to integrate the Imperavi Kube framework (http://imperavi.com/kube/css/grid/ (same people who make the new C5 Redactor text editor)) into the Concrete5 grid system.
I've successfully followed the tutorial here (https://www.concrete5.org/documentation/developers/5.7/designing-for-concrete5/adding-grid-support-to-your-theme/advanced-create-and-use-your-own-grid-framework/) and have Kube registered with Concrete and available to the 'Add Layout' drop-down but I'm getting very odd results when adding column.
Basically my column are all different widths within the same set. (See my image attachment).
The Kube framework uses percentage widths instead of the number of columns (as Bootstrap or Foundation) so I'm implemented a subset of 5 equal widths in my Grid Framework files - like so:
unit-20 makes 5 equal columns, unit-25 makes 4 equal columns, unit-33 makes 3, unit-50 makes 2 and unit-100 makes 1 column.
I've told the block area to have a maximum of 5 columns:
But keep getting these weird uneven columns that don't fill the width until i specify 5 columns. Is my implementation wrong or is Kube just incompatible with the way Concrete use grids layouts?
Anybody got any ideas? The Kube system is great, Ive used it to build my C5 themes for years. Its not as complex at Foundation/Bootstrap but very flexible and doesn't get in the way of you design - so it would be really useful to get it working in there grid layout properly!
I've successfully followed the tutorial here (https://www.concrete5.org/documentation/developers/5.7/designing-for-concrete5/adding-grid-support-to-your-theme/advanced-create-and-use-your-own-grid-framework/) and have Kube registered with Concrete and available to the 'Add Layout' drop-down but I'm getting very odd results when adding column.
Basically my column are all different widths within the same set. (See my image attachment).
The Kube framework uses percentage widths instead of the number of columns (as Bootstrap or Foundation) so I'm implemented a subset of 5 equal widths in my Grid Framework files - like so:
public function getPageThemeGridFrameworkColumnClasses() { $columns = array( 'unit-20', 'unit-25', 'unit-33', 'unit-50', 'unit-100', ); return $columns; }
unit-20 makes 5 equal columns, unit-25 makes 4 equal columns, unit-33 makes 3, unit-50 makes 2 and unit-100 makes 1 column.
I've told the block area to have a maximum of 5 columns:
<?php $a = new Area('Main'); $a->setAreaGridMaximumColumns(5); $a->display($c); // main editable region ?>
But keep getting these weird uneven columns that don't fill the width until i specify 5 columns. Is my implementation wrong or is Kube just incompatible with the way Concrete use grids layouts?
Anybody got any ideas? The Kube system is great, Ive used it to build my C5 themes for years. Its not as complex at Foundation/Bootstrap but very flexible and doesn't get in the way of you design - so it would be really useful to get it working in there grid layout properly!
Hi,
Not sure if you have tested this with the Bootstrap grid yet, but its also doing the same thing.
For example lets say we have this as the main area on a left side bar page type.
You would think that setting max columns to $a->setAreaGridMaximumColumns(9); would be the right thing to do, but just like your screenshot shows, it adds uneven columns when adding a layout.
The fix is to add $a->setAreaGridMaximumColumns(12);
I am not certain if this is a bug or the grids intended behavior, but it is a little confusing.
In your case since it looks like your page is a full width page type you can probably use $a->enableGridContainer(); instead of $a->setAreaGridMaximumColumns(12); to get things working.
Not sure if you have tested this with the Bootstrap grid yet, but its also doing the same thing.
For example lets say we have this as the main area on a left side bar page type.
<div class="col-md-9 col-sm-9 col-lg-9">
<?php
$a = new Area('Main');
$a->setAreaGridMaximumColumns(9);
$a->display($c);
?>
</div>You would think that setting max columns to $a->setAreaGridMaximumColumns(9); would be the right thing to do, but just like your screenshot shows, it adds uneven columns when adding a layout.
The fix is to add $a->setAreaGridMaximumColumns(12);
<div class="col-md-9 col-sm-9 col-lg-9">
<?php
$a = new Area('Main');
$a->setAreaGridMaximumColumns(12);
$a->display($c);
?>
</div>I am not certain if this is a bug or the grids intended behavior, but it is a little confusing.
In your case since it looks like your page is a full width page type you can probably use $a->enableGridContainer(); instead of $a->setAreaGridMaximumColumns(12); to get things working.
$a = new Area('Main'); $a->enableGridContainer(); $a->display($c);
Thanks for your reply hostco, I tried setting to 12 columns and then using $a->enableGridContainer(); instead - but I'm still seeing uneven columns generated (it's just adding 'units-container' and an extra 'units-row' / 'unit-100' around the columns now).
<div class="units-container"> <div class="units-row"> <div class="unit-100"> <div class="units-row"> <div class="unit-25"></div> <div class="unit-25"></div> <div class="unit-20"></div> </div> </div> </div> </div>
I use my own grid system (great with 5.6), but found 5.7 a bit strange when using ‘Add Layout’. What I had to do was add a new set of span classes in my main.less file, include them in the ’src/framework.php’ and use ‘$a->setAreaGridMaximumColumns(12);’, NOT ‘$a->enableGridContainer();’. I found twelve has to be used because C5 uses ‘Bootstrap’, which is based on ’12’.
So in my main.less file for C5 layouts I added:
And then for my grid system I have:
In the framework.php I have:
I do not use the ’span’ classes in my themes, they will only appear if an area has ‘Add Layout’ implemented.
Try putting the ‘span’ class in your theme to see if it works.
So in my main.less file for C5 layouts I added:
.span12{width: 100%} .span11{width: 90%} .span10{width: 85%} .span9{width: 75%} .span8{width: 66.666%} .span7{width: 60%} .span6{width: 50%} .span5{width: 40%} .span4{width: 33.333%} .span3{width: 25%} .span2{width: 16.666%} .span1{width: 8.333%}
And then for my grid system I have:
.boxx20{width:19%} .boxx25{width:24%} .boxx30{width:29%} .boxx33{width:32.333%} .boxx35{width:34%} .boxx40{width:39%} .boxx45{width:44%} .boxx50{width:49%} .boxx55{width:54%} .boxx60{width:59%} .boxx65{width:64%} .boxx70{width:69%} .boxx75{width:74%} .boxx80{width:79%} .boxx85{width:84%}
Viewing 15 lines of 17 lines. View entire code block.
In the framework.php I have:
$columns = array( 'span1', 'span2', 'span3', 'span4', 'span5', 'span6', 'span7', 'span8', 'span9', 'span10', 'span11', 'span12', );
I do not use the ’span’ classes in my themes, they will only appear if an area has ‘Add Layout’ implemented.
Try putting the ‘span’ class in your theme to see if it works.
Thanks Steevb, like you the conclusion I've come to is that you must have 12 columns specified for the layout grid to be deployed correctly in add layout.
With the Kube framework, using the following:
gives me the choice of up to 4 correctly sized columns - after that they begin to be uneven again. But for my purposes at the moment this is an acceptable work-around! (Only need up to 4 columns in my theme design).
I think the C5 layout system would need further work to support frameworks that specify columns using percentage widths as opposed to the actual number of columns.
With the Kube framework, using the following:
$columns = array( 'unit-10', 'unit-20', 'unit-25', 'unit-33', 'unit-40', 'unit-50', 'unit-60', 'unit-66', 'unit-70', 'unit-80', 'unit-90', 'unit-100', ); return $columns;
gives me the choice of up to 4 correctly sized columns - after that they begin to be uneven again. But for my purposes at the moment this is an acceptable work-around! (Only need up to 4 columns in my theme design).
I think the C5 layout system would need further work to support frameworks that specify columns using percentage widths as opposed to the actual number of columns.
Do you know if this has been updated or has changed?
We're struggling with the same thing while working with more flexible grids that don't care about specific columns, but rather divide the space available (like the Yahoo framework Pure:http://purecss.io/grids/).
Seems like there's logic that locks you into certain classnames and therefore frameworks which is a shame.
We're struggling with the same thing while working with more flexible grids that don't care about specific columns, but rather divide the space available (like the Yahoo framework Pure:http://purecss.io/grids/).
Seems like there's logic that locks you into certain classnames and therefore frameworks which is a shame.
Even with the newest version of C5 (5.7.5.1) I could only get up to 4 even-width columns to work properly (using Kube) - anything above that just came out totally wrong!
I think there is a fundamental incompatibility in the way the C5 custom grid system expects to define columns with numerical units to specify column widths (like Foundation) to frameworks like Kube which use combinations of percentage width (that all add up to 100%) to proportionally divide the space available as you say.
I'm not familiar with Pure, but it looks like it follows a similar principle as Kube to defining column percentage widths - so I don't think it will be possible to implement a perfect custom grid layout beyond a few compatible classes. I have at 1, 2, 3 or 4 definable columns working (which does give 'most' of the flexibility I currently need with a page layout in my design.
I think there is a fundamental incompatibility in the way the C5 custom grid system expects to define columns with numerical units to specify column widths (like Foundation) to frameworks like Kube which use combinations of percentage width (that all add up to 100%) to proportionally divide the space available as you say.
I'm not familiar with Pure, but it looks like it follows a similar principle as Kube to defining column percentage widths - so I don't think it will be possible to implement a perfect custom grid layout beyond a few compatible classes. I have at 1, 2, 3 or 4 definable columns working (which does give 'most' of the flexibility I currently need with a page layout in my design.
A few observations I can make:
- concrete5's layout tool seems to expect columns with _right_ margins, not left ones. When I've tried to use grid systems with left margins (i.e. Skeleton), the handles to adjust the grids go all screwy. Taking the same grid logic, but swapping the margins over the right side makes things behave as they should. I think Kube's grid uses left margins, so that could be causing some issues.
- The column system expects that the columns are equal in size.
- We've created custom grid systems for both Susy grids and Bourbon Neat, which both use percentages to define columns in a fluid grid, so I don't believe the units the grid uses are an issue. (in both cases we've got a Sass loop that defines the classes automatically, we've just has to dial in the number of columns)
- When we've worked with layouts with column numbers other than 12, we've just adjusted the number of column classes in the GridFramework class and used setAreaGridMaximumColumns in the template. So there is no restriction to 12 column grids.
- However, without using setAreaGridMaximumColumns concrete5's layout tool will still assume you are using a 12 column grid. I think this behaviour could be improved by automatically using the getPageThemeGridFrameworkNumColumns value returned by the grid framework and setting that to the maximum. In the meantime, it just needs to be specified.
As a sidenote, the reason why we moved away from pre-made grids like Skeleton (and I think Kube) to using Sass driven ones, is that we're able to more easily adjust the gutter sizes. On some sites we've found that once they are full of content we've wanted to adjust the columns to give things a bit more space. With a Sass driven grid framework all we've had to do is adjust a few numbers and re-compile. This flexibility has far outweighed the extra overhead of getting things working in the first place. Just my perspective.
- concrete5's layout tool seems to expect columns with _right_ margins, not left ones. When I've tried to use grid systems with left margins (i.e. Skeleton), the handles to adjust the grids go all screwy. Taking the same grid logic, but swapping the margins over the right side makes things behave as they should. I think Kube's grid uses left margins, so that could be causing some issues.
- The column system expects that the columns are equal in size.
- We've created custom grid systems for both Susy grids and Bourbon Neat, which both use percentages to define columns in a fluid grid, so I don't believe the units the grid uses are an issue. (in both cases we've got a Sass loop that defines the classes automatically, we've just has to dial in the number of columns)
- When we've worked with layouts with column numbers other than 12, we've just adjusted the number of column classes in the GridFramework class and used setAreaGridMaximumColumns in the template. So there is no restriction to 12 column grids.
- However, without using setAreaGridMaximumColumns concrete5's layout tool will still assume you are using a 12 column grid. I think this behaviour could be improved by automatically using the getPageThemeGridFrameworkNumColumns value returned by the grid framework and setting that to the maximum. In the meantime, it just needs to be specified.
As a sidenote, the reason why we moved away from pre-made grids like Skeleton (and I think Kube) to using Sass driven ones, is that we're able to more easily adjust the gutter sizes. On some sites we've found that once they are full of content we've wanted to adjust the columns to give things a bit more space. With a Sass driven grid framework all we've had to do is adjust a few numbers and re-compile. This flexibility has far outweighed the extra overhead of getting things working in the first place. Just my perspective.
Thanks for your valuable insights mesuva, I will take a another look at this and see what I can come up with - especially the left margin issue - that starts to make a lot of sense now with what Im seeing.
Sorry, Away until the 10th September 2015
Thanks Mesuva as always most helpful...!
With regards to left/right margins.... Im curious though as to how this would produce html with incorrect classes applied...
I too am using Pure and is very much like Kube which uses percentags, is not 12 columns, and IS driving me crazy!
Case in point, select add layout with 3 columns set and here is the output
See how the last one is a unit-2 not a unit-3 as it should be? Pardon my ignorance but that doesn't appear to be a CSS issue as a php one applying the wrong class...?
Here is a link to the post I put up, as I'm having the same issues as therenderman in his screenshot where it doesn't really change whether i add $a->setAreaGridMaximumColumns(8); OR $a->setAreaGridMaximumColumns(12); OR $a->enableGridContainer();
http://www.concrete5.org/community/forums/customizing_c5/gridframew...
Atleast not in the sense that its applying incorrrect classes (more examples of incorrect classes being applied in my post)
With regards to left/right margins.... Im curious though as to how this would produce html with incorrect classes applied...
I too am using Pure and is very much like Kube which uses percentags, is not 12 columns, and IS driving me crazy!
Case in point, select add layout with 3 columns set and here is the output
<div class="ccm-custom-style-main grid"> <div class="grid__unit-3"> <div class="grid__unit-3"> <div class="grid__unit-2"> </div>
See how the last one is a unit-2 not a unit-3 as it should be? Pardon my ignorance but that doesn't appear to be a CSS issue as a php one applying the wrong class...?
Here is a link to the post I put up, as I'm having the same issues as therenderman in his screenshot where it doesn't really change whether i add $a->setAreaGridMaximumColumns(8); OR $a->setAreaGridMaximumColumns(12); OR $a->enableGridContainer();
http://www.concrete5.org/community/forums/customizing_c5/gridframew...
Atleast not in the sense that its applying incorrrect classes (more examples of incorrect classes being applied in my post)
Please see the attached you can see a progression adding 1 to 8 columns and the way it splits them up.... VERY odd!
I think you may be misunderstanding how it's breaking the columns down.
When concrete5 starts splitting up the columns it's going to try to divide the number of columns you want into the number you have specified as the maximum.
So if you've set a maximum of 8 columns, the only way to split that up to whole numbers is to do 3+3+2. It's not going to split that area into equal thirds, as you can't divide 8 that way.
With this in mind the output you've pasted in is correct.
Even if you CSS grid uses percentages, you still need to think in columns. Kube might not actually be suitable for concrete5's layout system, after having another look at Kube I wouldn't actually call a css grid system as such, it's more just handy classes to apply percentages.
When concrete5 starts splitting up the columns it's going to try to divide the number of columns you want into the number you have specified as the maximum.
So if you've set a maximum of 8 columns, the only way to split that up to whole numbers is to do 3+3+2. It's not going to split that area into equal thirds, as you can't divide 8 that way.
With this in mind the output you've pasted in is correct.
Even if you CSS grid uses percentages, you still need to think in columns. Kube might not actually be suitable for concrete5's layout system, after having another look at Kube I wouldn't actually call a css grid system as such, it's more just handy classes to apply percentages.
THANK YOU!!!
That is the best and clearest explanation yet! And *click* it now makes perfect sense.
So would it be safe to assume that the system looks for an integer in your class array (ie -2) and tries to add these together to get the column count (ie 2+2+1+1+1+1 = 8).
So really, this system is ONLY ever going to work where a grid uses that style of convention.
What happens when you use a grid with different names? Such as 'halves, quarters, two-thirds etc....? Has anyone tried...?
This seems rather restricting.... Is there a way to make it work and say select 8 columns, it grabs the class from the appropriate slot in the array and applies it to all 8 columns. Likewise 5 columns, it would grab the appropriate class and assign it...
Kinda like this....
Col1
Col2
Col3
Col4
Col5 <--- 5 equal columns - each column gets this class.
Col6
Col7
Col8
Is anything like that possible? Or do we need to make another "Area Splitter" like in 5.6 (an absolute GOD send that!)
That is the best and clearest explanation yet! And *click* it now makes perfect sense.
So would it be safe to assume that the system looks for an integer in your class array (ie -2) and tries to add these together to get the column count (ie 2+2+1+1+1+1 = 8).
So really, this system is ONLY ever going to work where a grid uses that style of convention.
What happens when you use a grid with different names? Such as 'halves, quarters, two-thirds etc....? Has anyone tried...?
This seems rather restricting.... Is there a way to make it work and say select 8 columns, it grabs the class from the appropriate slot in the array and applies it to all 8 columns. Likewise 5 columns, it would grab the appropriate class and assign it...
Kinda like this....
Col1
Col2
Col3
Col4
Col5 <--- 5 equal columns - each column gets this class.
Col6
Col7
Col8
Is anything like that possible? Or do we need to make another "Area Splitter" like in 5.6 (an absolute GOD send that!)
Well it's fair to say that the layout system is intended to be used with _grid_ systems, where it has a specific number of columns.
The actual class names are irrelevant, it's really just the position in the array of class names for the grid that matters.
You could for example have a six column grid system with these column names
col-single
col-third
col-half
col-two-thirds
col-schfifty-five
col-full
What is important is that each column is incremental multiples of the single column.
What you've described where you'd have a list of classes that would be applied to all isn't actually a grid system, it's more of a class/column system. It does sound handy though, but just not something that is currently supported.
Keep in mind too that it's not just the columns that need to be supported, but also the offsets. Using your suggestion, you couldn't have two columns but of different sizes. Again, 12 column grids do handle halves, thirds and six columns.. handling 5 is a bit of the odd one mathematically to handle. I'd personally just create a new page template to handle this.
Technically you could handle it with a 60 column system, but that would be a bit fiddly to get right padding wise just for the sake of handling 5 equal columns!
What you've described is pretty close to what the 'Free-Form Layout' does though already, it just doesn't use your own classes.
The actual class names are irrelevant, it's really just the position in the array of class names for the grid that matters.
You could for example have a six column grid system with these column names
col-single
col-third
col-half
col-two-thirds
col-schfifty-five
col-full
What is important is that each column is incremental multiples of the single column.
What you've described where you'd have a list of classes that would be applied to all isn't actually a grid system, it's more of a class/column system. It does sound handy though, but just not something that is currently supported.
Keep in mind too that it's not just the columns that need to be supported, but also the offsets. Using your suggestion, you couldn't have two columns but of different sizes. Again, 12 column grids do handle halves, thirds and six columns.. handling 5 is a bit of the odd one mathematically to handle. I'd personally just create a new page template to handle this.
Technically you could handle it with a 60 column system, but that would be a bit fiddly to get right padding wise just for the sake of handling 5 equal columns!
What you've described is pretty close to what the 'Free-Form Layout' does though already, it just doesn't use your own classes.
Yes I see your point, we often use 2 classes together but yes these are based on dividing the available space instead of column counts... (ie 75% width + 25% width).
We actually have created a very extensive and very flexible grid using container modifiers to control any padding or lack there of. It's takes it's cue from the likes of Kube & Pure.
This worked amazingly with the area_splitter in 5.6 where we just created as many templates and carried on.
The 'column count' grids are often too restrictive for our custom designs and lack the flexibility we require. Where as we find this grid setup gives us the flexibility and range of options whilst still being incredibly light weight (a fraction of the weight of bootstrap by comparison!) but as we are finding this then limits us in the CMS world. Sigh.
It would be great if we could open up the possibilities of other grid systems as there are quite a few good ones out there that don't follow the traditional 'column count'.
And how is this going to bode when Flexbox is released?! (Bootstrap 4 has this option built in atleast in the alpha release it is...)
We actually have created a very extensive and very flexible grid using container modifiers to control any padding or lack there of. It's takes it's cue from the likes of Kube & Pure.
This worked amazingly with the area_splitter in 5.6 where we just created as many templates and carried on.
The 'column count' grids are often too restrictive for our custom designs and lack the flexibility we require. Where as we find this grid setup gives us the flexibility and range of options whilst still being incredibly light weight (a fraction of the weight of bootstrap by comparison!) but as we are finding this then limits us in the CMS world. Sigh.
It would be great if we could open up the possibilities of other grid systems as there are quite a few good ones out there that don't follow the traditional 'column count'.
And how is this going to bode when Flexbox is released?! (Bootstrap 4 has this option built in atleast in the alpha release it is...)
Layout is important to content design so should be available in the CMS - having access to it in C5 is really cool (and ground breaking in an open source CMS) so I reckon it’s important to get a healthy discussion going.
The issue here is that instead of providing an abstracted conduit to the layout controls in the dashboard, there’s set logic that locks everyone into a certain way of doing things.
Alternatives to the 960 mindset don’t care about units adding up to a total within a row, nor do they care about first and last columns in a row – in fact, they often don’t use row divs at all. Once you've used them, you really wonder why Bootstrap and the like are so popular.
As we all know, CSS layout is currently a bit of a hack because there’s never been built-in tools specifically designed for layout. Therefore, the way C5 assumes all grids are constructed will likely change, especially now that tools specifically designed for layout are almost here - flexbox currently has a 80.97% global score on http://caniuse.com/#feat=flexbox....
A custom mode that bypasses the row/column count logic and lets us name the column variables which appear in the dashbaord (and assign css classes to them) would help ensure we could plug anything into the engine.
Making it a switch would keep the current functionality working.
I opened a git issue on this subject yesterday:https://github.com/concrete5/concrete5/issues/2962... But I may not have explained myself very well as I was a bit frustrated with layouts (sorry c5 team). Hopefully smarter people than I can see that locking this awesome feature into one form of current grid thinking, makes it way less useful moving forward.
Cheers
Ben
Some light reading on the many alternative CSS grids - including a flexbox grid:
https://css-tricks.com/dont-overthink-it-grids/...
http://purecss.io/
https://philipwalton.github.io/solved-by-flexbox/demos/grids/...
The issue here is that instead of providing an abstracted conduit to the layout controls in the dashboard, there’s set logic that locks everyone into a certain way of doing things.
Alternatives to the 960 mindset don’t care about units adding up to a total within a row, nor do they care about first and last columns in a row – in fact, they often don’t use row divs at all. Once you've used them, you really wonder why Bootstrap and the like are so popular.
As we all know, CSS layout is currently a bit of a hack because there’s never been built-in tools specifically designed for layout. Therefore, the way C5 assumes all grids are constructed will likely change, especially now that tools specifically designed for layout are almost here - flexbox currently has a 80.97% global score on http://caniuse.com/#feat=flexbox....
A custom mode that bypasses the row/column count logic and lets us name the column variables which appear in the dashbaord (and assign css classes to them) would help ensure we could plug anything into the engine.
Making it a switch would keep the current functionality working.
I opened a git issue on this subject yesterday:https://github.com/concrete5/concrete5/issues/2962... But I may not have explained myself very well as I was a bit frustrated with layouts (sorry c5 team). Hopefully smarter people than I can see that locking this awesome feature into one form of current grid thinking, makes it way less useful moving forward.
Cheers
Ben
Some light reading on the many alternative CSS grids - including a flexbox grid:
https://css-tricks.com/dont-overthink-it-grids/...
http://purecss.io/
https://philipwalton.github.io/solved-by-flexbox/demos/grids/...
Sorry, Away until the 10th September 2015
Sorry, Away until the 10th September 2015
Sorry, Away until the 10th September 2015
Sorry, Away until the 10th September 2015
Sorry, Away until the 10th September 2015
Sorry, Away until the 10th September 2015
Sorry, Away until the 10th September 2015
Sorry, Away until the 10th September 2015
Sorry, Away until the 10th September 2015
Sorry, Away until the 10th September 2015
<div class="units-container">
<div class="units-row">
<div class="unit-25"></div>
<div class="unit-20"></div>
<div class="unit-20"></div>
<div class="unit-20"></div>
</div>
</div>
So its not CSS classes get corrupted in any way.