wpfixpath
Forum Replies Created
-
Forum: Plugins
In reply to: [WooCommerce] Delivery block inside echkout is not (always) showingFor Blocks checkout, this usually needs to be isolated by state, not screenshots alone.
Check in this order:
- Confirm whether affected products are physical, not virtual/downloadable.
- Confirm the customer address triggers the same shipping zone every time.
- Check whether the delivery/pickup option disappears before or after address entry.
- Disable custom pickup/shipping logic on staging and test only core WooCommerce shipping/local pickup.
- Watch the network requests during checkout and compare a working load vs a failing load.
The key evidence is whether the shipping method data is absent from the checkout response, or present in the response but not rendered by the block.
The evidence points to an email MIME/header problem, not the email client.
Your transcript difference is the key:
Site Kit email:
Content-Type: text/plain; charset=UTF-8Working HTML email:
Content-Type: text/html; charset=UTF-8So the HTML body is being delivered, but the mail pipeline is labeling it as plain text.
Check in this order:
- Test the Post SMTP HTML add-on/workaround on one affected site only.
- Do not migrate all sites or change SMTP plugin globally until one test confirms it.
- Compare headers for Site Kit vs Wordfence after the workaround.
- Keep Site Kit monthly reports disabled on client sites until the fix ships, if the report renders raw HTML.
The issue is not whether Gmail/Thunderbird can render HTML. They can. The wrong
Content-Typeis telling them not to.Intermittent sitemap 404 after a few days usually points to cache/rewrite/transient state, not normal Google crawling behavior.
Check in this order:
- Confirm whether
/sitemap_index.xmland the failing child sitemap return 404 at the same time. - Check whether Rank Math sitemap URLs are excluded from every cache layer: plugin cache, server cache, LiteSpeed cache, object cache, CDN.
- After failure, do not toggle the module first. First check whether flushing rewrite rules alone fixes it.
- Check whether the Rank Math sitemap transient/cache is recreated after deleting it.
- Check cron timing and any cleanup job that runs before the sitemap disappears.
The important test is: when the 404 happens, does a rewrite flush fix it, or does only disabling/re-enabling the module fix it? That separates rewrite-state failure from Rank Math sitemap cache/state failure.
A 404 after selecting the gateway usually means the return/redirect path or callback endpoint is not matching what the plugin expects.
Check in this order:
- Test checkout with Cash on Delivery or bank transfer. If that works, WooCommerce checkout itself is not the primary failure.
- Re-save WordPress permalinks to flush rewrite rules.
- Confirm the Curlec/Razorpay return URL and webhook/callback URL match the site domain exactly, including http/https and www/non-www.
- Temporarily disable security/cache plugins that may block gateway callback URLs.
- Check server logs at the exact checkout attempt timestamp for the requested URL that returned 404.
Do not change multiple gateway settings at once. First capture the exact URL that is returning 404.
Forum: Plugins
In reply to: [WooCommerce] Not enough stock validation bypassed to create a new orderThere are two separate paths here:
- Cart/session behavior after a pending payment order is created.
- Whether checkout validation blocks creation of a second order when stock is already reserved.
For diagnosis, I would avoid manual status changes. They do not replay the same stock-reservation path as checkout/payment flow.
Check in this order:
- Confirm the payment gateway hook that creates the pending order.
- Confirm whether the pending order has reserved stock in WooCommerce’s stock reservation table/state.
- Repeat with one product, stock = 1, only WooCommerce + payment gateway active.
- Compare whether the second order is created before or after
woocommerce_check_cart_items/ checkout validation runs. - Check whether the gateway creates the order directly instead of letting the normal checkout validation sequence complete.
The important evidence is not only “stock message appears.” It is whether the second order is created before validation blocks the checkout.
Forum: Plugins
In reply to: [WooCommerce] Uploading downloadable productsWooCommerce is probably not “damaging” the original upload. WordPress creates resized image variants automatically, and many themes/plugins display one of those generated sizes instead of the original file.
Check this in order:
- In Media Library, open the attachment and confirm whether the original file still exists at full resolution.
- Check Settings → Media for max image dimensions.
- Check whether an image optimization plugin is resizing/compressing uploads.
- For downloadable products, do not use the product image as the protected download file. Add the original file under Product data → Downloadable files.
- For PDFs/ZIPs, upload through the downloadable file field or store outside the media library if you need stricter file handling.
The product/gallery image and the paid downloadable asset should be treated as two different files.
This does not look like a Rank Math setup failure first. The message says Elementor is enqueueing a script with missing registered dependencies:
elementor-ai-media-library
depends on:elementor-v2-uielementor-v2-iconsCheck in this order:
- Confirm whether
WP_DEBUG_DISPLAYis enabled. If yes, disable display on production so notices do not render in the admin UI. - Update Elementor and Elementor Pro together, not one without the other.
- Temporarily disable Elementor AI-related features/addons and reload the Rank Math setup wizard.
- Check browser console/network tab to see whether the wizard actually fails or whether this is only a PHP notice being displayed above the page.
Do not change SEO settings yet. First isolate whether this is just debug output or a real JS dependency failure.
This looks like a real plugin-side edge case, not a normal site configuration issue.
The key point is that
! empty( $super_admins )only proves the array has values. It does not prove index0exists. On multisite, ifget_super_admins()returns a keyed or sparse array,$super_admins[0]can throw this PHP 8 warning.The safer pattern would be one of:
$login = reset( $super_admins );
or:
$super_admins = array_values( $super_admins );
$login = $super_admins[0] ?? null;
Before patching locally, I would check whether anything is filtering or modifying the super admin list. Search custom plugins/theme code for site_admins or get_super_admins.For production, I would not suppress warnings as the fix. Confirm the array shape first, then let Site Kit patch the access pattern.