Ward
Forum Replies Created
-
Forum: Plugins
In reply to: [SQLite Object Cache] Recent update conflict with TranslatePressFurther useful debug information of the working version:
Versions: SQLite: 3.45.1 php: 8.2.27 Server: nginx/1.26.3 Plugin: 1.4.1 igbinary: unavailable.
The issue is caused by an update to SQLite Object cache plugin, reverting back to 1.4.1 version of said plugin and flushing cache resolves it.
Will close this issue and follow up on SQLite plugin’s page.Forum: Plugins
In reply to: [SQLite Object Cache] Recent update conflict with TranslatePressHello,
Apologies for the late update, I have tested with 1.4.1 and the issue was solved. I believe the issue is connected to the APCu update.
Further context:
My server does not have APCu enabled.Forum: Plugins
In reply to: [SQLite Object Cache] Recent update conflict with TranslatePressThank you for taking the time to look into this! 🙂
The new APCu feature is disabled, I’ll roll back to 1.4.1 or 1.4.0 and test if it solves the issue, that will help us narrow down whether the APCu feature is connected
Will report back after testing.I can confirm the issue comes from a conflict with the plugin:
SQLite Object Cache – WordPress plugin | ww.wp.xz.cn
Disabling the plugin and removing the file .ht.object-cache.sqlite from wp-content folder fixes the issue. This occurs with the latest version of both plugins 1.5.1 for sqlite and 2.9.5 for translatepress.
I am not sure which plugin introduced the functionality breaking change.
I can confirm the issue comes from a conflict with the plugin:
SQLite Object Cache – WordPress plugin | ww.wp.xz.cn
Disabling the plugin and removing the file .ht.object-cache.sqlite from wp-content folder fixes the issue. This occurs with the latest version of both plugins 1.5.1 for sqlite and 2.9.5 for translatepress.
I am not sure which plugin introduced the functionality breaking change.
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.
Forum: Plugins
In reply to: [WC City Select] Slow Checkout loadingYou 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.
Forum: Plugins
In reply to: [WC City Select] add shipping fees to the areaHello @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 2 years ago by Ward. Reason: Typo
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