-
Posts
-
There have been some requests for being able to place a Masonry Gallery on a color section layout element in the Avia Layout Builder.
I have a solution, and it’s not terribly difficult, but it requires some diligence to manage the gallery with updates and your ability to edit short codes directly. If you are not comfortable with this, DO NOT try this at home. You will/might loose all the code for your Masonry gallery and will have to rebuild it again in Avia Layout Builder. A bummer. You’ve been warned. :-)Here is what worked for me to achieve a framed gallery that is a default 1000px wide centered in the main content area and browser window. The code below produces the screen capture attached. The key thing that makes it work is wrapping the Masonry Short code inside a DIV and manually pasting the Masonry shortcode inside
[ av_one_full first ]
You will have to do this in the editor directly after you have built your Masonry gallery in the Avia Layout Builder.[av_section color='main_color' custom_bg='#433A08' src='' attachment='' position='top left' repeat='no-repeat' attach='scroll' padding='default' shadow='no-shadow' id=''] [av_one_full first] <div> [av_masonry_gallery ids='38,39,37,36,35,34,13' items='24' paginate='pagination' size='fixed masonry' gap='large' overlay_fx='' caption_elements='title excerpt' caption_display='on-hover' container_links='active' id='' custom_class='noLightbox floatbox naked fbsquarecorners'] </div> [/av_one_full] [/av_section]Ignore the custom_class settings above. They are for the site here, not yours. Leave it blank, unless you have special classes assigned to your Masonry Gallery. 99% of the folks will probably not have any, so don’t worry about it.
HERE’s the CATCH! The caveat is If you go back and edit your Masonry Gallery with the Avia Layout Builder at a later date, the edits to your manually added DIV wrapper will be overwritten when you save the revised Masonry Gallery with the Avia Layout Builder. This is either a bug, or done by design. I don’t know. So keep all of the template structure and code cut and pasted as a backup inside a text editor. When you have revised your gallery, overwrite your new short code revisions by pasting them inside the
[ av_one_full first
tags in backup file.Please realize this is not an official way to edit the Masonry gallery, so if you have issues, you are probably on your own with regards to support. Try it. If it works for you great. If not, Oh well :-(
Good luck.
I thought I would mention one other thing. Please do not use any of the images in that screen capture. They are not stock photos. I’m making a tribute gallery for my deceased dog and the photos are mine. I doubt anybody would use them, but I thought I would mention it because you never know what will show up in Avatars online. Thanks for respecting this.
Hey!
Thanks for posting your solution. Personally i have not tried it but other users can try it at their own risk.
And sorry for your loss.Cheers!
Yigiti found a similar solution: give your grid an id and use some css:
#home-masonry { max-width: 1210px; float: none; margin: auto; } @media only screen and (min-width: 1800px){ .responsive.html_stretched .av-masonry-entry{width:24.9%;} }@maratino Thanks for the tip. I will add one thing here to your post. IE 8 can have issues with max-width. It may not happen with your code, but folks should be aware of some max-width issues with IE 8. Usually it’s with an element with overflow:hidden. And for sure it has issues with < img > max-width when the widths and heights are specified. In that scenario it works in compatibility mode, but not in standard mode. There are additional oddities with IE 8 that a Google search will highlight as well. I share this tidbit so that if someone has weird things happening in IE 8, they might want to take a gander at max-width. It has troubled us on many occasions.
Having said that, we have definitely experienced some issues with some max-width properties in Enfold. I’ve meant to bring it up, but haven’t had the time. Perhaps I might start a separate thread, but specifically, in the base.css file, there is a global property on < img > with max-width set to 100%. It’s near line 150ish (I’m recalling this from memory). We have some dynamic content being inserted into areas of Enfold with Ajax and callbacks, and the max-width property is not recognized in IE 8. No image renders in the browser. This is a separate matter for another thread, but I thought I would bring it up as an example just in case some folks experience some odd issues in IE 8.
Hey!
We have a few things in place to help IE8 along with the max-width issues. Specifically the backslash hack for defining the width instead of max width.
If you do find cases where its still failing to render let us know and we’ll add in the fix for the next release.
Regards,
DevinWe had some issues with with max-width on the base.css file. Specifically, we have a script that automatically generates thumbnails for youtube videos with a ‘play’ button graphic. It also removes the ugly black bars with the thumbnails generated by Youtube for non-16:9 videos and then links the video into a lightbox style popup window to play them. Upon completion of the video, it automatically closes the lightbox window, so no nasty advertisement popups appear in your face. It does this automatically with no interaction by the website visitor. Smooth, nice and unobtrusive. So there are Ajax callbacks happening to refresh the page content at various stages. The play button graphic has difficulty appearing centered in the thumbnail image using the enfold template upon loading. Something that doesn’t occur when we hand-code a lot of Youtube video links in our own web page. We’ve loaded 40-50 Youtube thumbnails on a hand-coded page with no errors, picture perfect thumbnails and the play graphic dead centered in the thumbnail. And that’s working on Localhost too! Sniffing around your CSS, it may be narrowed down to the img CSS inside Enfold, but I haven’t completely nailed it down. In IE, the thumbnails simply wouldn’t show up, until I comment out the following line in base.css Line 152
max-width: 100%;So how important is this line to Enfold’s performance?
Do you have the CSS properties set at 100% for a reason? Is it important for responsiveness perhaps?
Curious. Commenting out that line cured the IE problems, but we still have the issue with our transparent play graphic not centering in the middle of the thumbs.I realize this is a site specific problem and probably not a major issue with 99% of the folks that have your template, but I would like some input about why the settings are set at 100% so we can look at options on our end. It would also be useful to know if we have overlooked some CSS properties inside the various Enfold files that may have an impact on what I’m describing. I apologize but I don’t have a link online for you to look at. I may be able to put up a test page on a server to illustrate what I’m talking about. It would also show you a rather nifty script that is far superior to the lightbox clone you’re using. It’s very full-featured, has it’s own Ajax library with lots of nifty functions for advanced webmasters and the documentation and support is like no other script online. It’s been around for a very long time too. I figure you folks are vested in your current lightbox script, so I haven’t brought it up, but this one is light years ahead of the one you’re using. Not even close. I changed the entire look of the lightbox to black with one property setting. I saw a thread asking about putting the “title” attribute into the caption area of your Masonry script.
With this script, it’s one simple attribute/option to set and you’re done. No javascript to code inside your functions. It snags the title attribute and loads it into the caption area automatically. It’s good-to-go out of the box.Anyway, I thought I would expand on your question about max-width. This is one of the circumstances where we had issues with max-width, so if it’s not necessary for the performance of Enfold, then you folks might want to consider changing it due to it’s historical problems with IE.
Cheers,
DonHere are some screen captures visually depicting my comment above in post id#184636
1. A hand-coded from scratch thumbnail gallery showing a part of my Youtube video gallery. This file resides outside of the WordPress environment and is fetched by an Ajax call. There is no < head > or < body > in the fetched HTML. It’s straight HTML with the CSS snagged from the parent page which hosts the < a > and href call firing the lightbox overlay hosting all the thumbs. This is illustrated in the screen capture below. Even with this complex Ajax fetch which requires perfect coding to execute correctly, no errors can be found with the automatically generated play graphic overlaying the automatically generated Youtube thumbnails. They are centered correctly. Compare this to the thumbnail in Item 4. below which shows the play graphic shifted downward in an Enfold template. Something in the CSS is affecting it and I haven’t nailed it down yet.
2. An example of the lightbox window that opens when clicking the thumbnails.
3. Enfold themed page with video thumbnail and comment section.
4. And here is the bottom of the page and an example where the play graphic shifts downward due to some CSS properties in Enfold. See red arrow. If img-width: 100% was not commented out in base.css, the thumbnail would be 480px wide and part of the graphic would reside outside the darker opacitized text content area on the right side of the page. FYI, 480px is a default size for youtube thumbnails in their API and my CSS shrinking the thumbnail is ignored in IE due to img-width: 100%
5. Point five is not related to img-width, but I thought I would share a tidbit about the CSS in your Comments system while I’m thinking about it. You may want to consider giving the .comment-entry CSS a property of display: inline-table;
It will vastly improve the flexibility of your comment layout for users. Right now, the entire parent Div will not expand and contract dynamically. For example, if you use the Ajaxify plugin recommended in your forum by Dude, the parent Div hosting the comments entry will now expand and contract like it should if displayed as an inline-table. The colored background DIV will work great and scale up and down. With the current CSS in Enfold, it does not. So clicking on “reply” or add a comment creates a big dynamic hole in the background where the comment form appears. The colored background properties are transparent and do not expand and contract due to the current CSS properties on .comment-entry. I am sorry, but all of this is being developed on Localhost and I have no public link to show you. The concept of an inline-table setting should not be hard for a coder to visualize if they know CSS. Pass it along. They will get it and it will add up.And finally, the reason for showing you all these screen captures, is maybe lost in all the text here. It can be boiled down to two things:
6A. I am looking for some direction working around img-width: 100% as it relates to Enfolds performance. Is it important?
6B. What global CSS property might be shifting my play graphic downward? Point me in the right direction among your CSS files. I will probably figure it out from there.
Cheers.
If we can see the site live we can inspect it and go from there. Without context and working code the above is pretty unreadable for me at least, though I don’t know about other support.
IE8 support is pretty quickly going to be null anyway so if you don’t want to use the ie8 hack you don’t really need to.
- The topic ‘Solution Found: Hack/Workaround for fixed-width, non-fullframe Masonry Gallery’ is closed to new replies.