User tests: Successful: Unsuccessful:
Each module has some general parameters in the "Advanced" tab:
This parameters are meant to be supported by the templates module chromes. However most chromes don't support this parameters. The only one which currently supports it is the html5
chrome. You can test this by setting the "Module Style" to html5
.
This PR adds this parameters to some more chromes where it makes sense.
For Isis and Protostar this is the well
chrome and for the system chromes it's the xhtml
chrome.
With this new parameters, the xhtml
chrome actually does the exact same thing as the html5
one.
After applying the patch, play around with the advanced settings and see if it works.
Also make sure nothing changes in appearance as long as you don't change the module settings.
This is an alternative solution for the issue raised with http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=32055
Title |
|
test. Works as expected!
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2014-07-09 21:41:29 |
This has created issues when Bootstrapsize was set to 1 in the modules parameters.
1 was considered as one column 100% size of the container.
code is
$bootstrapSize = (int) $params->get('bootstrap_size', 0);
$moduleClass = $bootstrapSize != 0 ? ' span' . $bootstrapSize : '';
It is now a %
.row-fluid .span1 {
width: 6.382978723%;
*width: 6.3297872336383%;
}
This will break many sites
This has created issues when Bootstrapsize was set to 1 in the modules parameters.
1 was considered as one column 100% size of the container.
code is
"Bootstrapsize 1" never was meant to be 100%. It was always meant to be "1/12 size of the available space". If you need the full width, you have to either set it to 0 or 12. 0 is the default value.
Until that PR, the setting didn't do anything at all for those module positions/chromes.
So yes, it is possible that the user has played around with it and set it to some stupid values. Then it suddenly will change the appearance of those modules as soon as the user updates to 3.4.
Unfortunately that is not something we can solve on our end.
There were also some bad values in the default demo data, which I fixed in an earlier PR.
There were also some bad values in the default demo data, which I fixed in an earlier PR.
That was it...
@test: The new PR works as described. After applying the patch I can set the advanced parameters and they are applied as expected.