Title: wpfixpath's Replies - page 2 | WordPress.org

---

# wpfixpath

  [  ](https://wordpress.org/support/users/wpfixpath/)

 *   [Profile](https://wordpress.org/support/users/wpfixpath/)
 *   [Topics Started](https://wordpress.org/support/users/wpfixpath/topics/)
 *   [Replies Created](https://wordpress.org/support/users/wpfixpath/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/wpfixpath/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/wpfixpath/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/wpfixpath/engagements/)
 *   [Favorites](https://wordpress.org/support/users/wpfixpath/favorites/)

 Search replies:

## Forum Replies Created

Viewing 8 replies - 16 through 23 (of 23 total)

[←](https://wordpress.org/support/users/wpfixpath/replies/?output_format=md) [1](https://wordpress.org/support/users/wpfixpath/replies/?output_format=md)
2

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WooCommerce] Delivery block inside echkout is not (always) showing](https://wordpress.org/support/topic/delivery-block-inside-echkout-is-not-always-showing/)
 *  [wpfixpath](https://wordpress.org/support/users/wpfixpath/)
 * (@wpfixpath)
 * [1 day, 15 hours ago](https://wordpress.org/support/topic/delivery-block-inside-echkout-is-not-always-showing/#post-18902450)
 * For Blocks checkout, this usually needs to be isolated by state, not screenshots
   alone.
 * Check in this order:
    1. Confirm whether affected products are physical, not virtual/downloadable.
    2. Confirm the customer address triggers the same shipping zone every time.
    3. Check whether the delivery/pickup option disappears before or after address 
       entry.
    4. Disable custom pickup/shipping logic on staging and test only core WooCommerce
       shipping/local pickup.
    5. 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Site Kit by Google - Analytics, Search Console, AdSense, Speed] Monthly reports show HTML source code](https://wordpress.org/support/topic/monthly-reports-show-html-source-code-2/)
 *  [wpfixpath](https://wordpress.org/support/users/wpfixpath/)
 * (@wpfixpath)
 * [1 day, 15 hours ago](https://wordpress.org/support/topic/monthly-reports-show-html-source-code-2/#post-18902449)
 * 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-8`
 * Working HTML email:
   `Content-Type: text/html; charset=UTF-8`
 * So the HTML body is being delivered, but the mail pipeline is labeling it as 
   plain text.
 * Check in this order:
    1. Test the Post SMTP HTML add-on/workaround on one affected site only.
    2. Do not migrate all sites or change SMTP plugin globally until one test confirms
       it.
    3. Compare headers for Site Kit vs Wordfence after the workaround.
    4. 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-Type` is telling them not to.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Rank Math SEO – AI SEO Tools to Dominate SEO Rankings] Sitemap module intermittently returns 404 until re-enabled in Rank Math settings](https://wordpress.org/support/topic/sitemap-module-intermittently-returns-404-until-re-enabled-in-rank-math-settings/)
 *  [wpfixpath](https://wordpress.org/support/users/wpfixpath/)
 * (@wpfixpath)
 * [1 day, 15 hours ago](https://wordpress.org/support/topic/sitemap-module-intermittently-returns-404-until-re-enabled-in-rank-math-settings/#post-18902440)
 * Intermittent sitemap 404 after a few days usually points to cache/rewrite/transient
   state, not normal Google crawling behavior.
 * Check in this order:
    1. Confirm whether `/sitemap_index.xml` and the failing child sitemap return 404
       at the same time.
    2. Check whether Rank Math sitemap URLs are excluded from every cache layer: plugin
       cache, server cache, LiteSpeed cache, object cache, CDN.
    3. After failure, do not toggle the module first. First check whether flushing 
       rewrite rules alone fixes it.
    4. Check whether the Rank Math sitemap transient/cache is recreated after deleting
       it.
    5. 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WooCommerce] getting Page Not Found in checkout when I select Razorpay as payment](https://wordpress.org/support/topic/getting-page-not-found-in-checkout-when-i-select-razorpay-as-payment/)
 *  [wpfixpath](https://wordpress.org/support/users/wpfixpath/)
 * (@wpfixpath)
 * [1 day, 15 hours ago](https://wordpress.org/support/topic/getting-page-not-found-in-checkout-when-i-select-razorpay-as-payment/#post-18902439)
 * 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:
    1. Test checkout with Cash on Delivery or bank transfer. If that works, WooCommerce
       checkout itself is not the primary failure.
    2. Re-save WordPress permalinks to flush rewrite rules.
    3. Confirm the Curlec/Razorpay return URL and webhook/callback URL match the site
       domain exactly, including http/https and www/non-www.
    4. Temporarily disable security/cache plugins that may block gateway callback URLs.
    5. 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](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WooCommerce] Not enough stock validation bypassed to create a new order](https://wordpress.org/support/topic/not-enough-stock-validation-bypassed-to-create-a-new-order/)
 *  [wpfixpath](https://wordpress.org/support/users/wpfixpath/)
 * (@wpfixpath)
 * [1 day, 15 hours ago](https://wordpress.org/support/topic/not-enough-stock-validation-bypassed-to-create-a-new-order/#post-18902437)
 * There are two separate paths here:
    1. Cart/session behavior after a pending payment order is created.
    2. 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:
    1. Confirm the payment gateway hook that creates the pending order.
    2. Confirm whether the pending order has reserved stock in WooCommerce’s stock 
       reservation table/state.
    3. Repeat with one product, stock = 1, only WooCommerce + payment gateway active.
    4. Compare whether the second order is created before or after `woocommerce_check_cart_items`/
       checkout validation runs.
    5. 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](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[WooCommerce] Uploading downloadable products](https://wordpress.org/support/topic/uploading-downloadable-products/)
 *  [wpfixpath](https://wordpress.org/support/users/wpfixpath/)
 * (@wpfixpath)
 * [1 day, 15 hours ago](https://wordpress.org/support/topic/uploading-downloadable-products/#post-18902422)
 * WooCommerce 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:
    1. In Media Library, open the attachment and confirm whether the original file 
       still exists at full resolution.
    2. Check Settings → Media for max image dimensions.
    3. Check whether an image optimization plugin is resizing/compressing uploads.
    4. For downloadable products, do not use the product image as the protected download
       file. Add the original file under Product data → Downloadable files.
    5. 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Rank Math SEO – AI SEO Tools to Dominate SEO Rankings] Returning an error on the Setup Wizard page](https://wordpress.org/support/topic/returning-an-error-on-the-setup-wizard-page/)
 *  [wpfixpath](https://wordpress.org/support/users/wpfixpath/)
 * (@wpfixpath)
 * [1 day, 15 hours ago](https://wordpress.org/support/topic/returning-an-error-on-the-setup-wizard-page/#post-18902421)
 * 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-ui``elementor-v2-icons`
 * Check in this order:
    1. Confirm whether `WP_DEBUG_DISPLAY` is enabled. If yes, disable display on production
       so notices do not render in the admin UI.
    2. Update Elementor and Elementor Pro together, not one without the other.
    3. Temporarily disable Elementor AI-related features/addons and reload the Rank
       Math setup wizard.
    4. 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.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Site Kit by Google - Analytics, Search Console, AdSense, Speed] PHP Warning: Undefined array key 0 in Has_Multiple_Admins.php line 93 (multisite](https://wordpress.org/support/topic/php-warning-undefined-array-key-0-in-has_multiple_admins-php-line-93-multisite/)
 *  [wpfixpath](https://wordpress.org/support/users/wpfixpath/)
 * (@wpfixpath)
 * [1 day, 15 hours ago](https://wordpress.org/support/topic/php-warning-undefined-array-key-0-in-has_multiple_admins-php-line-93-multisite/#post-18902419)
 * 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 index `0` exists. On multisite, if `get_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.

Viewing 8 replies - 16 through 23 (of 23 total)

[←](https://wordpress.org/support/users/wpfixpath/replies/?output_format=md) [1](https://wordpress.org/support/users/wpfixpath/replies/?output_format=md)
2