Open vleo opened 6 years ago
you write
Bootstrap3 containers should not be nested.
why not? This is one of the many cool features of BS3.
If you want to fiddle with CMS placeholders inside existing BS3 rows or containers, you have to emulate the grid widths for them. This can only be done through the projects configuration settings.
Please refer to the section Adding Plugins into a hard coded grid in the docs.
It's quite unlikely that I'll merge this pull request.
why not? This is one of the many cool features of BS3.
From https://getbootstrap.com/docs/3.3/css/:
Containers: Bootstrap requires a containing element to wrap site contents and house our grid system. You may choose one of two containers to use in your projects. Note that, due to padding and more, neither container is nestable.
Speaking of your approach to handling the issue addressed by the proposed patch -
Please refer to the section Adding Plugins into a hard coded grid in the docs.
Hence we must tell
djangocms-cascade
which breakpoints shall be allowed and what the containers extensions shall be. This must be hard-coded inside yoursetting.py
It seems to me that checking couple/three checkboxes is much easier then patching settings.py
for the project and can be done by a content editor person, as opposed to a python coder.
Another question I wanted to ask - why is it theBootstrapContainerPlugin
and not the BootstrapColumnPlugin
where the breakpoints are set - you still have to set column widths there, why not enable/disablexs/sm/md/lg
for a given column there as well, like it is done in bs3 html code?
You're right. It currently is possible to add a BootstrapContainer
as a child of another BootstrapContainer
, BootstrapRow
or BootstrapColumn
.
This is a bug.
Unfortunately the parent-children relationship code in django-CMS is very static. This means that all possible relationships are determined during bootstrapping the app.
I would like to have a more dynamic approach, one which takes into consideration the current tree configuration. This is my proposal:
https://groups.google.com/forum/#!topic/django-cms-developers/vtsdrMWnUFA
Therefore, before implementing something else on top of this in Cascade, it presumably is better to fix this in django-CMS. I don't like the hack with transparent containers in Cascade, but I had no other choice.
Thank you for your concise answer.
Of course my patch is a quick hack, since I don't have the deep understanding of Cascade architecture. Unfortunately I was not able to find a Wiki or some other developer's / architecture manual for djangocms.
Ideally, I'd rather check if given BootstrapContainerPlugin
is the topmost in the hierarchy of plugins, and then disable "container"
class attribute on it if it's not.
I like you proposal for dynamic (by client JS code + server HTTP API request/reply) evaluation of (+) menu on the plugin widget. Not sure about the exact meaning of REST endpoint, probably meaning having clearly defined HTTP based API defined on the server?
My understanding of your proposal is: Do an AJAX request on clicking the (+) on the plugin widget that populates possible child plugin choices with information received at that moment from the django server (REST endpoint), given that the django server has the ability to maintain dynamic data structure on all possible children allowed under current state of the djangocms plugins tree.
I would try implementing something towards this, but so far I can't figure out how to traverse the djangocms plugins tree, would appreciate if your hint me on that.
Please vote for this proposal on the CMS discussion group by adding your 2 cents.
Traversing the plugin tree is rather easy. Find the root node and invoke .get_descendants()
. More on that API is here: http://django-treebeard.readthedocs.io/en/latest/
But, there is at least two examples of nesting containers on the official bootstrap website : https://getbootstrap.com/docs/3.3/examples/navbar/ , https://getbootstrap.com/docs/3.3/examples/carousel/ . What does the sentence "...due to padding and more, neither container is nestable" really means ?
What does the sentence "...due to padding and more, neither container is nestable" really means ?
In my experience, nested containers resulted in unpredictable (undefined) behavior - namely, nested containers took wrong widthsj (wider then expected) etc. - maybe it was due to padding, I did not investigate, just got rid of nested containers and the layout was back to sanity.
I do not know if it's related, but in the project Insights djangocms-bs4forcascade (bootstrap4); I had to put in _variables.scss:
$ grid-gutter-width: 0px;
After this, the container width, row, column behave better, I did not understand why.
Bootstrap3 containers should not be nested. But if I use the template that provides it's own top level bootstrap "container", for example in order to combine dynamic and static djangocms placeholders:
the required toplevel placeholder cmsplugin_cascase "Container" ends up nested in top level bootstrap container that is coded in the template.
Is there some already existing setting or workarouond I'm missing, or BootstrapContainerPlugin has to be patched in order to maybe add a flag that will replace css_classes.append('container') in its get_css_classes method? I.e. it would have not only 'fluid' / 'non-fluid', flag but also 'cascade only' flag?
I patched cmsplugin_cascade/bootstrap3/container.py to that effect and in case it's the right way to solve this problem I've also created a pull request.