[#32055] Add advanced parameters to module chromes

[Bakual]

Issue

Each module has some general parameters in the "Advanced" tab:

• Module Tag
• Bootstrap Size
• Header Tag
• Header Class

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.

Proposal

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.

Testing

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.

Tracker

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

[roland-d]

@test: The new PR works as described. After applying the patch I can set the advanced parameters and they are applied as expected.

[peterlose]

test. Works as expected!

[phproberto]

Feature merged in 3.4-dev branch: f72f6fb

Thanks!!

[infograf768]

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

[Bakual]

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.

[infograf768]

There were also some bad values in the default demo data, which I fixed in an earlier PR.

That was it...