Ward

Apologies for the late response.

The issue seems to have been resolved, so it might have been a plugin conflict that was resolved via an update.

Thank you once more, closing.

Hello John,

Thank you for your reply. I’ll do my best to provide better troubleshooting data this weekend.

Thank you for your work on this great plugin.

You can use a plugin that defers script loading until the page has already loaded and the user took an action like WP Meteor to prevent the script from kicking in until the user has moved the mouse.

This will improve loading time and prevent any scripts in your page from triggering until you’ve moved your mouse (or any other custom interval).

Thank you for your reply, will make sure to go through the documentation and help fix the plugins we use to be compatible.

Hello @dina99

This is not necessary related to the plugin, but I did need this option for one of my projects before and below is how I solved it:

You have 2 options:

Option 1: this is more if you’re comfortable with coding, just write a small snippet to autofill zipcode field for each city (while having that field hidden) whenever the user selects the city from the drop list.

Option 2(The easy way): Simply use booster! while the plugin has hundreds of options and may be overwhelming, you can enable only the feature you need, and they have just the one you need with a very simply and easy to use UI, documented here: Shipping Methods by City or Postcode For WooCommerce plugin – Booster for WooCommerce

Happy to help if you have more questions.

• This reply was modified 6 months, 2 weeks ago by Ward. Reason: Typo

@mantish

I was able to resolve the issue with no modifications to your plugin here’s the issue’s root:

In?WooCommerce 8.3?and later versions, cart and checkout pages will be created using the new WooCommerce blocks.

And like everything else blocks touch, this broke compatibility with 100s of plugins that modified the checkout page. This is why everything still worked fine in “my account” page as that one is luckily still not blocked page.

Thankfully, the legacy checkout is still supported, so to resolve the issue simply delete the checkout page created by woocommerce (or delete its content) and replace it with the legacy shortcode which is:

[woocommerce_checkout]

This also applies to cart, which can be reverted back to non-blocks based legacy version by using a page with the shortcode:

[woocommerce_cart]

Since I have no interest in using block-based editor and also use Classic Editor and Classic Widget plugins in all my projects, so I sadly will not be able to invest the time to make a block-compatible hook and will be using the solution above, however, if you have the time it’s good to invest it into that given blocks may eventually be forced and classic editor retired.

Update:

I managed to find the root cause of the issue.

WooCommerce checkout page now has the city field IDs as follows “billing-city” and “shipping-city”

While my account page and backend pages has the following IDs “billing_city” and “shipping_city”

So the plugin only triggers a list for element IDs with an underscroll not a dash, and the checkout page now for some reason has it as a dash instead.

I am getting the exact same behaviour, will troubleshoot and share the solution as a pull request if I manage to resolve it

Hello Jahidul,
Thank you for your response but you have indeed misunderstood the issue.
I’m a developer myself and I’m aware of the concept of child orders and why dokan uses it this is why I mentioned it in the original post.
Dokan used to have a function to filter the analytics of woocommerce and the order to show correct info and not show duplicate orders.
The concept is using the query post_parent=0 to only take into account main orders not child orders.

This is not working with the latest version and it’s displaying both child orders and main orders which is causing duplicate analytics beside the in accurate number of orders in the dashboard/orders screen

After looking at the code I realized the default providers are listed according to your API and are not stored locally, which I understand due to integration with Trackship.

Can you at least provide a way or an update to hide them from the orders page droplist as long as they are disabled and only show active one?

was implemented, so I’m gonna close.

//

• This reply was modified 3 years, 4 months ago by Ward. Reason: Retracted

Which table are they stored in?
As they clutter my order screen, when you click filter by shipping provider you get a drop list with 300 providers which is not practical.

• This reply was modified 3 years, 4 months ago by Ward.

Unfortunately our current staging environment contains sensitive data.
I’ll try to setup a new empty staging websites and let you know.

Thank you for the follow up.

Hello,

There is no sensitive data that require an email.
Here’s my server information:
-PHP 7.4.9, MariaDB 10.5.5
-Server is Apache + NGINX
-Centos 7.0
-Wordpress 5.7.2
Let me know if you need any other info, I’m happy to share publicly.

I noticed the issue after the last update (Both WordPress and plugin were updated at the same time)