LovingBro (woo-hc)

Hi @nesheeg34,

Great to hear that you were able to track this down and get things working again, that is a really helpful update and will definitely benefit others who might run into something similar.

Since everything is now sorted, we’ll go ahead and consider this resolved. If you need any further help with WooCommerce in the future, feel free to open a new topic anytime, we’re always happy to help.

If you’ve been enjoying WooCommerce and the support provided, we’d really appreciate it if you could take a moment to leave a review. Your feedback helps other merchants make informed decisions:
https://wordpress.org/support/plugin/woocommerce/reviews/#new-post

Hi @mikeatagita,

I can see what you’re running into here, the add to cart URL is working in terms of adding the product, but the unexpected redirect back to the homepage is definitely not the default behaviour you’re aiming for. Let’s get this behaving as expected.

From what you’ve described and tested, your workaround using the full page URL confirms that WooCommerce itself is not forcing the redirect globally. This points more toward something in the environment altering how the request is handled.

A few things to check here:

1. Theme or plugin interference
   Even with the redirect setting disabled, a theme or plugin can hook into the add to cart process and force a redirect. Since you’re using Elementor and a few other plugins, it would be worth doing a quick conflict test. You can follow this guide to safely test: https://woocommerce.com/document/how-to-test-for-conflicts/
2. Custom code or template overrides
   If there’s any custom code, snippets, or Elementor templates handling buttons or links, they may be overriding the default behaviour. Especially if the link is being output dynamically.
3. URL structure
   Using just /?add-to-cart=604 relies on WooCommerce resolving the current page correctly. In some setups, especially with custom post types like your “catalog”, WordPress may fall back to the homepage. That explains why appending it to the full page URL works consistently.

In cases like this, the recommended approach is actually to use the full URL, for example:
https://your-site.com/current-page/?add-to-cart=604
This ensures the redirect target is explicit and avoids ambiguity in routing.

You can also review how add to cart URLs are intended to work here:
https://woocommerce.com/document/quick-guide-to-woocommerce-add-to-cart-urls/

If after a conflict test the issue disappears, that will confirm something in the stack is forcing the redirect and we can narrow it down further.

Let me know what you find after that, happy to continue digging into this with you.

Hi @giannisdigitup,

Thanks for clearly outlining what you’ve tried here, I can see the goal is to remove a specific shipping method from the Express Checkout flow, and it’s understandable this is frustrating now that the previous approach is no longer working and triggering notices.

From what you’ve found, you’re correct that the filter you were relying on is no longer available in the updated version of the WooCommerce Stripe Payment Gateway plugin. Since your earlier solution depended on modifying the plugin file directly, those changes would have been overwritten during updates.

As a quick workaround, you can reintroduce the filter in the plugin file again and your existing snippet should start working as before. That said, this approach is not update safe, meaning the change will be lost each time the plugin is updated.

A more sustainable approach would be to have a developer implement this customization in a way that does not rely on editing plugin core files, for example by extending functionality via hooks or a custom integration layer. This helps ensure updates won’t break your setup.

Regarding the PHP notice you’re seeing, it would also be worth confirming whether it disappears after removing the current custom snippet and reverting any plugin file changes, just to isolate whether it’s tied directly to this customization.

Let me know if you need further help, happy to continue working through this with you.

Hi @mrfragrance,

Thanks for reaching out, I can see you have already added your Google Analytics Tracking ID and are now looking for where to manage things within the plugin.

The Google Analytics for WooCommerce plugin does not have a separate dashboard of its own. Instead, all its settings are handled directly within your WooCommerce settings.

You can find it here: WooCommerce → Settings → Integration → Google Analytics
That section is essentially the “control panel” for the plugin, where you configure tracking options and confirm your setup.

If you were expecting to see reports or analytics data, those will not appear in WordPress. You will need to view them directly in your Google Analytics account, as the plugin’s role is to send data there rather than display it locally. You can learn more about how the integration works here:
https://woocommerce.com/document/google-analytics-integration/

Let me know if you were expecting a specific feature or view, happy to guide further 🙂

Hi @2chicks,

Thanks for taking the time to test this thoroughly and for clearly outlining the behavior you are seeing, I can see how this would feel inconsistent and not aligned with expected shipping logic, and I appreciate you flagging it.

What you are experiencing is tied to how the block-based checkout currently handles shipping rate estimation before a full address is provided. In this flow, WooCommerce may surface available methods like Local Pickup early, even without a confirmed customer location, and then recalculate as more address details are entered. That said, the behavior you described where Local Pickup does not reappear after entering a valid nearby address does not sound correct and is worth investigating further.

To move this forward, could you please share a System Status Report so we can better understand your setup and try to reproduce this more accurately? You can find how to get it here:
https://woocommerce.com/document/understanding-the-woocommerce-system-status-report/

Please share it via a paste service like https://pastebin.com or https://gist.github.com

In the meantime, it would also help to confirm:
– How your shipping zones are configured and which zones include Local Pickup
– Whether this occurs with a default theme like Storefront and only WooCommerce active

This will help determine if this is expected behavior, a configuration issue, or something that needs to be escalated. Looking forward to your findings so we can dig deeper into this.

Hi @billbobong147,

Thanks for the detailed breakdown here, I can see you’ve already verified key areas like Action Scheduler and that orders are being created correctly, so it’s definitely worth digging deeper into why the webhook isn’t even attempting delivery.

If no delivery logs are being generated at all, it usually means WooCommerce is not triggering the webhook event in the first place, rather than the request being blocked later.

A few things you can check:

1. Webhook status and configuration: Ensure the webhook is set to Active and the topic is correctly set to “Order created”. You can also try recreating the webhook to rule out any corruption.
2. Order creation trigger: Webhooks for “Order created” fire when the order is initially created. If orders are being imported or created programmatically, some flows may bypass the trigger. As a test, try placing a manual order from the frontend and see if that generates a delivery log.
3. Scheduled Actions and WP-Cron: Even though Action Scheduler is working, webhook delivery depends on WP-Cron running reliably. On some hosting setups, especially with Cloudflare involved, WP-Cron may not trigger as expected. You can confirm this by checking: WooCommerce > Status > Scheduled Actions. Look for any pending or failed woocommerce_deliver_webhook_async actions.

Guide: https://woocommerce.com/document/understanding-the-woocommerce-system-status-report/scheduled-actions/

4. REST API and loopback requests: Webhook delivery relies on outbound HTTP requests. If your server blocks loopback or external requests, nothing will be sent. You can test this under: WooCommerce > Status > Tools > “Check system status”. Look for REST API or loopback failures.
5. Server level blocking (Cloudflare / hosting): Cloudflare or the host may block outgoing requests silently. You can temporarily disable Cloudflare or whitelist outbound requests to test. Also check with Hostinger if outbound HTTP requests are restricted.
6. Debug logging: Enable logging to see if anything is being attempted: WooCommerce > Status > Logs Select “webhooks-delivery” or similar logs if available.

If after these checks there are still no delivery logs, it would be helpful to see your System Status Report so we can take a closer look at your setup. You can share it via https://pastebin.com or https://gist.github.com.

Let us know what you find from the above, happy to keep digging with you on this.

Hi @musizaidi,

Thanks for reaching out about this, I can see how frustrating it must be to get logged out of the admin area specifically when activating WooCommerce, especially after already testing with other plugins disabled. Let’s work through this together.

This kind of behavior is often related to session or cookie handling, which can be affected by things like site URL mismatches, caching, or server level configurations.

To help narrow this down, could you please check the following:

1. Confirm that your WordPress Address (URL) and Site Address (URL) match exactly under Settings → General. Even a difference like http vs https or www vs non-www can cause logout issues.
2. Try clearing your browser cache and cookies, or test in an incognito/private window to rule out a browser-related session issue.
3. Temporarily switch to a default theme like Twenty Twenty-Four and test again with only WooCommerce active.
4. If you are using any server-level caching, CDN, or security/firewall (like Cloudflare), try temporarily disabling it to see if that affects the behavior.
5. Check if your hosting environment is forcing sessions to expire quickly or blocking cookies.

If the issue persists after these checks, it would be helpful to take a closer look at your setup. Please share your System Status Report so we can better understand your environment: https://woocommerce.com/document/understanding-the-woocommerce-system-status-report/

You can paste it via https://pastebin.com or https://gist.github.com and share the link here.

Looking forward to your findings so we can continue troubleshooting with you.

Hi @cshinkin,

Thanks for sharing the System Status Report, that’s helpful to have.

That said, I noticed the earlier questions and initial checks we asked about weren’t addressed. The SSR on its own doesn’t give us enough context to move forward, so we’ll need your input on those points to properly understand what’s going on.

Could you please go back to the previous message and provide clarity on the following:

• Whether anything recently changed on your site, such as updates to WooCommerce, WordPress, or other plugins
• Which Royal Mail integration plugin you’re using
• What you’re currently seeing when attempting to use the integration, including any errors or unexpected behavior
• Feedback on the initial checks suggested earlier, such as verifying API credentials, confirming the plugin is up to date, and reviewing logs under WooCommerce > Status > Logs

Once we have those details alongside your SSR, we can properly investigate and guide you on the next steps.