Is Ocean WP quantity input interfering with qunatity input of WPC Bundle Plugin?

Artan
(@artankrasniqi1988)

3 months, 2 weeks ago

Hi,

weird behavior and found a similar problem in your threat already here https://wordpress.org/support/topic/oceanwp-theme-on-woocommerce-page-causes-all-quantity-fields-to-change-together/

When Changing value directly in the input field no matter if in the WPC input fields or in the theme input field, all other input fields get updated to that value almost instantly.

When changing input value through + – buttons of the bundled single products of WPC plugin then only that desired single input field gets changed without affecting the others.

When changing the value of the input field through + – buttons of the theme (the one on the bottom) then again all values get changed to be the same.

I guess your theme has a kind of function who causes this by manipulating perhaps class “qty”. Is this your class or from WooCommerce? Because that theres a css conflict doesnt make much sense as CSS does not have the ability to manipulate the values of the inputs as far as I know.

Help is appreciated.

Regards

Viewing 6 replies - 1 through 6 (of 6 total)

Thread Starter Artan
(@artankrasniqi1988)

3 months, 1 week ago
UPDATE:

It seems to be your function that is causing this unwanted behavior. Your function seems to be a keyup event sitting in /wp-content/themes/oceanwp/assets/js/wp-plugins/woocommerce/woo-custom-features.min.js?ver=1.0 in single product pages (couldn´t see it in cart).

The function causing this issue:
```
function(e) {
var t = e.target,
r = t.getAttribute("type"),
e = document.querySelectorAll(".quantity:not(.buttons_added) .qty");
"date" !== r && "hidden" !== r && e.forEach(function(e) {
e.value = t.value
})
}
```
It would be nice if you isolate .qty a bit more like ("form.cart.quantity:not(.buttons_added) .qty"); so it only affects the main product amount value and not plugins that could use the same input classes or give own classes where the function gets triggered.

Hope we can resolve this fast.

Regards
Amit Singh
(@apprimit)

3 months, 1 week ago
Hi @artankrasniqi1988,

Thank you for reaching out.

We will take look and try to replicate it.

For now, please try the below code and let me know if it fixes the issue or not. Before using the code replace the .your-plugin-class .qty class name with actual plugin class name.
```
document.addEventListener('DOMContentLoaded', function () {

  document.querySelectorAll('.your-plugin-class .qty').forEach(function(input) {

    input.addEventListener('keyup', function(e) {
      e.stopImmediatePropagation();
    });

    input.addEventListener('change', function(e) {
      e.stopImmediatePropagation();
    });
  });
});
```
Thread Starter Artan
(@artankrasniqi1988)

3 months, 1 week ago
Hi @apprimit,

your function did not have an effect. I made a workaround for the moment. This is blocking your propagation to all input fields. I am using it in the functions.php file.
```
function block_wpc_smart_bundle_sync() {

    if ( ! is_product() ) {
        return;
    }

    global $product;

    if ( empty( $product ) ) {
        return;
    }

    if ( 'woosb' !== $product->get_type() ) {
        return;
    }

    ?>
    <script>
    (function(){
        ['change', 'keyup'].forEach(function(eventName){
            document.addEventListener(eventName, function(e){
                if (e.target.matches('.quantity .qty')) {
                    e.stopImmediatePropagation();
                }
            }, true);
        });
    })();
    </script>
    <?php
}
add_action( 'wp_footer', 'block_wpc_smart_bundle_sync', 100 );
```
I still would prefer if we wouldn´t need this. At the moment we don´t know why OceanWP wants to change/sync all .qty. Perhaps you can please explain if this is needed for your theme!? This will cause not only problems with the WPC Bundle plugin but also with other grouped products and plugins who use the native .quantity classes of WooCommerce.

Hope you’ll find a better workaround as the current approach seems to have an unwanted global effect in product single pages.

Regards.
Amit Singh
(@apprimit)

3 months, 1 week ago

Hi @artankrasniqi1988,

At the moment we don´t know why OceanWP wants to change/sync all .qty. Perhaps you can please explain if this is needed for your theme!?

To provide a final, technical perspective on why OceanWP is built this way, and why the theory of ‘global incompatibility’ doesn’t really hold up in practice:

OceanWP is a theme that supports WooCommerce: we support native Woo features, and we took it a step further by introducing a bit more advanced features. In the WordPress ecosystem, there are two ways to build:

#1 Proprietary: Using custom classes (.owp-qty-input) that only your theme understands.

#2 Standardized: Using the native WooCommerce classes (.qty, .quantity) that the entire ecosystem understands.

As you already noticed on your own, we choose Standardized. Why? Because if OceanWP used proprietary classes, the thousands of plugins that interact with quantity fields (dynamic pricing, tiered discounts, shipping calculators, etc) would all stop working the moment you activated OceanWP. By targeting ‘.qty’, we ensure that 99% of the thousands of Woo related plugins on the market ‘just work’.

The function you highlighted is a core UX feature. Modern users expect that if they change a quantity in a Floating Bar, or Quick View, the value remains synchronized across the entire page. Our global listener on .qty facilitates this.

If a third party plugin (like WPC bundle) introduces a unique ‘sub-product’ quantity field that uses the standard Woo class but shouldn’t sync with the main product, it is standard development practice for that plugin to handle its own event propagation.

OceanWP has quite a number of active installations and powers a massive portion of the WooCommerce web. If targeting the native ‘.qty’ class caused ‘unwanted global effects’ for grouped products or other plugins, our support forums would be flooded with these reports daily.

The reality is quite different, and this forum speaks for itself.

As noted by the other user in the thread you shared, the solution is already built into that plugin:

“Enable the ‘Show plus/minus button’ setting within the WPC plugin. This toggle exists specifically because the plugin developers are aware of how global theme scripts interact with standard WooCommerce classes. https://postimg.cc/7f02VSwf

If you’re indeed using the same plugin as the user from the thread you shared, I strongly recommend going with the native plugin option to support correct functionality, instead of custom codes.

To summarize: we won’t be changing the core targeting of .qty because doing so would break compatibility for the vast majority of our users who rely on the theme following the WooCommerce standard. The ‘workaround’ is simply to use the plugin as intended by its developers

Thread Starter Artan
(@artankrasniqi1988)

3 months, 1 week ago

Hi @apprimit,

I explained in detail what I did and that I already activated the “plus minus” option in the plugin AS U CAN SEE IN THE SCREENSHOTS :D. As I also already explained, this has nothing to do with the conflict that is happening directly in the INPUT FIELDS! I am always amazed how OceanWP manages to guide problems to the users because we simply seem to be to stupid to understand.

Ahh, just let it be… I write my own solutions, sorry that i disturbed you master.

Bye

Amit Singh
(@apprimit)

3 months, 1 week ago

We apologize if the technical explanation felt dismissive; our goal was simply to clarify the ‘why’ behind the theme’s core architecture and why we prioritize the WooCommerce global standard over individual plugin overrides.

Since you have implemented a custom workaround that satisfies your specific site requirements and the discussion has reached its conclusion, we will go ahead and consider this topic as resolved.

If you believe there’s a more efficient way to handle global sync without sacrificing the existing structure, we welcome your contribution.

Feel free to submit a Pull Request on our official GitHub repo with a proposed workaround that supports this specific third-party plugin without impacting core OceanWP functionality. We’d be more than happy to review it there – https://github.com/oceanwp/oceanwp

We wish you the best with your project

Viewing 6 replies - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

Tags