robertstaddon
Forum Replies Created
-
Note that there is no known POP chain present in this plugin so it would likely take an additional plugin or theme for an unauthenticated user to be able to actually inject a PHP object. The vulnerability was partially patched in version 2.2.82 and seems to be more fully patched in the latest 2.2.83 version. I would recommend updating your sites to the latest version and you should be good.
I believe this issue was most likely caused by a cache-busting version parameter not being updated correctly in WordPress 6.7 https://core.trac.ww.wp.xz.cn/ticket/62422
Clearing the CloudFlare cache (and then a Shift + refresh to clear my local browser cache) fixed it for me.
Forum: Fixing WordPress
In reply to: Blank Screen When Trying to Add a New PostClearing the CloudFlare cache (and then a Shift + refresh to clear my local browser cache) fixed the Uncaught TypeError JavaScript (reading ‘unstable_scheduleCallback’) issue on admin pages for me.
Forum: Fixing WordPress
In reply to: Can not edit pages, posts or create new onesClearing the CloudFlare cache (and then a Shift + refresh to clear my local browser cache) fixed the Uncaught TypeError JavaScript issue on admin pages for me.
Clearing CloudFlare cache (and then a SHIFT + refresh to clear local cache) also fixed this issue for me.
Forum: Plugins
In reply to: [WooCommerce Shipping] Can’t Reprint Shipping LabelsThank you for this reply, @shahzeenfarooq
I understand your reasoning. However, generating a new label for an existing order is very helpful for:
- 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.
- 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 1 year, 7 months 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://ww.wp.xz.cn/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.
Forum: Plugins
In reply to: [LiteSpeed Cache] Admin Bar Missing on front end Divi SitesThank you @hailite ! I just installed the dev branch and it worked beautifully. Looking forward to the v6.5 release!
Forum: Plugins
In reply to: [LiteSpeed Cache] Admin Bar Missing on front end Divi SitesThat’s great to hear @qtwrk ! Thank you!
Forum: Plugins
In reply to: [LiteSpeed Cache] Admin Bar Missing on front end Divi SitesThank 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?
Forum: Plugins
In reply to: [LiteSpeed Cache] Admin Bar Missing on front end Divi SitesOk, 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.