LovingBro (woo-hc)

Hi @fullcolor,

Thanks for trying that out and sharing how it turned out, I can see you were aiming to have everything nicely aligned on one line with the search.

In Storefront, the search bar is placed separately from the main menu, so having My Account, Cart, and Search all on the same line is not something it does by default.

Since you prefer to keep things simple, going with the previous setup is a great choice and works well with how Storefront is built.

If you ever want to explore changes later, this guide can help: https://woocommerce.com/document/storefront/

If anything else comes up, feel free to reach out, happy to help.

Hi @2chicks,

I can see how frustrating this behavior has been, especially with orders slipping through using Local Pickup and requiring manual follow-ups. I’ve taken time to test this thoroughly on my end to compare behavior.

From my testing on a clean setup, I consistently get the correct shipping method selected based on the customer’s location, and not Local Pickup being chosen by default. This held true across different addresses and scenarios.

In WooCommerce, both block and classic checkout treat defined shipping zones and Local Pickup as separate shipping methods. So Local Pickup should only be selected when it is the most relevant option for the detected or provided location.

To help narrow this down further on your site, I’d recommend the following:

• Go to WooCommerce > Settings > General
• Under Default customer location, enable Geolocate
• Ensure you have shipping zones properly configured for all intended regions
• Optionally, set up a “Rest of the world” shipping zone as a fallback

Once that’s in place, try placing a few test orders using different locations.

The expected behavior is that even before a full address is entered, WooCommerce attempts to match the customer to the most appropriate shipping zone or best available method, rather than defaulting incorrectly to Local Pickup.

If after this the issue persists, it would be helpful to see a quick screen recording or screenshot of the checkout flow on your site via https://loom.com or https://snipboard.io so we can observe exactly how it’s behaving in your setup.

Hi @chrisbarbers,

Thanks for the detailed update and for walking through all those tests, I can see you’ve covered a lot of ground already and the issue still persists across environments, which helps narrow this down significantly.

Given what you’ve confirmed:

• rollback did not resolve it, even on a clean test setup
• the issue occurs with both Checkout block and shortcode
• optimisation and caching have been ruled out
• and the error points to wc_stripe_upe_params intermittently not being available

this strongly suggests something environment level or script loading related rather than a simple plugin regression.

At this stage, a few more focused checks would help isolate the root cause:

1. IONOS server-side optimisation / caching Even when toggled off in the UI, IONOS can still apply server-level caching or script handling. Could you reach out to them to confirm:

• all caching layers are fully disabled for testing
• no JavaScript deferral, compression, or CDN-level optimisation is active

2. Test in a different browser / incognito with no extensions The ERR_BLOCKED_BY_CLIENT is harmless, but testing in a clean browser session helps confirm nothing is interfering with script execution timing.
3. Check if Stripe scripts are consistently loading When the fields fail to appear, open DevTools → Network tab and filter for:

• stripe
• wc-stripe
• upe-blocks

Confirm whether any of these are missing, delayed, or loading out of order compared to when the fields display correctly.

4. Temporary debug test If possible, enable WordPress debug logging to see if anything else is silently failing during checkout: https://wordpress.org/documentation/article/debugging-in-wordpress/

Given everything you’ve tested so far, this looks very much like a race condition influenced by the hosting environment rather than a direct plugin bug, especially since it persists on a minimal setup.

If you can share:

• a short screen recording showing the Network tab when the issue happens
• confirmation from IONOS about server-level optimisations

we can take a closer look and escalate this further if needed.

I’ll stay with you on this, looking forward to your findings.

Hi @donlee101,

Thanks for taking the time to share that detailed explanation, it is really helpful and adds valuable context to the discussion. Your breakdown of how barcode data consistency and uniqueness affect scanning reliability is spot on, and I am confident it will help others facing similar issues better understand what to look out for.

We truly appreciate your contribution to the community 🙌

Hi @davidecho, thanks for reaching out, I can see how frustrating it is to have the Stripe webhook repeatedly disconnect even after reconnecting, let’s work through what might be causing this.

In most cases, a webhook getting disconnected is usually due to one of the following:

• The webhook endpoint URL becoming inaccessible, for example due to firewall, security plugins, or server restrictions blocking incoming requests from Stripe
• A mismatch or reset of the webhook signing secret after reconnection
• The site returning non-200 responses to Stripe, which causes Stripe to disable the endpoint after repeated failures
• Caching or security layers interfering with the /wc-api/WC_Stripe endpoint

To move forward, please check the following:

1. Go to your Stripe Dashboard → Developers → Webhooks and confirm if the endpoint is being disabled there and if there are any delivery errors logged
2. Review your WooCommerce → Status → Logs and look for Stripe-related logs around the time the webhook disconnects
3. Ensure your site is publicly accessible and not blocking Stripe IPs or requests
4. Temporarily disable any security or firewall plugins, or server-level protections, and test again
5. Confirm there are no caching rules applied to the webhook endpoint

You can also follow this guide for a full walkthrough on webhook setup and troubleshooting: https://woocommerce.com/document/stripe/setup-and-configuration/stripe-webhooks/

If the issue persists, please share your System Status Report via https://pastebin.com or https://gist.github.com and any relevant Stripe webhook error logs. That will help us take a closer look.

Looking forward to your findings so we can narrow this down further.

Hi @chrisbarbers,

Thanks for sharing the System Status Report and for continuing to test this, I can see the issue is still intermittent even after disabling optimisation, which helps narrow things down further.

From what you’ve shared in the report and earlier console errors, the key issue still points to that wc_stripe_upe_params is not defined error, which aligns with a script timing problem where Stripe’s configuration object is not available when the block script runs.

A few important observations from your setup:

• Your WP memory limit is set to 40MB, which is below the recommended minimum. While not the root cause, this can contribute to inconsistent script execution under load. I’d recommend increasing it to at least 64MB or ideally 128MB:
  https://wordpress.org/documentation/article/editing-wp-config-php/#increasing-memory-allocated-to-php
• You’re running WooCommerce 10.7.0, and based on other reports in this thread and similar cases, this does appear to be linked to a recent update where the UPE (Unified Payment Experience) scripts are not always initializing correctly.

Since disabling WP-Optimize did not fully resolve it, here are the next focused steps:

1. Exclude Stripe scripts explicitly (if any optimisation still exists at server level)
   Even if the plugin is disabled, some hosts apply server-side JS optimisation. If your host has this, try excluding:

• stripe
• wc-stripe
• upe-blocks

2. Temporarily disable UPE (for testing)
   Go to WooCommerce → Settings → Payments → Stripe → Settings and check if there is an option to disable the new checkout experience or UPE. If available, switch it off and test checkout again.
3. Rollback test (very important)
   Another user confirmed that rolling back resolves the issue. Please try installing version 10.5.3 of the Stripe plugin and test: https://wordpress.org/plugins/woocommerce-gateway-stripe/advanced/

If the issue disappears completely after rollback, that strongly confirms a regression in the latest version.

4. Theme / block checkout check
   If you are using the Checkout Block instead of the classic shortcode, this issue is more likely to occur. If possible, test switching temporarily to the classic checkout shortcode to compare behaviour.

At this stage, given:

• the intermittent nature,
• the specific JS error,
• and confirmation from others that rollback fixes it,

this is very likely a plugin-level regression rather than something specific to your site.

Please let me know:

• if rollback resolves it for you,
• whether you’re using Checkout Block or shortcode,
• and if your host applies any server-side optimisation.

From there, we can either provide a stable workaround or escalate this properly. Looking forward to your update.

Hi @csdshop,

I can see how concerning this has become, especially now that the issue has escalated from intermittent “connection lost” errors to a full Internal Server Error on the live site. That definitely points to something deeper at the server level rather than just an editor or plugin behavior.

The “Internal Server Error” typically indicates a misconfiguration or a fatal process failure on the server, and combined with the earlier 504 timeout on admin-ajax.php, it strongly suggests that something is exhausting server resources or failing during execution.

At this stage, reaching out to your hosting provider is absolutely the right next step. When you contact them, it would help to ask them to specifically check:

• Server error logs around the exact time the issue started
• Any processes or requests causing high CPU or memory usage
• Whether any PHP limits are being hit, such as execution time or memory limits
• If there are repeated or stuck requests to admin-ajax.php or similar endpoints

Also, a couple of quick checks you can do on your side while waiting:

• Try accessing /wp-admin directly to see if the backend is still reachable
• If you have access via FTP or your hosting file manager, temporarily rename the /plugins/ folder to disable all plugins and see if the site comes back
• Check if there were any recent changes, updates, or deployments just before this started happening

Since the issue now affects the entire site and not just product editing, this is very likely outside WooCommerce itself and tied to either the server environment or a failing process.

Once your host shares the logs or findings, feel free to paste them via https://pastebin.com or https://gist.github.com and we can take a closer look with you. We’ll stay with you on this and help narrow it down 👍

Hi @Adrianmkl,

Thanks for sharing the details here, I can see how being stuck in a login loop when trying to connect your Square account would block progress, and I’m happy to help you work through this.

This type of behavior is often related to session handling or a conflict preventing the connection from being properly stored. To narrow this down, please go through the following checks:

1. Clear your site cache, browser cache, and any server level caching you may have in place, then try reconnecting again in a private or incognito browser window.
2. Temporarily disable all plugins except WooCommerce and WooCommerce Square, and switch to a default theme like Storefront. Then attempt to connect your Square account again. If it works, you can re enable everything one by one to identify the conflict.
3. Confirm that your site URL in WordPress settings matches exactly what is configured in your Square account, including https and www consistency, as mismatches can cause repeated auth redirects.
4. Ensure your site is publicly accessible, not behind maintenance mode, firewall restrictions, or basic auth, as Square needs to complete the OAuth handshake.
5. If you are using any security or firewall plugin or service, try temporarily disabling it or allowlisting Square related requests to rule out blocking.

You can also review the official setup guide here for reference:
https://woocommerce.com/document/woocommerce-square/

If the issue persists after these checks, please share your System Status Report via https://pastebin.com or https://gist.github.com so we can take a closer look.