I am testing 1.4 RC on a client website (staging though!), and noticing a lot of things that seem to be breaking changes, requiring many different fixes / adjustments after upgrading. I’m worried about the impact this will have to people who have several sites or more already using Bricks.
I realize of course Bricks is still in its infancy and there will be breaking changes, but this just seems like a lot of them at once and I’m not sure if it’s just me and maybe I designed my site poorly (my first real site with Bricks so far), or if it’s something bigger, but I guess just raising this for discussion and hopefully this will be considered. I love that there was a converter included which is great, although it didn’t really work for me either (see point #4 below).
I’m not sure if these issues have been reported before or if they’re simply breaking-changes which are to be expected, so please forgive me if I’ve missed these being reported previously.
Some examples of what I noticed when comparing between prod (1.3.7) and staging (1.4 RC2):
The converter doesn’t seem to work for me, as it didn’t do a find & replace in the CSS for previous class names and convert them accordingly (maybe I misunderstood the point of the converter, but I assumed it’d go through the CSS to find matching custom CSS to Bricks classes and then convert them accordingly if it matched any Bricks CSS classes). For example, I had some custom CSS on a pricing table which wasn’t converted and thus it looks quite different now too:
Hi Dustin,
1.4 brings a whole bunch of changes, mostly due to the community’s desire to remove the element wrappers. Taking this step for 25% of the elements at first, then another 25% in the next version… doesn’t really make sense.
Apart from that: if your site has no problems so far and you don’t want to use any of the new features, you don’t need to update it. If you start a new project, you probably won’t start with a 1.3.x version
Now to your problems:
1.4 beta: Container width 100% - other adjustment than in 1.3.7 - #4 by timmse The problem is that only the root container gets a width. This makes the inner containers more flexible, but also ensures that if you overwrite the width with 100% or vw, all other inner containers follow. You can still use the 100% or vw and as a 4th option just add the root class to the inner container that holds your content.
Good catch, apparently for some reason there is a ::before pseudo-element added that I don’t know why it is there. I’ve added it to the bug tracker.
If you compare the same slides you’ll notice the same issue Since Bricks 1.4 you can place the dots and arrows where you want, i.e. outside the testimonial element, slider, or carousel (which was not possible before, but it’s currently not mentioned in the changelog ). Set them to bottom: -30px or something, so they won’t overlay at any time. Currently, their position is the default “bottom: 15px”.
Totally agree! Happy to see Bricks making improvements and ripping off the proverbial bandaid, going all-in.
That’s difficult to do in practice the moment a feature of a newer version is needed or even if security issues are later known and fixed in future versions, but I understand the point you’re trying to make - that we aren’t required to upgrade and can postpone to temporarily avoid a headache.
I’ll test this out hopefully tonight and see if I can quickly fix those then. I’d assume Theme Styles could be used for this but I suppose not and would require effort to look at all inner containers individually. It’s interesting as I had assumed if I didn’t set a specific width that it would not be modified with this type of change, and that it’d perhaps only result in a full width if I actually had purposely set it to be full width. I’ll test this more though, maybe there’s a concept I’m just not understanding yet on the relationship between the different ‘types’ of containers. Thank you for the detailed response there btw.
Excellent, glad to know that’s on the radar now and am happy to have raised that one for attention. Hopefully it’ll be fixed for the final 1.4?
Ah very interesting, good catch. I’ll check that out! Glad to know that’s a feature added in 1.4 (definitely would be nice to see that in the changelog though, lol).
Do you mean to say that with that CSS on a pricing table element, if you run the Converter in Settings it’ll update them for you in your test? I wonder why it isn’t doing that for me then. Strange.
Thanks again for the detailed reply, I appreciate it! I hope it didn’t come across as me complaining earlier, haha, was just worried there may be some things not yet fully considered, and that there may be more breaking-changes than fully understood by the changelog, so having that all called out would be beneficial. Plus as it turns out I guess there was some bugs identified from my post too which at least makes me happy I was able to help in some small way. Haha. I definitely love the direction Bricks is heading in, and am happy to try and contribute however I can. Thanks for listening and helping.
). Set them to bottom: -30px or something, so they won’t overlay at any time. Currently, their position is the default “bottom: 15px”.
I definitely love the direction Bricks is heading in, and am happy to try and contribute however I can. Thanks for listening and helping. 