pawelkmpt

I did it like this:

function custom_default_address_fields( $fields ) {
    $fields_order = array( 'company', 'first_name', 'last_name', 'address_1', 'address_2', 'city', 'postcode', 'country', 'state' );

    // Set fields priority
    $priority = 10;

    foreach ( $fields_order as $key ) {
        if ( ! isset( $fields[ $key ] ) ) {
            continue;
        }

        $fields[ $key ]['priority'] = $priority;
        $priority += 10;
    }

    // Change fields order
    $fields_ordered = array();

    foreach ( $fields_order as $key ) {
        if ( isset( $fields[ $key ] ) ) {
            $fields_ordered[ $key ] = $fields[ $key ];
        }
    }

    return $fields_ordered;
}

add_filter( 'woocommerce_default_address_fields', 'custom_default_address_fields' );

• This reply was modified 6 years, 9 months ago by pawelkmpt.
• This reply was modified 6 years, 9 months ago by pawelkmpt.

Eventually I set priorities and reordered fields in array using woocommerce_default_address_fields filter and both group of fields are displayed in desired order.

I did as mentioned above

I needed to reorder both: billing and shipping fields and for some reason changing their priorities in woocommerce_default_address_fields made fields ordered desired way only for shipping fields. Billing fields were displayed in order they are kept in fields array.

From the other side, reordering fields in array (without changing priorities) using woocommerce_default_address_fields or woocommerce_checkout_fields filter made and effect only on billing fields.

Eventually I set priorities and reordered fields in array using woocommerce_default_address_fields filter and both group of fields are displayed in desired order.

I’m just wondering if this is how it should work, or checkout page I’m working on is so highly customized that default WooCommerce scripts are not triggered on specific fields group.

• This reply was modified 6 years, 11 months ago by pawelkmpt. Reason: I want follow the topic

I also have a problem with getting JSON response. Few sites I tested it on use pretty permalinks but only 404 or some archives are displayed. I tried ?rest_route=/ as well but without success.

Is anybody aware of any possible conflicts with plugins? Or what in general could be wrong?

So issue is in the PayPal Express plugin, USPS is fine: https://github.com/woocommerce/woocommerce-gateway-paypal-express-checkout/issues/179

This I figured out as well. Question is why when client logs in to PayPal and is redirected to the checkout page from cart, zip code is not given to USPS plugin?

Have you had a chance to test your plugin with PayPal one? Because it might be they’re not compatible with each other or some additional code snippet is needed to make it work.

From the other side, when client is logged in and have its address saved in the account, shipping fee is provided.

Thanks for checking settings! I have requests from debugging mode (without sensitive data hopeefully).

However, please make sure some valid services for your source and destination is enabled in the settings

Chosen services are valid as shipping price calculation works without any problem when client use other payment gateway. We’ve used many different plugins over the time and PayPal Express is the first one having issues.

REQUEST
API=RateV4&XML=<RateV4Request USERID=""><Revision>2</Revision><Package ID=""> <Service>ONLINE</Service> <ZipOrigination>15212</ZipOrigination> <ZipDestination></ZipDestination> <Pounds>3</Pounds> <Ounces>3.20</Ounces> <Container /> <Size>REGULAR</Size> <Width>0.1</Width> <Length>0.1</Length> <Height>0.1</Height> <Girth>0.4</Girth> <Machinable>true</Machinable> <ShipDate>07-Dec-2016</ShipDate></Package></RateV4Request>

RESPONSE

<?xml version="1.0" encoding="UTF-8"?>
<Error><Number>-2147219099</Number><Source>clsRateV4:UnpackRateNode</Source><Description>Missing value for ZipDestination.</Description><HelpFile/><HelpContext/></Error>

Thanks for quick response!

Settings screen can be found here: https://i.imgur.com/cyet8cc.png
Additionally – in Services section only Priority Mail is chosen.

I’ll provide debugging information later as problem occurs for clients is US and I’m located in Poland.

I just found out this on FAQ page:

What do I need to do if I’m updating from the retired premium Braintree plugin from WooThemes.com?
You’ll need to go through the same installation process as everyone else. Luckily it’s only a few clicks (no need to copy and paste API keys) so it should only take a minute.

Credit card tokens will not migrate. Your customers will have to reenter their CC details once. All transactions made with the new plugin will let the user choose if they want their CC details saved (as tokens of course) so they don’t have to reneter them every time.

It basically means that WooThemes don’t care about migration…

Hey,

I tested new version with my client and in the beginning everything looked good, there was no any sign of bugs. After few hours we found out:
– that credit card fields are still disappearing on occasion,
– following error occurs when users try to pay with PayPal nearly 50% of the time: Error: PayPal Powered by Braintree did not supply a payment nonce. Please try again later or use another means of payment.
– this plugin doesn’t have credit card data migration from the Skyverge Braintree extension so all subscription products were failing.

We giving this plugin up. There’s no point to wait until developers do something to make it work 100% as this issue is up for almost 5 months. Shop owners are basically losing clients because of the issues.

New version of plugin was released 2 days ago. Did anybody test it and can tell if issue was fixed? I don’t see any info about it in changelog though.

After detailed debugging of WP::parse_request() and WP_Query::parse_query() I found out that unset( $query_vars['date'] ); in 'request' filter helps.

It basically unsets date query var before WP_Query::parse_query() is invoked so is_home() returns false.

add_filter( 'request', function( $query_vars ) {
        global $wp_query, $wp;

        if ( ! $wp_query->is_main_query() ) {
            return $query_vars;
        }

        $qv_keys = array_keys( $wp->query_vars );

        if ( ! ( in_array( 'product_cat', $qv_keys, true )
           || in_array( 'product_tag', $qv_keys, true )
           || in_array( 'post_type', $qv_keys, true ) && 'product' === $wp->query_vars['post_type']
           || in_array( 's', $qv_keys, true )
        ) ) {
            unset( $query_vars['date'] );
        }

        return $query_vars;
} );

Explanation:
Posts archive loads when WP_Query::$is_home = true so I traced back places where this value is set and in brief I think it’s like this:

1. $this->query_vars['post_type'] and $this->query_vars['name'] are not set in this condition as date query var is not assigned with any post type.
2. In result after many operations WP_Query::$is_singular is set to false here
3. And it leads to WP_Query::$is_home = true few lines later.

unset( $query->query_vars['date'] ); in 'pre_get_posts' doesn’t help. I also tried to set value of query var to ”.

Typically, you would have some sort of code hooked into ‘pre_get_posts’ that does something meaningful with the ‘data’ query var.

I do have for products archive and custom taxonomy.

Without that, WP will add AND date = ‘23.08.2016’ to the query’s WHERE clause. Since there is no date field in the posts table, the query fails to return anything.

Query Monitor doesn’t show query with this condition. Should it be visible or maybe some magic is happening somewhere and this query is overwritten?

The query I can see is regular posts archive query:

SELECT SQL_CALC_FOUND_ROWS wp_34_posts.ID
FROM wp_34_posts
WHERE 1=1
AND wp_34_posts.post_type = 'post'
AND (wp_34_posts.post_status = 'publish'
OR wp_34_posts.post_status = 'private')
ORDER BY wp_34_posts.post_date DESC
LIMIT 0, 20

When nothing is found by the query, what happens depends on the template.

I think theme behaves correctly. Query finds posts and is_home() returns true so correct templates are loaded. Question is why this is home when it should be front page?

As a workaround you could use the ‘pre_get_posts’ action to unset the ‘date’ query var if it is not needed.

I’ll try it and let you know if that worked. But still, I’d like to understand why this happens… Analysing WP_Query::parse_query() didn’t give me the answer yet.

Because ‘date’ is a known query var, WP tries to list all posts matching that criteria.

What do you mean by matching that criteria?

If your intent is to use the date parameter on your front page, just don’t register it through ‘query_vars’.

No, I don’t want to use this query var on front page and if this param appears in the URL I don’t want to break my website. But it does. I also changed the name of it to kp (even if date is not listed here https://codex.www.ads-software.com/Reserved_Terms) but it still breaks the front page.

Can you suggest any way of debugging it or workaround? I don’t entirely understand why it would load posts archive instead of 404 page.