RLDD

Hi Diego, Thank you for your previous recommendations. You have created a beautiful plugin and I would like to improve compatibility between the two plugins.

The Cart page works fine, the issue is on Checkout.

I see the Order Summary html structure on /checkout with Fluid Checkout is different than the native structure.

Here are a two images, the first with Fluid Checkout, and the second with native WC elements. Since the structure is different, the pseudo element does not apply in the Order Summary.

I look forward to your recommendations to improve compatibility on the checkout page.

Hi, thank you for this question. Yes this is an option on the PRO plugin. Look under the plugin settings for Entry Type. If it is not “Itemized Time”, then temporarily change this to “Itemized Time”. You’ll see an option appear at the top of the PRO module where you can select a 12 or 24 hour time format.

You can then return the Entry Type to it’s original setting if it was not “Itemized Time”.

Hello,

I’m happy to say we found the problem and it was related to the translation of the cart page name. There was no code difference between the two versions, so it must have been using some piece of data cached in WC with the older version that is lost when a new version is installed.

Ultimately we just added one more check to ensure the Ship Estimate runs on cart pages even if the cart page name is in a non-English language. To ensure this works for you, visit WooCommerce > Settings > Advanced, and make sure the Cart page is set correctly (Panier in your case).

Sure, please just delete the highlighted portion of the line below in wse_functions.php.

If this doesn’t work, check and disable any caching plugins at checkout.

If all else fails, please send diagnostics from PRO tab so I can research further.

Ok thank you for confirming. Allow me some time to do a deeper analysis between v1.8 and v2. There were many improvements during this time. If you could please leave v1.8 installed on your site temporarily to allow me to look at the CSS at checkout that would help move this along.

Thank you for that information. This is for certain a theme or plugin conflict. You mentioned that the delivery date displays in the email, so the plugin is active. I see the plugin is active at checkout, but the styles are overridden by something else, likely a theme or other plugin used to customize checkout. Until I know what is overriding it, I’m unable to offer more specific guidance.

The current version of the plugin works with WooCommerce 9.7. To troubleshoot the conflict I recommend temporarily deactivating other plugins until the delivery estimate re-appears at checkout. This includes caching or performance plugins that may reorganize CSS styles. You can also temporarily switch themes to rule out theme settings. You may also try switching your checkout page to use the new WooCommerce blocks, it’s easy to try this out on a new test page.

If you need more personalized support or troubleshooting you may visit the ‘PRO’ tab in Ship Estimate settings for support options.

Thanks for reaching out. There have not been recent changes to the plugin, so it is likely to be a conflict with another plugin or a recent theme update. I suggest temporarily disabling other plugins or switching to a default theme to help isolate the cause.

If you’re able to post the store URL you need help with -I can begin to troubleshoot for you to see if another plugin has overridden the css styles and the estimates are simply hidden. If you need more personalized support or troubleshooting you may visit the ‘PRO’ tab in Ship Estimate settings for support options.

Thank you for reporting this issue and providing such a detailed explanation of the situation.

This plugin is designed to retrieve all coupons that qualify to be auto-applied in a single sweep, avoiding redundant and looping queries that typically consume additional resources. The query specifically targets published posts with the shop_coupon post type that have not expired, ensuring quick execution under normal circumstances.

Have you tried executing this query directly on your database? In our tests within an established WooCommerce environment, the query consistently executes in approximately 0.004 seconds. If you find this to differ when running a query profile please let me know, I would be happy to look into this further -as it could perform differently in other environments.

There are certain scenarios that could lead to prolonged query execution times, such as:

1. High Traffic or DDoS Activity
   If a malicious or unusually high volume of traffic targeted your cart page, it could trigger this query repeatedly in rapid succession, straining server resources.
2. Large or Unindexed Tables
   In stores with large datasets (e.g., extensive coupon metadata), insufficient indexing on key columns (e.g., meta_key in wp_postmeta) could significantly impact query performance.
3. Custom Code or Hooks
   If custom functionality modifies or hooks into WooCommerce coupon queries, it might inadvertently add complexity or cause conflicts. Reviewing any custom functions tied to coupon processing could help identify potential contributors.

Please let me know if you continue to look into this incident. If any issues are identified with a part of the query that causes extended execution, or if you find that any part of the query is omitted and it runs faster, I can definitely take this information and improve the plugin. For example, if you run the query without all the columns (or without the LEFT JOIN) and it’s performance changes, this would be helpful to know. Or if you exclude any conditions past WHERE and it runs differently. I look forward to finding the root issue with your help. Thank you!