Forum Replies Created

Viewing 30 posts - 1 through 30 (of 61 total)
  • Author
  • in reply to: WooCommerce 3.0 und Enfold #775451

    Sorry, but you still don’t get it. This is not about Enfold not benig compatible. These things happen and you or me don’t have any problems with that because of the way we work. But other users obviously do.

    This is about communication. And at least in the few threads I have opened I have never seen any “official” acknowledgement of the problem. Actually, you have been the only one proposing solutions and helping other users as far as I can tell. This is very nice of you and I salute your for that. But wouldn’t it be time for someone from the Kriesi staff to handle this?

    You are right, the changelog is not the end of all things. But usually looking into the changelog and checking if there are any stickies in the forum should be enough to verify if any serious problems exist.

    in reply to: WooCommerce 3.0 und Enfold #775422

    We have to rely on the changelog if we don’t want to do a testinstallation for each and every update (simply not feasible nor practicable). And if that changelog states the current version is fully compatible with WC 3.0 we have to be able to rely on that too.
    It desn’t matter if Woocommerce is the focus or a minor feature in Enfold, as soon as major problems occurs and the official stance is “nothing is wrong, but try this fix” it makes you think how reliable Enfold might by in other areas too.

    in reply to: WooCommerce 3.0 und Enfold #775381

    I fully support Adrian’s request/standpoint The way the whole WC 3.0 issue is being handled is vey bad and puts Enfold in a (unnecessary) bad light. The Woocommerce support of Enfold was always a bit lacking and the latest issue seems to indicate that Woocommerce has no priority in Kriesi’s development at all. It would be reassuring to hear, or better yet, see otherwise.

    @mensmaximus I should have said “restore the old plugin version from backup”. But in any case, every webdev should do backups right before major (plugin-)updates and check the outcome. If its not ok, you can and should restore the backup. If too much time has passed and things have changed since then (and this shouldn’t be) you can restore just the plugin.
    Creating a child theme is not the right recommendation for people who haven’t done so right from the (development) start, imho.

    .. or Woocommerce to fix it ;-)

    @georgcornelius reverting back to woocommerce 2.6.14 is much more hassle than the five simple steps I provided above

    Sorry, but simply not true. Just restore a backup and wait for Kriesi to fix this. Everything else is just a bad hack.

    Hi Victoria,

    awesome, this really helps. Thank you very much!


    Hi Victoria,

    I found it’s even easier to use the selector Firsh recommended, i.e. “.justified-image-grid a”
    and place that under “exclude” in the lightbox activation script in js/avia.js

    		$.fn.avia_activate_lightbox = function(variables)
    			var defaults = {
    				groups			:	['.avia-slideshow', '.avia-gallery', '.av-instagram-pics', '.portfolio-preview-image', '.portfolio-preview-content', '.isotope', '.post-entry', '.sidebar', '#main', '.main_menu'], 
    				autolinkElements:   'a.lightbox, a[rel^="prettyPhoto"], a[rel^="lightbox"], a[href$=jpg], a[href$=png], a[href$=gif], a[href$=jpeg], a[href*=".jpg?"], a[href*=".png?"], a[href*=".gif?"], a[href*=".jpeg?"], a[href$=".mov"] , a[href$=".swf"] , a:regex(href, .vimeo\.com/[0-9]) , a[href*=""] , a[href*=""], a[href*="iframe=true"]',
    				videoElements	: 	'a[href$=".mov"] , a[href$=".swf"] , a:regex(href, .vimeo\.com/[0-9]) , a[href*=""] , a[href*=""], a[href*="iframe=true"]',
    				exclude			:	'.noLightbox, .noLightbox a, .fakeLightbox, .lightbox-added, a[href*=""], .justified-image-grid a',

    Is there a way now to do this permanently, i.e. via function php so it survives theme updates?

    Hi Victoria,

    you can see an example of a double lightbox here: (Purchase code hidden if logged out) -deutschland/
    (clicking on the thumbnails below the main cover).
    So according to Firsh’s recommendation I would like to exclude the imgaes with rel=”Jig[1]” from the Enfold lightbox.


    in reply to: Full sized product category images #750437

    Hi Ismael,
    seems to work fine, thank you so much!

    in reply to: Script conflict with EventOn #715653

    Never mind, I have found the problem. It was a faulty entry in the function.php.

    Thanks Yigit!

    Yeah, right. You answered the last ticket before mine at 8:56 and my 3 tickets between 8:57 and 8.59. As I said, this is exactly 2 minutes.

    And instead of definding your poorly done support job now, how about going back to topic and thinking about my question for a minute? At least try to understand it. Again, I am not asking for any changes or any customization. I am pointing to the fact, that there is something not right with the sorting of the search results and I want to know why. No customizaton necessary to answer that question, only understanding.

    in reply to: reduce the number of columns at certain breakpoints #689793

    Hi Yigit, thanks again. But honestly, whatever I’ll do via CSS can only gloss over the fact that these templates are not fully responsive with a true content choreograpy. So I’ll have to come up with a replacement anyway :-(

    in reply to: reduce the number of columns at certain breakpoints #689771

    Hi Yigit, thanks for that, but going from 5 columns down to 1 is not really desirable UX and natuarlly I’ve tried all that before.

    Seeing as this a major issue with Enfold itself (Kriesi seems to have designed the shop templates with 3 columns in mind only) and considerig all the other issues we have (all are shop related) we will have to replace the theme for future shop projects. It simply is not on par with others for Woocommerce. It is still the best coded theme out there, but not for shops :-(

    in reply to: A few woocommerce issues #689200

    Hi Andy, achieve what, what customization? I am talking about a snippet postet by Ismael, not a customization I want. Ismael’s snippet doesn’t seem to be working correctly, so maybe we should ask him?

    in reply to: A few woocommerce issues #689125

    Hi Andy,

    since moving the sidebar to the right is done via function.php, this issue cannot happen in another theme.

    Andy, ich schreibe immer auf Englisch, damit ander etwas von unserer Konversation haben, aber nur ganz kurz, zur bessere Klärung: Das oben gezeigte Snippet stammt von Ismael und wurde schon öfter im Forum empfohlen
    Aber die definition der Sidebar

    function avia_add_sidebar() {
    	if(is_product()) {
    	$avia_config['currently_viewing'] = "shop_single";

    scheint dabei nicht zu klappen, denn es werden eben nicht die Widgets aus schop_single genommen. Ich meine schon mal etwas diesbezüglich hier im Form gelesen zu haben, finde es aber nicht mehr und damit auch nicht die evtl. gefundene Lösung. Herzlichen Gruß, Michael


    I am calling bullshit on that one now. It took you a mere 2 minutes to answer 3 of my tickets, so you didn’t even read them. Your answer to this ticket makes it very clear, that you have been too lazy to read and understand the question. Because that’s what it was, a question and not a request. I don’t want any customisation here, I am pointing to an irregularity in behaviour. And you should be interested in that, as it is your job to find such irregularities, confirm them and report them to your boss @kriesi, if they turn out to be of interest to others too.

    But you didn’t even get that. So let me put my question in very simple words:

    When you search for something, the search widget displays realtime results while you are typing. It displays some results in the order result A, result B, result C. Then you hit enter. The Enfold search result page opens. You see the results ain a different order, e.g. result A, result C, result B. Why ist that.

    This is not correct. Call it a bug, call it whatever you like. But I haven’t asked for customisation , so don’t call it that to get it out of the way. As I have writtten, it a rather small issue. But if you don’t even bother to understand it in oder to weigh it’s importance and report it or tell me that it’s to small of an issue to be reported, then your are wasting your time and mine here.

    in reply to: reduce the number of columns at certain breakpoints #689072

    So, you are telling me that this is the intended behaviour for the Enfold shop layout? That’s what Kriesi intended and it is fine?

    in reply to: disable the parallax effect on the shop category page header #689069

    Ok, I understand

    in reply to: A few woocommerce issues #688615

    Really? After 5 days all I get is “open different tickets for different issues”? These question are all abou the same site, and you want me to fill out 4 tickets, each with the accces data and so on? Seriously? Well then….

    Ok, btt, issue 1.:

    Have a look here:
    And have a look here: and look into the “Single Product Pages” widget. You will see that the widget I placed there is not shown on the product page.
    And as you cann se in the code snippet, the sidebar clearly should show “shop_single” – but it doesn’t.

    Not sure how else I can explain this, if you don’t even bother to look.

    in reply to: A few woocommerce issues #686271

    Oh, before you ask regarding issue 1. – I have moved the sidebar to the right, but I did it according to the available instructions and it should be correct and should work.

    // adjust settings on init
    add_action('init','ava534345953_init', 50);
    function ava534345953_init() {
    	add_action( 'woocommerce_after_single_product_summary', 'avia_add_sidebar', 25);
    function avia_close_image_div() {
    	echo "</div>";
    function avia_add_sidebar() {
    	if(is_product()) {
    	$avia_config['currently_viewing'] = "shop_single";

    I think I understand now why Kriesi calculates the image the way he does, ’cause the calculation has to work no matter where the parallax section sits. E.g. if it is NOT the first row on a page, the image indeed has to cover the whole browser height.
    I am so used to having the first row as parallax image and a transparent header on top, that I didn’t think about it more.

    BUT, that doesn’t mean you/he shouldn’t consider applying another calculation for the first row (the header section if you will), because there the image always is smaller than the parent section and so it’ll always cut of the bottom.

    Hi Josue,

    I’ve been fiddling a little with the javascript, but since I am no java programmer, I can only try minor things and all those didn’t have the desired effect (the image was scaled correctly, but wasn’t positioned at the top anymore and so on).

    So I’ll have to wait if you guys or Kriesi comes up with anything, otherwise I’ll have to make use of some plugin do do what we need.

    I am having the same issue at another customer’s website, there we make use of the category headers in the shop.

    We have stopped using other theme mostly because Enfold is the best, most complete and very well coded. But the parallax is not on par with others. For example they do it right: (and they have one of the very very few themes, that come close to Enfold – but they all use VC and I try to avoid it)

    At “scale-to-fit” it does apply the class “avia-full-contain” but if you select “no-repeat” it gets “avia-full-stretch”. Scale-to-fit almost never makes sense unless you have a square background image.

    And regarding the parallax calculation, that is not a feature request per se, but a hint, that something is not done the best way. Nobody would vote up some technicality like that, so it would be rather futile…


    Hi Ismael,

    The height is calculated based on the browser height multiplied by avia-parallax-ratio plus the parent section height.

    I know, that’s exactly what I am saying is wrong resp. not very elegant. It would be better to ONLY use the parent section height multiplied by avia-parallax-ratio. Since we have no influence on the latter and cannot make that negative, the image size needed can never be higher than the parent section height and that is either fixed or a percentage (25%,50%,75%,100%) of the browser height. So if Kriesi would change the script to only use the parent section height for calculation, the whole thing would make much more sense.

    I am not against the usage of “cover” there, it make most sense most of the time, but without a proper height calculation the positioning of the image is almost useless.

    But apart from that, I still would prefer to be able to choose cover, contain or 100% – and surely will have to live with the results ;-)

    This is only set if you select the “Stretch to Fit” option.

    Not true, the avia-full-stretch class is always applied to any parallax image, no matter what you set in the options (e.g. see here So it is a bug, right?

    in reply to: Logo on mobile to big on FF, fine in Chrom #588945

    Thanks Yigit, didn’t know about the .avia-mozilla class, easy then…



    in reply to: Sticky fullwidth Submenu at the bottom of the screen #587480

    Hi Ismael,

    it does look good and works, so I decided to stop calling it a workaround and think of it as a solution now ;-) So I am fine, thanks a lot.

    For all others: As written above I wanted to have a submenu below the slider on this site:
    Instead of some complicated fiddling with the header height, the top-margin of the submenu when scrolled to top and so on I simply set the submenu to 72px height and moved the whole slider container up by 72px:

    #top .av-submenu-container { height: 72px; } 
    #fullscreen_slider_0  { margin-top: -72px; }

    The slider is cut off those 72px at the top, but I can live with that.



    in reply to: Sticky fullwidth Submenu at the bottom of the screen #585497

    Found a quick and dirty fix for the time being:

    .avia-builder-el-0.av-minimum-height-100 .container, .avia-builder-el-0.avia-fullscreen-slider .avia-slideshow {
        margin-top: -72px;

    This essentially pushes the 100% container 72px to the top, cutting of the top of the slider, but I can present this to our customer in the hopes that you guys have a better solution for me.

    The way I see it we could either change the script for the sticky fullwidth submenu OR we could shorten the 100% container by 72px.
    In any case, I didn’t find any way to do it, so I am still hoping you have an idea.



    in reply to: Sticky fullwidth Submenu at the bottom of the screen #584775

    Hi again,

    I had another look myself at how the sticky fullwidth submenu script works, but as a non-programmer I couldn’t figure it out how to change the top-margin the script gives the container when scrolled up :-(

    So any input is more then welcome :)



Viewing 30 posts - 1 through 30 (of 61 total)