robertstaddon

Thank you for this reply, @shahzeenfarooq

I understand your reasoning. However, generating a new label for an existing order is very helpful for:

1. Merchants who are not using WooCommerce for detailed inventory tracking (e.g. just using it for “In Stock” or “Out of Stock”) and have a package that (1) is lost in shipping or (2) the label was damaged by the Post Office or (3) the wrong product was shipped and a corrected order needs to be shipped out.
2. Merchants who are using WooCommerce for detailed inventory tracking and decide that in many situations it’s much easier to reprint a new label and manually adjust their inventory level than it would be to re-create an entirely new order and re-add the products from the previous order and re-enter the customer’s information and then generate a brand new shipping label. For example, my customer noticed a defect in a CD and had to re-ship 50 orders with a replacement CD. Manually generating 50 shipping labels would have been a huge headache but “WooCommerce Shipping + Tax” made it simple for them with the “Reprint New Shipping Label” option. A simple inventory adjustment and they were golden. Re-creating 50 new orders would have taken them considerably more time and frustration, which is why they specifically contacted me and requested that I roll their site back to the previous “WooCommerce Shipping + Tax” plugin.

Please consider that this ability, which seems simple to implement in the new plugin, is the 5th most-requested feature for WooCommerce Shipping: https://woocommerce.com/feature-request/multiple-shipping-labels-for-an-order/ It also shares similarities to the #1 requested feature for WooCommerce Shipping: https://woocommerce.com/feature-request/add-ability-to-print-return-labels/

The problem appears to be solved in this latest version of the plugin. Thank you!

• This reply was modified 3 weeks, 2 days ago by robertstaddon.

I noticed the exact same issue on my sites after updating to the latest version of Event Tickets! Hope that this is fixed soon. Thanks!

I’m not sure that @polevaultweb would be able to reply on these forums any longer. If you’d like to reach him, you may want to try directly through https://www.advancedcustomfields.com/

I noticed you’d released a new version! Good work. Thank you!

The only blocker for me using Stripe Tax now would be that it breaks the coupon field from working in with the default WooCommerce Blocks: https://www.ads-software.com/support/topic/breaks-coupon-field-in-woocommerce-blocks-cart-and-checkout/

Ok! I totally understand. I think it would be important to prioritize this as Blocks are now the default WooCommerce install. As a Pro subscriber, I’d love to use your plugin on new client deployments but I’m hesitant to have to roll back the beautiful new checkout experience to the old shortcode approach just to allow your plugin to work.

Thank you @hailite ! I just installed the dev branch and it worked beautifully. Looking forward to the v6.5 release!

That’s great to hear @qtwrk ! Thank you!

Thank you, @thyran, for helping report this issue and @litetim and @qtwrk for trying to help replicate it. And @stefanr wins the prize for being the first to really pinpoint it in a replicatable way.

So my question is what would be the best next step. Should I email LiteSpeed support with login credentials to my dev site? Or hop on the developer Slack channel? Or submit an issue on the LiteSpeed GitHub?

Ok, so I figured out the issue and have set up a staging site to replicate the problem. It only happens on Divi sites with a Theme Builder Global Header. Here’s how to reproduce the problem:

• Install LiteSpeed and enable ESI
• Install Divi theme and use the Theme Builder to create a Global Header with anything in it.

After doing the above, visit the frontend of the website and the top admin bar will disappear after refreshing the page.

The issue appears to somehow be related to the way that Divi executes and outputs the “wp_body_open” action in relation to the Theme Builder, perhaps to keep “wp_body_open” output from messing up a Global Header template. So when LiteSpeed Cache added the following line of code, it caused the admin bar ESI block to generate early but then it never gets added to the page:

add_action('wp_body_open', array($this, 'sub_admin_bar_block'), 0);

On all Divi pages with a Theme Builder, the admin bar code seems to output in the footer of the page using “wp_footer”. However, with ESI enabled, the admin bar code is now not placed there because $this->admin_rendered becomes true when the “wp_body_open” action is run.

I have confirmed that it is the following two lines of code added in LiteSpeed Cache 6.4 on lines 369 and 370 of src/esi.cls.php (to fix the Elementor button on the admin bar) that is causing the top admin bar to disappear on the frontend of all these Divi installs.

remove_action('wp_body_open', 'wp_admin_bar_render', 0);
add_action('wp_body_open', array($this, 'sub_admin_bar_block'), 0);

I haven’t figured out exactly why quite yet and how to duplicate this on a clean new staging install…

I’ve repeated these same steps with a brand new dev site with Divi and LiteSpeed with ESI enabled and I am also unable to replicate the issue of the admin bar disappearing on the frontend.

However, I have over a dozen live sites where this issue is very much a problem and oddly enough disabling all other plugins does not seem to resolve it. There must be a special LiteSpeed or Divi setting somewhere that’s causing the problem but so far I have not been able to pinpoint it. In fact, the only solution that I’ve found so far for all of these live sites has been to roll back to LiteSpeed 6.3.0.1.

At the moment I’m working through the LiteSpeed 6.4 update code line by line to find out which one is triggering the problem. I’ll let you know what I find…

You might want to check your plugins and make sure that the latest version of “Product Recommendations – Custom Locations” is both installed and activated. Everything is working fine for me after updating to Product Recommendations to the latest 4.0.2 version but I had to go in and re-activate this “Product Recommendations – Custom Locations” to get the “Custom Locations” tab back. (For some reason upgrading this plugin to 2.0 caused it to deactivate and need to be re-activated.)

This issue has been resolved in the latest version of Woo Product Recommendations 4.0.2!

This would be a very helpful feature to have! I just added a feature request for it: https://woocommerce.com/feature-request/allow-the-cart-and-checkout-blocks-coupon-field-to-be-displayed-by-default/

I found the following snippet of code on the #developer Slack channel:

 function enqueue_open_coupon_section_script() {
	// Check if we are on the checkout page
	if ( is_checkout() || is_cart() ) {
			?>
			<script type="text/javascript">
				// using MutationObserver to detect when the coupon section is added to the DOM
				var observer = new MutationObserver(function(mutations) {
					mutations.forEach(function(mutation) {
						if (mutation.addedNodes && mutation.addedNodes.length > 0) {
							var couponButton = document.querySelector('.wc-block-components-totals-coupon button');
							if (couponButton && !document.querySelector('.wc-block-components-totals-coupon').classList.contains('is-open')) {
								couponButton.click();
								observer.disconnect();
							}
						}
					});
				});
				observer.observe(document.body, {
					childList: true,
					subtree: true
				});
			</script>
			<?php
	}
}
add_action('wp_footer', 'enqueue_open_coupon_section_script');