Rune Rasmussen

Thanks, it surely is handled much better now.

But please note that if you’re going to use language strings from WooCommerce, ensure you use the right ones: https://plugins.trac.ww.wp.xz.cn/browser/posten-bring-checkout/tags/1.1.52/checkout/PostenBringCheckoutPublic.php#L598

It can else have some strange looking results:

This is one of the right one in WooCommerce for the billing section, but I haven’t checked it for shipping: https://plugins.trac.ww.wp.xz.cn/browser/woocommerce/tags/10.7.0/includes/class-wc-checkout.php#L866

Those strings (Billing/Shipping) also showed up in the language file for the plugin today, so if you fix the language domain in the code we get better control on them from there, even though the formatting still would be a slightly off so check that also.

Anyhow, those are just minor issues, nothing important – the plugin is already much better.

Thanks again 🙂

Note! There is one obvious problem with your insertion of country code, like if the store uses other shipping plugins, there is no similar validation in those – they normally use only the Woo logic who accepts t.ex. only +47 as valid. Thus, if you intend to keep this automated insertion of country code, you also need to ensure it’s being validated even if another shipping plugin is selected.

*The problem might also occur if something goes wrong with the method ID, with your existing validation:

if (isset($selected_shipping_methods[0]) && str_starts_with($selected_shipping_methods[0], 'posten-bring-checkout')) {
    // all phone validation here
}

Btw! There’s also an UX issue in this, when country prefix is being pre-filled based on country, as t.ex. Norway (but not only) have plenty of foreign workers and visitors ordering online, using their foreign phone number.

All in all, not a good solution to manipulate core fields. Betters submit your PR to the core, if you think it needs improvements.

Yeah, it’s interesting. I can confirm it seems to work somewhat in a new clean install. Though; t.ex. the error message is only displayed when there is no other validation errors (other fields), and the field is not marked with red – it’s always green (validated). The error message also doesn’t match the others in formatting, nor their normal sorting.

I can’t share any links here, nor do I actually have time or paid to debug this, so I think I’m just adding an improved custom validation snippet for it, and move on.

BTW! The missing phone validation might be a JS issue, as it seems like you have added your own validation in JS scripts in this plugin, which might be an issue for sites using caching and optimisations.

/**
 * Validate Nordic mobile phone numbers on WooCommerce checkout.
 *
 * - Accepts both "+" and "00" international prefixes.
 * - Per-country digit length rules (subscriber number, i.e. after country code).
 * - Falls back to billing_country when no prefix is supplied.
 * - Uses Woo's native error string so translations stay consistent.
 * - Marks the billing_phone field invalid (red border + inline message).
 * - Re-sorts checkout errors to match the field order on the form.
 */
add_action( 'woocommerce_after_checkout_validation', 'wc_validate_nordic_phone', 10, 2 );

function wc_validate_nordic_phone( $data, $errors ) {

    if ( empty( $data['billing_phone'] ) ) {
        return; // Let Woo's own "required" validation handle empties.
    }

    // Nordic rules: country code => [ min digits, max digits ] of subscriber number.
    $rules = array(
        '47'  => array( 8, 8 ),   // Norway
        '45'  => array( 8, 8 ),   // Denmark
        '46'  => array( 9, 9 ),   // Sweden (mobile, leading 0 stripped)
        '358' => array( 9, 10 ),  // Finland
        '354' => array( 7, 7 ),   // Iceland
        '298' => array( 6, 6 ),   // Faroe Islands
        '299' => array( 6, 6 ),   // Greenland
    );

    // Map billing_country (ISO) to dial code for fallback.
    $country_to_cc = array(
        'NO' => '47', 'DK' => '45', 'SE' => '46',
        'FI' => '358', 'IS' => '354', 'FO' => '298', 'GL' => '299',
    );

    $raw = trim( (string) $data['billing_phone'] );

    // Normalize: keep leading "+" if present, strip everything non-digit.
    $has_plus = ( strpos( $raw, '+' ) === 0 );
    $digits   = preg_replace( '/\D+/', '', $raw );

    if ( '' === $digits ) {
        return;
    }

    // Resolve country code from input or fall back to billing_country.
    $cc         = '';
    $subscriber = '';

    if ( $has_plus || strpos( $digits, '00' ) === 0 ) {
        // Strip "00" international prefix if present.
        if ( ! $has_plus && strpos( $digits, '00' ) === 0 ) {
            $digits = substr( $digits, 2 );
        }
        // Try matching the longest country code first (3 then 2 digits).
        foreach ( array( 3, 2 ) as $len ) {
            $candidate = substr( $digits, 0, $len );
            if ( isset( $rules[ $candidate ] ) ) {
                $cc         = $candidate;
                $subscriber = substr( $digits, $len );
                break;
            }
        }
    } else {
        // No international prefix — use billing_country as the fallback.
        $country = isset( $data['billing_country'] ) ? $data['billing_country'] : '';
        if ( isset( $country_to_cc[ $country ] ) ) {
            $cc         = $country_to_cc[ $country ];
            $subscriber = $digits;
            // Allow national trunk "0" prefix (e.g. SE: 070...).
            if ( '46' === $cc && strpos( $subscriber, '0' ) === 0 ) {
                $subscriber = ltrim( $subscriber, '0' );
            }
        }
    }

    // If we can't resolve to a Nordic country, don't block — let other plugins decide.
    if ( '' === $cc || ! isset( $rules[ $cc ] ) ) {
        return;
    }

    list( $min, $max ) = $rules[ $cc ];
    $len = strlen( $subscriber );

    if ( $len < $min || $len > $max ) {

        // Get the field label so the message matches Woo's other field errors.
        $fields = WC()->checkout()->get_checkout_fields( 'billing' );
        $label  = isset( $fields['billing_phone']['label'] )
            ? $fields['billing_phone']['label']
            : __( 'Phone', 'woocommerce' );

        // Prefix with "Billing" exactly like WC core (class-wc-checkout.php L866).
        /* translators: %s: field name */
        $label = sprintf( _x( 'Billing %s', 'checkout-validation', 'woocommerce' ), $label );

        // Use Woo's native translation string — translates automatically per locale.
        /* translators: %s: field name */
        $message = sprintf(
            __( '%s is not a valid phone number.', 'woocommerce' ),
            '<strong>' . esc_html( $label ) . '</strong>'
        );

        $errors->add(
            'billing_phone_validation',
            $message,
            array( 'id' => 'billing_phone' )
        );

        // Re-sort all checkout errors to follow the on-screen field order.
        wc_reorder_checkout_errors_by_field_order( $errors );
    }
}

/**
 * Reorder a WP_Error bag so checkout field errors appear in the same order
 * as the fields on the form. Errors not tied to a field keep their position
 * at the end.
 */
function wc_reorder_checkout_errors_by_field_order( $errors ) {

    if ( ! is_wp_error( $errors ) || empty( $errors->errors ) ) {
        return;
    }

    // Build the canonical field order across all checkout fieldsets.
    $checkout      = WC()->checkout();
    $all_fieldsets = $checkout->get_checkout_fields();
    $field_order   = array();
    $i             = 0;
    foreach ( $all_fieldsets as $fieldset ) {
        foreach ( array_keys( $fieldset ) as $field_key ) {
            $field_order[ $field_key ] = $i++;
        }
    }

    // Snapshot current errors with their data, then sort by field position.
    $entries = array();
    foreach ( $errors->errors as $code => $messages ) {
        $error_data = $errors->error_data[ $code ] ?? array();
        $field_id   = isset( $error_data['id'] ) ? $error_data['id'] : '';
        $pos        = isset( $field_order[ $field_id ] ) ? $field_order[ $field_id ] : PHP_INT_MAX;

        $entries[] = array(
            'code'     => $code,
            'messages' => $messages,
            'data'     => $error_data,
            'pos'      => $pos,
        );
    }

    usort( $entries, function ( $a, $b ) {
        return $a['pos'] <=> $b['pos'];
    } );

    // Rebuild the WP_Error bag in the new order.
    $errors->errors     = array();
    $errors->error_data = array();
    foreach ( $entries as $entry ) {
        foreach ( $entry['messages'] as $msg ) {
            $errors->add( $entry['code'], $msg, $entry['data'] );
        }
    }
}

/**
 * Mark fields invalid client-side based on server validation errors.
 * Woo emits <li data-id="<field_key>"> for errors that carry an 'id' in their
 * error_data; we use that to add the woocommerce-invalid class on the field
 * wrapper so it gets the red border, matching native field validation.
 */
add_action( 'wp_footer', 'wc_mark_server_invalid_fields_js', 99 );

function wc_mark_server_invalid_fields_js() {

    if ( ! function_exists( 'is_checkout' ) || ! is_checkout() ) {
        return;
    }
    ?>
    <script>
    (function ($) {
        $( document.body ).on( 'checkout_error', function () {
            $( '.woocommerce-error li[data-id]' ).each( function () {
                var fieldId = $( this ).data( 'id' );
                if ( ! fieldId ) {
                    return;
                }
                var $row = $( '#' + fieldId + '_field' );
                if ( ! $row.length ) {
                    return;
                }
                $row
                    .removeClass( 'woocommerce-validated' )
                    .addClass( 'woocommerce-invalid woocommerce-invalid-phone' );
            } );
        } );
    })( jQuery );
    </script>
    <?php
}

• This reply was modified 1 week, 2 days ago by Rune Rasmussen.
• This reply was modified 1 week, 2 days ago by threadi.

Installed yesterday, so versjon 1.1.51

You’re the same people both places.

Anyhow you already got the bug info, do as you like with it. Ignore it or forward to the right person(s). 😉

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.

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