Title: wpfixpath's Replies | 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 15 replies - 1 through 15 (of 23 total) 1 [2](https://wordpress.org/support/users/wpfixpath/replies/page/2/?output_format=md) [→](https://wordpress.org/support/users/wpfixpath/replies/page/2/?output_format=md) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WooCommerce PayPal Payments] Invalid Payment Method](https://wordpress.org/support/topic/invalid-payment-method-20/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [4 hours, 7 minutes ago](https://wordpress.org/support/topic/invalid-payment-method-20/#post-18903536) * Glad the shortcode checkout fixed the PayPal issue. For the “Ship to a different address?” control, that one is actually a WooCommerce checkbox.First try the normal WooCommerce setting:WooCommerce → Settings → Shipping → Shipping options/ Shipping settings → Shipping destinationSet it to:Default to customer billing addressDo not choose “Force shipping to customer billing address” unless you want to remove the different shipping address option completely.Then clear any checkout/page cache and reload the checkout page in a private/incognito window. If Divi or another checkout customization is still forcing it checked, you can force the default state to unchecked with this small snippet:add_filter( ‘woocommerce_ship_to_different_address_checked’,‘ __return_false’ );Add that through a child theme functions.php file or a code snippets plugin, not by editing WooCommerce core/template files directly.Customers will still be able to tick the box manually if their shipping address is different from their billing address. - This reply was modified 4 hours, 6 minutes ago by [wpfixpath](https://wordpress.org/support/users/wpfixpath/). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Site Kit by Google - Analytics, Search Console, AdSense, Speed] Add to cart events not firing](https://wordpress.org/support/topic/add-to-cart-events-not-firing/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [18 hours, 16 minutes ago](https://wordpress.org/support/topic/add-to-cart-events-not-firing/#post-18903303) * If the custom theme changed the add-to-cart button markup/behavior, that is probably the right place to inspect. * I would check whether the custom button still uses the normal WooCommerce add- to-cart path: - standard add-to-cart form/button classes - correct product ID / variation ID - correct quantity field - normal WooCommerce AJAX add-to-cart request - no custom JS that updates cart UI without firing the expected WooCommerce event path * If the theme bypasses WooCommerce’s normal add-to-cart event flow, Site Kit / Google for WooCommerce may have nothing standard to listen to. * Fast verification path: 1. Test one product with a default WooCommerce theme or default add-to-cart template. 2. Use Tag Assistant realtime/debug while clicking Add to cart. 3. Compare the custom theme request vs the default WooCommerce request. 4. If the custom theme must stay custom, either restore the expected WooCommerce hooks/markup or manually push the ecommerce event in a controlled way. * The key is to avoid debugging Analytics first if the frontend never emits a recognizable add-to-cart action. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WooCommerce PayPal Payments] Failed Order Process Then Processed Causing Duplicate Order](https://wordpress.org/support/topic/failed-order-process-then-processed-causing-duplicate-order/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [18 hours, 17 minutes ago](https://wordpress.org/support/topic/failed-order-process-then-processed-causing-duplicate-order/#post-18903302) * After disabling the PayPal button on the cart page, I would run one controlled test and compare the log sequence before/after. * The thing to verify is whether you now have only one PayPal entry point into the order flow. * Test path: 1. Clear PayPal/WooCommerce logs or note the current timestamp. 2. Start checkout only from the normal WooCommerce checkout page. 3. Complete one low-value live or sandbox transaction. 4. Check whether these log messages disappear or reduce: * - `WC order ID was not found in webhook event` - `Order is already being processed` - `already has transaction ID, skipping payment processing` - duplicate Woo order IDs for one PayPal transaction * If the duplicate order behavior stops after removing the cart PayPal button, the likely issue was competing entry points: cart express flow + checkout/order flow + webhook timing. * If it still happens, the next useful evidence is a timestamped mapping table: - Woo order ID - PayPal order ID - PayPal capture ID - first Woo order note timestamp - webhook event type - whether customer returned to the site successfully - whether the same browser/customer retried checkout * Without that mapping it is very hard to separate harmless webhook retry noise from actual duplicate order creation. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WooCommerce PayPal Payments] Invalid Payment Method](https://wordpress.org/support/topic/invalid-payment-method-20/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [18 hours, 18 minutes ago](https://wordpress.org/support/topic/invalid-payment-method-20/#post-18903301) * Since PayPal works on the Cart page but fails on the Checkout page, I would not treat this as a popup problem first. * “Invalid Payment Method” usually means WooCommerce is receiving a checkout submission where the selected payment method is not valid/available in that checkout context. * Check these in order: 1. Confirm whether the Checkout page is using the Checkout Block or the classic`[ woocommerce_checkout]` shortcode. 2. Temporarily disable cache/minification for: * - checkout page - cart page - account page - WooCommerce AJAX endpoints - `/wp-json/` * 1. In WooCommerce → Settings → Payments → PayPal, confirm the PayPal method is enabled for the Checkout location, not only Cart/product express buttons. 2. Test with only: * - WooCommerce - WooCommerce PayPal Payments - default theme - no checkout customizer - no payment/coupon/cart drawer plugin * 1. Open browser DevTools on checkout and check: * - console errors - network errors - whether the checkout request includes the expected `payment_method` * Venmo visibility is also eligibility-dependent. It can be enabled in settings and still not appear depending on merchant account, country, buyer/browser/device, and PayPal eligibility. I would debug the main PayPal checkout failure first, then Venmo second. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[LiteSpeed Cache] Fatal error enabling Object Cache (Redis) – undefined function](https://wordpress.org/support/topic/fatal-error-enabling-object-cache-redis-undefined-function/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [18 hours, 20 minutes ago](https://wordpress.org/support/topic/fatal-error-enabling-object-cache-redis-undefined-function/#post-18903299) * This looks like two separate checks, not only a Redis credential problem. 1. The failed Redis connection test should be isolated first: * - confirm the exact Redis host/port/password from the hosting panel - if the host provides a Redis CLI/test tool, test the same host/port/password outside WordPress - confirm whether Redis is available to PHP on the same account/container, not just enabled in cPanel * 1. The fatal error is a different signal. An “undefined function” inside the LiteSpeed object-cache save path usually points to a stale/partial plugin/drop-in/bootstrap state, not normal Redis failure. * I would test this sequence on one affected site only: - leave Object Cache OFF - delete `wp-content/object-cache.php` - delete `wp-content/advanced-cache.php` only if you know it belongs to the previous cache setup - fully remove the LiteSpeed Cache plugin folder, not just deactivate/reactivate - reinstall a clean copy of LiteSpeed Cache - restart/flush PHP OPcache if the host exposes that option - test on PHP 8.3 first, not 8.4/8.5 - then enable Object Cache again * If the same fatal error appears after a clean plugin reinstall + no old drop- in + OPcache flush, then it is likely a LiteSpeed Cache 7.8.x bug or host-specific bootstrap bug and worth reporting with the exact plugin version, PHP version, and stack trace. * For now, keeping Object Cache disabled and using page cache only is the right safe state. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Payments via Teya Payments for Woocommerce] The plugin doesn’t handle the stocks when the customer cancels the order](https://wordpress.org/support/topic/the-plugin-doesnt-handle-the-stocks-when-the-customer-cancels-the-order/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [1 day, 3 hours ago](https://wordpress.org/support/topic/the-plugin-doesnt-handle-the-stocks-when-the-customer-cancels-the-order/#post-18903002) * That extra test is useful, but I would be careful with the conclusion. * A Pending payment -> Cancelled test does not always prove that WooCommerce failed to restore stock. It depends on whether stock was actually reduced in the first place. * There are two different cases: 1. Actual stock was reduced In that case the order/item should normally have stock- reduction state, and cancellation should restore it. 2. Stock was only held/reserved while the order was pending In that case the product stock quantity may not have been reduced in the normal “Stock levels reduced” sense, so there may be no “Stock levels increased” order note to add. The issue would then be whether the held/reserved stock was released, not whether reduced stock was restored. * For the next test, I would separate those two things: 1. Create a test product with managed stock = 3. 2. Record the product’s actual stock quantity before checkout. 3. Place the order through Teya and stop at Pending payment. 4. Check whether the actual product stock quantity changed. 5. Check the order notes for “Stock levels reduced”. 6. If possible, check whether the order item has reduced-stock state/meta. 7. Cancel the order. 8. Check whether actual stock changes, whether held/reserved stock clears, and whether an order note is added. * The important branch is: - If actual stock never decreased, then there is nothing for WooCommerce to “ restore”; the problem is probably held/reserved stock not being released or the stock display including held stock. - If actual stock did decrease but there is no stock-reduction note/meta, then something may be reducing stock outside WooCommerce’s normal stock-reduction path. - If actual stock did decrease and the order is marked as stock-reduced, but cancellation does not increase it, then the restore path is being blocked or not triggered. * So I would not call it a plain WooCommerce Pending payment -> Cancelled bug yet. First confirm whether Teya is reducing stock, reserving stock, or changing order status in a way that bypasses WooCommerce’s normal stock bookkeeping. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WPS Hide Login] Password Reset Links Invalid When WPS Hide Login Is Enabled](https://wordpress.org/support/topic/password-reset-links-invalid-when-wps-hide-login-is-enabled/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [1 day, 3 hours ago](https://wordpress.org/support/topic/password-reset-links-invalid-when-wps-hide-login-is-enabled/#post-18903000) * You are right — I worded that part too broadly. * The final visible URL does not necessarily need to keep key and login forever. In the normal reset flow those values may be consumed first, then the browser can move into the action=rp step. * The thing I would inspect is not “do key/login remain visible in the final URL”, but this: - which URL first receives the key/login values - whether that request is handled by the expected login/reset endpoint - whether the reset-pass cookie/state is created before the redirect to action =rp - whether the redirect chain jumps between different login systems before WordPress/ EDD can validate the same flow * In your case, the EDD login page being set to a different URL than the WPS Hide Login URL sounds like the important clue. * I would treat this as a canonical-login-URL mismatch: 1. WPS Hide Login has one custom login URL. 2. EDD has its own configured login/reset URL. 3. WordPress core still has wp-login.php?action=rp/resetpass behavior. 4. If the reset flow starts on one of those URLs and then redirects into another before the reset state is established, the key can appear invalid even though the email link was fresh. * A useful Network-tab test would be: 1. Generate a fresh reset link. 2. Open DevTools > Network before clicking it. 3. Click the link. 4. Find the first request containing key and login. 5. Check the next redirect location. 6. Check whether it moves through the WPS URL, the EDD login URL, or wp-login.php. 7. Compare that with the working configuration where EDD and WPS use the same login URL. * If aligning the EDD login/reset URL with the WPS Hide Login URL fixes it, then this is probably not a bad reset key. It is the reset flow being split across two login URL handlers. * 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, 3 hours ago](https://wordpress.org/support/topic/returning-an-error-on-the-setup-wizard-page/#post-18902999) * That confirms the issue is coming from the Elementor AI asset loading path, not from the Rank Math setup wizard itself. * The notice says this script is being enqueued: * elementor-ai-media-library * but its dependencies are not registered: * elementor-v2-ui elementor-v2-icons * So there are two separate things here: 1. Workaround Keeping Elementor AI disabled is the safe workaround if you are not using those features. 2. Actual fix The real fix needs to happen in the Elementor/Elementor Pro side: the AI feature should not enqueue a script whose dependencies are missing, or it should only enqueue those assets on screens where the dependencies are available. * I would also check these before reporting it: - Elementor and Elementor Pro are both updated together - no mixed old/new Elementor versions - no admin asset optimization/minification plugin is changing script loading - no custom code is deregistering Elementor admin scripts * If all of that is clean, I would report it to Elementor/Elementor Pro support with the exact notice and mention that it appears when Elementor AI is enabled on the Rank Math setup wizard screen. * Separately, if this is a production site, make sure PHP notices are not displayed in the admin/browser output. That does not fix the missing dependency, but it prevents debug notices from being printed into admin screens. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WooPayments: Integrated WooCommerce Payments] Stripe Payment Element iframe height is incorrect on mobile and cuts off fields](https://wordpress.org/support/topic/stripe-payment-element-iframe-height-is-incorrect-on-mobile-and-cuts-off-fields-2/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [1 day, 6 hours ago](https://wordpress.org/support/topic/stripe-payment-element-iframe-height-is-incorrect-on-mobile-and-cuts-off-fields-2/#post-18902796) * One extra thing to check on the staging copy: inspect the iframe parent containers, not only the iframe itself. * With Stripe/Payment Element fields, the iframe height is controlled by the payment script, but the visible cutoff can still happen if a parent container has restrictive CSS. * On mobile, check the computed styles for the payment section and its parents: - overflow: hidden - fixed height / max-height - transform - display grid/flex alignment issues - animation/collapse classes - checkout accordion/tab wrappers - theme or builder CSS applying height constraints * A useful test is: 1. On staging, switch to a default theme. 2. Disable custom checkout CSS and builder styling. 3. Test the same mobile viewport. 4. If the iframe height becomes correct, re-enable theme/custom CSS in pieces. 5. If it remains cut off even on a clean staging setup, then it is more likely WooPayments/Stripe rendering rather than theme clipping. * Also capture the computed CSS of the iframe wrapper when it is broken. That will give support more useful data than only a screenshot. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[LiteSpeed Cache] Invalid WP API response](https://wordpress.org/support/topic/invalid-wp-api-response-4/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [1 day, 7 hours ago](https://wordpress.org/support/topic/invalid-wp-api-response-4/#post-18902788) * Since you cannot share the report ID publicly, I would debug the response path rather than the UCSS result itself. * That message usually means the remote LiteSpeed node notified WordPress, but WordPress returned something other than the expected REST/API response. * Check these privately: 1. Open this in a logged-out browser: /wp-json/ * It should return JSON, not HTML, a redirect, a firewall page, or a maintenance page. 2. Check server access logs around the time of the error for requests from: 38.114.121.40 * Look at the status code and response type. 3. Check whether any layer is blocking or changing REST requests: * - Cloudflare/WAF/Bot Fight mode - ModSecurity - security plugin - basic auth - maintenance mode - custom redirects - cache-everything CDN rule * 3. Exclude REST/API paths from aggressive cache/security rules: /wp-json/*admin- ajax.phpLiteSpeed callback/API paths if present in the logs 4. Temporarily disable UCSS and reproduce. If the warning stops, the issue is likely the callback/notification path rather than general page speed. * If privacy is the concern, the private ticket is still probably the right route, but the server logs should show whether WordPress returned JSON, a 403, a redirect, or an HTML error page. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[WPS Hide Login] Password Reset Links Invalid When WPS Hide Login Is Enabled](https://wordpress.org/support/topic/password-reset-links-invalid-when-wps-hide-login-is-enabled/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [1 day, 7 hours ago](https://wordpress.org/support/topic/password-reset-links-invalid-when-wps-hide-login-is-enabled/#post-18902781) * This sounds less like email delivery and more like the reset URL being rewritten or redirected in a way that changes what WordPress validates. * I would isolate it like this: 1. Generate a fresh reset link with WPS Hide Login enabled. 2. Before clicking it, copy the exact URL from the email. 3. Open DevTools > Network, then load the reset link. 4. Check whether there is any redirect before the final page. 5. Compare the original URL and final URL. * The important part is whether these survive unchanged: - action - key - login * If the link is redirected from wp-login.php to the custom login URL, or from the custom login URL back to another path, the key/login values may be preserved visually but handled differently by the login flow. * Also check that the custom login URL and wp-login.php reset actions are excluded from: - page cache - CDN cache - security/WAF rules - “cache everything” rules - login protection plugins - any plugin that rewrites query strings * The fastest comparison test would be: - WPS Hide Login disabled: copy working reset URL format - WPS Hide Login enabled: copy failing reset URL format * If the only material difference is the login path/redirect path, the issue is probably in the login URL rewrite/reset handling rather than the password reset key itself. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Payments via Teya Payments for Woocommerce] The plugin doesn’t handle the stocks when the customer cancels the order](https://wordpress.org/support/topic/the-plugin-doesnt-handle-the-stocks-when-the-customer-cancels-the-order/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [1 day, 7 hours ago](https://wordpress.org/support/topic/the-plugin-doesnt-handle-the-stocks-when-the-customer-cancels-the-order/#post-18902762) * This is worth checking at the WooCommerce order-status transition level. * When stock is reduced/restored correctly, the order notes usually show the stock action. Since you are seeing no note about restoring stock, the cancellation path may not be triggering WooCommerce’s normal stock restoration flow. * I would test this: 1. Create one test product with managed stock = 1. 2. Place an order through the Teya payment flow. 3. Cancel or let the payment timeout. 4. Open the order notes and check whether WooCommerce logged stock reduction/restoration. 5. Compare with a manual cancellation from wp-admin for the same kind of order. * The plugin author should check whether the plugin is cancelling the order through the normal WooCommerce status transition, not by directly setting state or bypassing hooks. * The important thing to verify is whether WooCommerce sees this as a real transition into cancelled/failed status after stock was reduced. If that transition is bypassed, stock restoration will not reliably run. * I would avoid adding a custom “restore stock on cancelled” hook as a permanent workaround until the plugin author confirms the flow, because it could double- restore stock in some cases. * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[Rank Math SEO – AI SEO Tools to Dominate SEO Rankings] post_tag-sitemap.xml don’t work](https://wordpress.org/support/topic/post_tag-sitemap-xml-dont-work/) * [wpfixpath](https://wordpress.org/support/users/wpfixpath/) * (@wpfixpath) * [1 day, 7 hours ago](https://wordpress.org/support/topic/post_tag-sitemap-xml-dont-work/#post-18902761) * A few things to isolate before treating this as a general sitemap failure: 1. Open the child sitemap directly: post_tag-sitemap.xml 2. Check whether the tag taxonomy actually has indexable terms: * - tags exist - tags are attached to published posts - the tag archive is not set to noindex - the individual tag terms are not set to noindex * If there are no indexable tag terms, the post_tag sitemap can fail or appear missing even when “Include in Sitemap” is enabled. 3. Flush the sitemap/rewrite state: * - Rank Math > Sitemap Settings: turn sitemap off, save, turn it on, save - Settings > Permalinks: save once without changes - clear page cache/CDN/object cache * 3. Exclude sitemap URLs from caching if you use a cache/CDN layer: sitemap_index. xml*-sitemap.xml * If only the post_tag sitemap fails while other child sitemaps work, I would focus on taxonomy/indexability/caching first rather than the main sitemap index. * 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, 12 hours ago](https://wordpress.org/support/topic/php-warning-undefined-array-key-0-in-has_multiple_admins-php-line-93-multisite/#post-18902480) * This is good evidence and confirms the exact failure mode. * The important part is: - `get_super_admins()` returns a non-empty array - the only key is `5` - key `0` does not exist - raw `site_admins` is `{"5":"svenms"}` * So the current check: * ! empty( $super_admins ) is not sufficient before reading: * $super_admins[0] The issue is not whether the site has a super admin. It does. The issue is that get_super_admins() does not guarantee a zero-based array. * For reproduction, a multisite install with a sparse site_admins option should be enough: * update_site_option( ‘site_admins’, array( 5 => ‘svenms’ ) ); Then any code path that assumes $super_admins[0] can trigger the PHP 8 warning. * The plugin-side fix should avoid assuming key 0, for example: * $login = reset( $super_admins ); or normalize first: * $super_admins = array_values( $super_admins ); $login = $super_admins[0] ?? null; A site-side workaround would be to normalize the stored site_admins option, but that should not be necessary for Site Kit to avoid the warning. * 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, 13 hours ago](https://wordpress.org/support/topic/uploading-downloadable-products/#post-18902460) * One extra clarification that may help separate the two issues: * If the problem is the product image looking lower quality on the product page, check which generated image size the theme is rendering and whether `srcset` is selecting a smaller variant. In that case the fix is usually image-size/theme/ display related, not the downloadable-file setup. * If the problem is the paid file itself losing quality, treat it separately from the product/gallery image. Upload the original file as the downloadable file, or use an external/protected URL for the actual asset if the file needs to remain untouched. * So I would first confirm which file is affected: 1. the display image shown on the product page 2. the original file in Media Library 3. the actual file delivered after purchase * Those are three different paths and should not be debugged as one issue. Viewing 15 replies - 1 through 15 (of 23 total) 1 [2](https://wordpress.org/support/users/wpfixpath/replies/page/2/?output_format=md) [→](https://wordpress.org/support/users/wpfixpath/replies/page/2/?output_format=md)