wpfixpath

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 destination

Set it to:

Default to customer billing address

Do 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 2 hours, 33 minutes ago by wpfixpath.

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.

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.

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.

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.

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.

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.

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.