clementrectangle

Forum Replies Created

Viewing 15 replies - 1 through 15 (of 31 total)
  • Thread Starter clementrectangle

    (@clementrectangle)

    Ha, that’s unfortunate.

    We don’t want to go back to the classic Woocommerce cart and checkout, the new block versions are far superior (faster to load, cleaner layout, more optimized for mobile use, …).

    We will look into another solution then, thanks for your answer !

    Thread Starter clementrectangle

    (@clementrectangle)

    Hi,

    I managed to make it work.

    With the provided code snippet, the scelect2 dropdown was correctly moved in the div I chose, but the scroll computation was still on, so the dropdown was moving based on scroll, when it should not move anymore (because placed in the flow of the page, so no need to manage scroll sync).

    I noticed that adding the “position: relative” CSS to the containing form (#forminator-module-*id*) seems to disable the scroll computation (which was my goal), not sure why, maybe this is a condition in your plugin JS checking for parent positionning ?

    With the containing form positionned as “relative”, the dropdown is correctly positionned, without trying to compute its distance from top, so it follows the page flow, it’s not bothered by any fake scroll lib anymore ?? 

    setTimeout(function() {
        jQuery('.forminator-custom-form').trigger('after.load.forminator');
    },500);
            
    jQuery(document).on('after.load.forminator', function( e, form_id ) {
        const formID = e.target.id;
        jQuery('#select-1 select').FUIselect2( { 'dropdownParent': jQuery(    #${formID}) } );
    });

    You’ll notice that I retrieved the form ID from the event too, that way I can move the dropdown directly in the form “owning” it, that way I think it should work with multiple forms on a same page, but I didn’t try. Putting the code here if it can be of any help for other people.

    And you’re right, I had to make some styling on the dropdown, some things were gone, like paddings, or the search field being hidden.

    As I said I think it would be nice to consider adding a filter, or even an option in the plugin to choose between “Place dropdown in body” and “Place dropdown in form”, something like this ??

    Can I ask why this choice to place the dropdown directly in the body, and move it on scroll, instead of placing it in the form directly so it doesn’t have to be moved with JS ?

    Thread Starter clementrectangle

    (@clementrectangle)

    Hi,

    Thanks for looking into this !

    This fix doesn’t seem to work, I think this is related to the way GSAP + Scroll smoother manages the smooth scroll…
    The dropdown position is fine on scroll “ticks”, but since Scrollsmoother adds inertia to the scroll, the dropdown gets missplaced after the last action on mouse wheel.
    I already tried things like this (computing distance from top to fix dropdown placement) but didn’t find a way to make it right…

    To be able to put the website online before fixing this, I used a workaround : when the user scrolls with the dropdown opened, the dropdown is automatically closed, to avoid having it misplaced.

    I set up a GET argument to allow you to make further testing.

    On the normal URL (https://emc.staging.rectangle.net/contact/), you can see the fix I just talked about, closing the dropdown on scroll.

    On this URL : https://emc.staging.rectangle.net/contact/?select2, you can test how it behaves with the fix you gave. (I didn’t put it in a MU plugin, but directly in the JS module managing the contact page, it’s the same but fits my project architecture better).
    I added a console.log() to display the computed distance from top, to better understand what happens.

    Here’s the code I put in the JS module for reference :

    jQuery(window).on('scroll', function () {
        var inp = jQuery(document).find('#select-1 select');
        var distance = inp.offset().top + inp.outerHeight()
        console.log('Manage select2 on scroll, distance: '+distance);
        jQuery('.select2-container.forminator-select').css('top', distance);
    });

    I really think the proper way to fix this would be to add a filter or something to your plugin, allowing to choose a custom container for the select2 dropdown instead of <body>, using the existing “dropdownParent” property of Select2.

    I guess you’d have to set a second filter, to allow to disable the dropdown displacement on scroll : I think that if the dropdown is in the same div that the original select, it would only have to be placed once, and wouldn’t have to me moved around on scroll.

    Anyway, I’ll keep the “auto-close” fix for now, so you have time to look into a proper solution around smooth scroll systems (I think the problem would be the same with most libs faking the scroll, not only GSAP).

    Thanks !

    clementrectangle

    (@clementrectangle)

    Hi,

    Came here for the same problem, I installed the beta version you provided, but it seems the deprecated errors are still there.

    I still get those 2 errors on every page load :

    Deprecated: Creation of dynamic property Mailtpl_Customizer::$defaults is deprecated in?/plugins/email-templates/includes/class-mailtpl-customizer.php?on line?49

    Deprecated: Creation of dynamic property Mailtpl_Mailer::$opts is deprecated in?/plugins/email-templates/includes/class-mailtpl-mailer.php?on line?49

    I looked in “class-mailtpl-customizer.php”, and it seems the problem hasn’t been fixed : you need to declare this “defaults” property before using it :

    private $defaults;

    Thread Starter clementrectangle

    (@clementrectangle)

    Thank you, it worked regarding the table creation : using the shortcode you pointed out and loading the page created the table just fine ??

    I still used your second technique to avoid loading the front_builder at all, we don’t use it, so it’ll be lighter that way.

    Sadly, it didn’t fix the problem I had originally… I thought it was related to the error with the table missing, but it seems it wasn’t.
    I’ll continue to look into it, and make a new topic if I can’t fix it myself, regarding this current topic, the table missing problem is resolved !

    Thread Starter clementrectangle

    (@clementrectangle)

    Hi,

    Have you changed something about it in a recent Woocommerce update ?

    After noticing that it worked on the test website with no plugin enabled and storefront, I re-did the statistics deleting and reimporting on the production website, to confirm the bug was still there on this one, and the statistics seems to be back at normal…

    I don’t get what changed in the meantime, I’ll investiguate and let you know if I find anything usefull to know.

    Thread Starter clementrectangle

    (@clementrectangle)

    Hi,

    I followed those steps, but unfortunatly it didn’t fix the issue.

    When clicking on “Delete previously imported data”, I see a message saying that the previously imported datas will be deleted, but I still see “0 of 0” if I don’t uncheck “skip previously imported” (even after reloading the page), would that mean that the datas aren’t correctly deleted ?

    Maybe I could provide a test website with credentials so that you can see it by yourself ?

    Thread Starter clementrectangle

    (@clementrectangle)

    Hi,

    Yes, that is correct.

    Here are 2 screenshots of the Statistics pages :

    And here is the system report from the production website. I could provide the staging website report if required, where all plugins but Woocommerce are disabled.

    https://pastebin.com/JikuNaiN

    Thread Starter clementrectangle

    (@clementrectangle)

    The background colors problem was apparently because I didn’t select a sample order, after selecting a sample order they appear. I think there was a fatal error or something with no sample order selected.

    One other thing : the sliders allowing to choose the size of paddings or max-width of logo and such are pretty hard to use, I think it would be really usefull to be able to type a value with the keyboard. I wanted the logo to be 100px wide and had to use the developer tools to write “100” by hand, I couldn’t reach this value with the slider.

    clementrectangle

    (@clementrectangle)

    I’m trying to do the exact same thing, just leaving a message to follow replies ??

    Thread Starter clementrectangle

    (@clementrectangle)

    D’accord je vais faire ?a, comme il s’agit d’une fonctionnalité qui si je ne m’abuse est présente aussi sur la version gratuite, je pensais que ?a avait sa place…

    Thread Starter clementrectangle

    (@clementrectangle)

    Yes I know, I can’t warp my head around this neither ??

    When I desactivate the plugin, or check the checkbox to disable automatic files deletion, the problem stops.

    What is bugging me is that it’s not a file that is being deleted and recreated, it’s the “wpcf7-files” folder itself. If it was a file, I would have supposed the same : someone is uploading and deleting a file again and again.

    And the strangest thing in this is when the folder gets recreated wiuth another linux user as owner. The website is run by the www-data user, and all files created by WordPress or plugins are created with www-data as owner, but sometimes, randomly, the “wpcf7-files” folder is recreated but owned by one of our admin users… That particular problem may be with our server configuration, but I’ve never seen that happen.

    Actually, that’s the detail that pointed me to the problem : when the folder is owned by the admin user, it’s not writable anymore by www-data, so file upload stops working on the form.

    I disabled automatic deletion anyway, and I’m now cleaning the “wpcf7-files” folder with a cron job, so this is not urgent, is working like this, but I was very curious to understand what happens ??

    Thread Starter clementrectangle

    (@clementrectangle)

    Ha !

    With that code, I can easily disable SVI for simple products only and get my Alt texts back ??

    Thank you for the help, very appreciated !

    PS : If anyone has the same problem and find this thread : the very easy condition to set in David’s snippet is : if ($product->is_type( ‘simple’ ))

    Thread Starter clementrectangle

    (@clementrectangle)

    I tried to add the following elements to simple products forms as a workaround, by modifying default simple.php woocommerce template :
    – the “variations_form” class on the form
    – the “data-product_id” attribute on the form (filled with the right ID of course)
    – a “reset_variations” button in the form, with display:none; since it’s not usefull on simple forms

    But no luck, the error is still there…

    Thread Starter clementrectangle

    (@clementrectangle)

    Hi,

    The problem is that most products on the website are not variable product, but simple ones… So it’s normal that the variable product form isn’t there.

    And I just noticed that the fallback to the default theme display is a PRO feature. I also noticed that we can disable SVI for a specific product in the Advanced tab, but since it’s not accessible from the bulk modify, we would have to disable it on every products one by one…

    It seems to me that it makes the free version of your plugin pretty unusable ??

    Isn’t there any way to fix this error for simple products, so that Alt texts are correctly applied to product images ?

Viewing 15 replies - 1 through 15 (of 31 total)