bbceg
Forum Replies Created
-
Thanks @fahadmahmood
I need all of the locations to be enabled, but only one to be selected per order. Stock should then only be deducted from that location. So one user might choose location A for their order and another user might choose location B for their order. In each case the stock should be deducted from the user’s chosen location only.
I’ll send you the code I’m using to set the order item meta shortly.
Thanks for your help.
Forum: Plugins
In reply to: [Stock Locations for WooCommerce] Ajax add to basket broken (page reloads)@fahadmahmood Thanks I did that one, I just wanted to point out that I also had to comment out the blockUI line to prevent the overlay from appearing. In reality I can comment out the whole block from 83-89:
// $.blockUI({message:''}); // $.post($(this).prop('href'), {}, function(){ // //document.location.href = slw_frontend.cart_url; // document.location.reload(); // });Thinking about it, with my use-case above in mind, I may even be able to get away with dequeuing the common.js file entirely.
Forum: Plugins
In reply to: [Stock Locations for WooCommerce] Ajax add to basket broken (page reloads)Thanks @fahadmahmood your fast response is always appreciated.
While this does prevent the page reloading I get left with an eternally spinning spinner! 😉 Fortunately commenting out line no 83 sorts that:
//$.blockUI({message:''});Incidentally, it looks like the plugin is attempting to check stock levels for the product at the location specified but I don’t think it will ever succeed in my case. This is because I’m managing the user’s selected location externally to your plugin – I ask the user for their location and set this via a cookie. I then do stock checks / display on the sever by hooking into the relevant Woocommerce filters and using your SlwStockAllocationHelper::getProductStockLocations function.
Do let me know if you see any problems with this approach.
Forum: Plugins
In reply to: [Stock Locations for WooCommerce] Ajax add to basket broken (page reloads)There’s not too much to say but I will try and explain here 🙂
I’m trying to prevent the whole page from reloading. You can tell this has happened in the video because the ‘View Basket’ links disappear from underneath the ‘Add to Basket’ buttons. With the plugin disabled the page does not reload and these links do not disappear.
Perhaps you could show me what happens when you do the same in your install (both with the woocommerce ajax add to basket archive buttons enabled / disabled)?
Forum: Plugins
In reply to: [Stock Locations for WooCommerce] Ajax add to basket broken (page reloads)Thanks @fahadmahmood
Link available here:
https://privnote.com/Ix5VZpHZ#ACfkVWEPQNote how the buttons reset each time and the ‘View Basket’ links disappear.
To reproduce simply navigate to an archive page with the ajax setting enabled in Woocommerce and click Add to Basket. If that’s not happening for you then perhaps something else is going on.
If you have a filter to disable this behaviour that’s fine with me, I don’t need an option in the UI.
Thanks.
Hi @robert681
I never thanked you for sorting this. So thank you!
Thanks very much for sorting this so promptly @fahadmahmood and for the credit!
Thanks very much for the swift response @fahadmahmood although this sounds like it might be slightly different. I’m happy for the information to appear under WooCommerce > Products as we can use this to verify stock levels.
We’re only looking to hide the fields from individual orders as we’ll be syncing stock levels via a 3rd party ERP system much of the time.
Unless I’ve misunderstood the new option…
Hi @robert681
That’s right. The options I had ticked before upgrading were:
Login Form Registration Form Lost Password Form Reset Password Form Comment FormThe error is simply “Please solve the captcha” (no CAPTCHA control appears as is probably expected).
I think I’m right in saying the WordPress login form and Woocommerce login form are somewhat intertwined. Might that have something to do with it?
Hi @robert681
Thanks for the update but just to clarify, I’m not trying to allow the reCAPTCHA control to be enabled on the my-account form. I do not need the control on that form and am happy with the free functionality the plugin provides elsewhere. Or are you saying that in order for that form to not be broken by this plugin, we need to pay for the premium version?
Thanks
I just stumbled across the same issue. Rolling back to version 6.1.7 solves the problem. I presume this is a bug rather than an intended feature since I have not (and can not) enabled the reCAPTCHA for Woocommerce without the Premium version. I should add that I don’t require this feature.
Forum: Plugins
In reply to: [WooCommerce] JQuery conflict after updateGot there eventually. I have code that dequeues jquery-migrate to minimise the number of scripts being loaded. Enqueuing this removes the error.
Might it suggest that if the flexslider code I’ve highlighted was updated then jquery-migrate would not be required?
Thanks
Forum: Plugins
In reply to: [WooCommerce] JQuery conflict after updateHi @rainfallnixfig ,
Thanks for the response.
It’s a bit of head scratcher. I have two virtually identical sites that share the same codebase except for some location-specific features. One such feature disables an instance of MetaSlider from appearing in the footer of the site. Oddly, if this isn’t rendered then the error appears.
I’ve installed a completely fresh install with storefront and sure enough I can’t replicate the error so no doubt there is a conflict somewhere.
Incidentally, and just in case it’s relevant, if I replace the aforementioned code with the following then the error does not appear and everything works as expected:
item = $('<img/>', { src: slide.attr('data-thumb'), alt: slide.attr('alt') }); item.on('load', function (el) { el.currentTarget.width = el.currentTarget.naturalWidth; el.currentTarget.height = el.currentTarget.naturalHeight; });Forum: Plugins
In reply to: [WooCommerce] JQuery conflict after updateI can confirm I’m seeing the same issue but oddly it’s not affecting virtually identical websites (which might explain why it’s slipped through testing). The offending code change appears to have been as follows:
Previous Code – Lines 245-247 of jquery.flexslider.js
if ( slider.vars.controlNav === "thumbnails" ) { item = $( '<img/>' ).attr( 'src', slide.attr( 'data-thumb' ) ); }New Code
if ( slider.vars.controlNav === "thumbnails" ) { item = $('<img/>', { load: function (el) { el.currentTarget.width = el.currentTarget.naturalWidth; el.currentTarget.height = el.currentTarget.naturalHeight; }, src: slide.attr('data-thumb'), alt: slide.attr('alt') }) }Specifically I think the load function is causing the problem but I wasn’t sure how to replace this with the equivalent of .on(‘load’) which is usually the fix for this error.
Just a quick note to say thank you for the fix and that this appears to have fixed the navigation problem for me in Chrome.