Rune Rasmussen

Why? You have a bug in the software, the feature have been wrongly implemented. And now you have been made aware of it, and your team can debug it at your own test environment if you need to.

Hi there,

I got feedback that it still doesn’t work as expected.

When a product having a discount set in WooCommerce is added to the cart, the coupon is denied used as it should. The cart displaying the error text: ?Sorry, this coupon is not applicable to selected products.?

But when a product having a YayPricing discount is added to the cart, the coupon is applied to the cart, and the product price is set back to normal price excl. discount. That doesn’t make much sense, and would potentially make the customers upset…

Before adding coupon code:

After adding coupon code:

It’s actually super easy to recreate;

1. Create a ‘Smart Bundle’ product, name it t.ex. ‘Smart Bundle’.
2. Add a bundle item and other required info to it.
3. Save the product (Publish).
4. When it’s saved you can continue to edit the product, just search for ‘Smart Bundle’, and add it as a bundled item. Note! It’s greyed in the returned results, but you still can add it.
5. Save the product again (Update).
6. Crash …

*WooCommerce 9.3.3, PHP 8.2

No the admin can add the product to itself. Like you have created a Smart Bundle product, then you add this as a bundled product to itself. ‘Product A’ is added as a bundled product to ‘Product A’…

It’s several ongoing issues with this plugin, because it doesn’t follow PHP 8+ standards, and it sadly seems like the dev doesn’t care or can fix it, don’t understand why though: https://www.ads-software.com/support/topic/php-warning-undefined-array-key-sale_price-2/#post-17837796

Another one started to pop up in the later versions:

PHP Warning: Undefined array key “reviewer_name” in /wp-content/plugins/woo-product-feed-pro/classes/class-get-products.php on line 131

You really need to start checking for if things are defined before trying to use it, if you continue to fail doing so, keeping your plugin up to date with PHP, folks have to find other plugins to use for product feeds…

Instead of the mentioned override of the template file, this might work better:

add_filter( 'woocommerce_checkout_fields' , 'remove_order_notes_field', 20, 1 );
function remove_order_notes_field( $fields ) {
    unset($fields['order']['order_comments']);
    return $fields;
}

For more info see: https://www.ads-software.com/support/topic/disable-order-note-field-in-checkout/#post-17987063

For others wondering, while we wait for the new release:

If you’d like to remove the order notes field in the current version we suggest overwriting the template in your child theme instead.

The code in svea-checkout.php loading the order note field is as follows, which means you might end up removing other things also if removing/commenting it:

                <div class="wc-svea-checkout-other-fields">
                    <?php foreach ( $checkout->get_checkout_fields( 'order' ) as $key => $field ) : ?>
                        <?php woocommerce_form_field( $key, $field, $checkout->get_value( $key ) ); ?>
                    <?php endforeach; ?>
                </div>

So maybe instead just add a custom filter to functions.php or a code snippet plugin:

add_filter( 'woocommerce_checkout_fields' , 'remove_order_notes_field', 20, 1 );
function remove_order_notes_field( $fields ) {
    unset($fields['order']['order_comments']);
    return $fields;
}

Bump! https://translate.www.ads-software.com/projects/wp-plugins/svea-checkout-for-woocommerce/stable/nb/default/?filters%5Bstatus%5D=waiting

Det med mest p?litelig er nok litt relativt, og i forhold til betalingsutvidelser s? handler det vel om momsberegning og m?ten som Woo h?ndterer dette p? i sine kalkulasjoner (og visninger), at man tar den enkle utveien istedenfor ? tilpasse seg Woos logikk i egen kalkulering av dette (hva som vises i butikk m? samsvare p? betaling og ogs? stemme ved riktig momskalkulasjon). Man kan vel stort sett se p? de fleste Checkout-betalingsutvidelsene m.m. at de krever desimaler.

Uansett, hvorfor det er slik osv. er ikke s? viktig, det nytter heller ikke ? diskutere s? mye med dem, man m? bare tilpasse seg dem s? lenge det er slik. Og det skulle jo v?re en relativt enkel ting ? gj?re i ‘Bring Fraktguiden for WooCommerce’, legge til et valg for dette, som ogs? gj?res hos dere ?konkurrent? mener jeg.

Takk for forslag om filterl?sning, men enklere for alle deres brukere om det er et valg i utvidelsen deres, mer positivt for dere.

Sounds great regarding the 3.0.0 version, looking forward to testing it, hopefully it will solve all known issues and limitations then. ??

OK, sounds good regarding the 3.0.0 version.

In the meantime, while everyone waits for it, better post the full instructions for the current versions for everyone who needs it till then (which is most Instore users I guess ;)).

Minimum is 10 and maximum is 60.

Are those the minimum and maximum allowed by Svea Checkout API?

Turns out the 60 minutes isn’t enough for many customers when the orders is placed through the webshops, and thus it just leads to more work for the store admins, supporting those customers who isn’t able to pay within 60 minutes – re-adding their orders over and over again.

So when used in webshops it needs to be increased to something like 3 hours I guess …

I just have to say that it’s a bit strange to see that you recommend updating to PHP 8.2/3 when the plugin haven’t even been fully updated for PHP 8+ yet: https://www.ads-software.com/support/topic/product-feed-not-updating-4/#post-17911424 ??

• This reply was modified 3 months, 4 weeks ago by Rune Rasmussen.

This is not fixed yet?

Failed in my tests today, with the latest version of the plugin. At the same time there is issues with the selection of pickup point for ‘Freight Integration for Woocommerce to Logistra Cargonizer or Profrakt by WildRobot’ – which most likely will be a stopper for the store to use Svea …