Forum Replies Created

Viewing 15 replies - 1 through 15 (of 62 total)
  • Thread Starter webwitnl

    (@webwitnl)

    Hmm, placing a new order will decrease stock though. It also worked without problems for quite some time until recently.

    Thread Starter webwitnl

    (@webwitnl)

    Thanks, that fixed it for me!

    I don’t really need to cache the rest api so I’ll leave it off, but I guess that cache should be updated after a new order?

    Thread Starter webwitnl

    (@webwitnl)

    JNKNSKTM

    Thread Starter webwitnl

    (@webwitnl)

    Yes yes, giant delay on the backend by GfW is caused by GTM kit on the front-end inserting an external <script> and little json for google, got it. So now you can close the ticket.

    Thread Starter webwitnl

    (@webwitnl)

    None of that is correct. Backend. See OP for trace.

    Thread Starter webwitnl

    (@webwitnl)

    I doubt it’s the analytics script, as we have this handled by the GTM Kit plugin instead of GfW, and also it’s front-end not back-end, and it’s an asynchronous loading javascript, not a server page.

    Thread Starter webwitnl

    (@webwitnl)

    We solved it by uninstalling this plugin and writing our own little 13K script to make an XML product feed. That shaved ±15 seconds from backend pages. Probably our hosting limitations in combination with other plugins were also a factor, but this was the major one. The data is also much better than before because we could include unit_pricing_measure and fine-tune the feed much more to our liking (such control is missing from GFW). Not sure about the design direction to like rebuild the Google Ads and Merchant Center interface in WordPress/Woocommerce.

    Thread Starter webwitnl

    (@webwitnl)

    Hi,

    Thanks for that. That’s so generic I wonder if you’re an AI lol. You also didn’t answer the question why the plugin does stuff on every page load even in places where it should do nothing.

    Anyway, our profiler shows the DB isn’t the bottleneck by far. Disabling other plugins will of course help one at a time, but yeah, the heaviest plugin to be disabled is… Google For Woocommerce, it makes stuff much faster, so we’ll be looking into a plugin that just produces a feed.

    Btw, we investigated which plugins are the most bloated, and while size isn’t always indicative of what is actually loaded, after the Woocommerce plugin itself and Jetpack, GFW is the largest with a size of a whopping 41 MB.

    That seems kind of careless for WordPress/plugin environments where everything adds up. Bit of trivia, did you know the original Doom is just 2MB, and the full version with 4 episodes is 12MB? Not sure why you need 41 MB to fire some basic product data at an API.

    Thread Starter webwitnl

    (@webwitnl)

    Disabling other plugins didn’t help. Fatal error log is empty. Here’s the system status report:

    https://pastebin.com/KML6QG5N

    Thread Starter webwitnl

    (@webwitnl)

    The third option is probably preferable for most internet connections or site speeds. Because when I manage to focus on the search field before the script is loaded, and then start typing, the script loads within half a second anyway, sees that I’m typing and shows the auto results. That already works. So that would make 1 unnecessarily restrictive.

    Thread Starter webwitnl

    (@webwitnl)

    P.S. I have a better temporary fix which seems quite robust, as it checks the dark layer when the details panel is shown. So that should catch all occurrences when the search results are shown but not the dark layer. Maybe something similar should be added to search.js getSuggestions().

    jQuery( document ).on( ‘fibosearch/show-suggestions’, () => {
    if (!jQuery(‘.dgwt-wcas-search-darkoverl-on’).length) {
    const $input = jQuery(‘.dgwt-wcas-search-input’).first();
    if ($input.length) {
    const fiboAutocomplete = $input.data(‘autocomplete’);
    if (fiboAutocomplete) {
    fiboAutocomplete.enableOverlayDarkened();
    }
    }
    }
    });

    Thread Starter webwitnl

    (@webwitnl)

    Thanks, and the temporary fix works!

    Thread Starter webwitnl

    (@webwitnl)

    Hi Marta,

    Unfortunately it’s on a staging environment behind a firewall.

    However, I’m not sure what you can’t replicate. The logic and, looking at it, the code is obvious:

    In search.js there’s an initialize function which is called on load, which calls the registerEventsSearchBar function.

    In there it does this:

    that.el.on(‘focus.autocomplete’, function (e) {
    that.onFocus(e);
    });

    And in the onFocus function it adds the dark layer.

    So if you focus on the search input field before this script is loaded, obviously onFocus isn’t called, and the dark layer isn’t added.

    I added a line of code in my own script to check if the search input field is already active when the script is loaded, in which case it triggers onFocus. That’s all you need to do.

    • This reply was modified 10 months, 1 week ago by webwitnl.
    Thread Starter webwitnl

    (@webwitnl)

    Thanks a lot, that did the trick!

    Btw, I wanted to use Riverty and Mollie’s offer for one month of no charges, but when I activate Riverty, it asks for a “Birthdate” at the checkout instead of Dutch “Geboortedatum”. Therefore I can’t use it or your offer. I reported this back in October, but no response or fix at all in three weeks. It would take minutes to fix… Shame. It seems Mollie lost all sense of urgency.

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