LovingBro (woo-hc)

Hi @klloyd86,

Thank you for bringing this to our attention. I can understand how concerning it is when the Shipment Tracking functionality stops working after updating the Stripe plugin, and I’d like to gather a few more details so we can investigate this properly.

Could you please share the following:

1. The exact version of WooCommerce Stripe Payment Gateway currently installed on your site.
2. The version of the Shipment Tracking extension you are using.
3. A screenshot or screen recording showing what happens when you try to add or expand the shipment tracking section.
4. Whether the issue disappears immediately after disabling the Stripe plugin, while keeping all other plugins active.
5. Your site’s System Status Report. You can find it via WooCommerce > Status > Get system report > Copy for support.

Please share the report using one of the following services: https://pastebin.com https://quickforget.com https://gist.github.com

Once we have these details, we’ll be in a much better position to narrow down what may be causing the conflict.

Hi @rossymina,

I understand how frustrating this can be, especially after completing the setup flow and granting all the required permissions, only to be redirected back to the same page. I’d like to help narrow down what might be causing the connection loop.

Could you please share a screenshot or screen recording of what you are seeing on your end after completing the setup process? You can upload it via https://snipboard.io or a similar service.

Also, please share your WooCommerce System Status Report so we can check for any configuration or connectivity issues.

You can find it via WooCommerce > Status > System Status, then click “Copy for support” and paste the report to https://pastebin.com, https://quickforget.com, or https://gist.github.com and share the link here.

Looking forward to your update.

Hi @yosimwojcik,

I understand you are looking to retrieve a direct downloadable URL for the uploaded file via the API, rather than only receiving the file metadata. Looking at the screenshot you shared, the file does appear in the order’s “Uploaded Files” section with a downloadable link available in the WooCommerce admin.

At the moment, the metadata you are receiving only contains the temporary upload information and does not automatically expose the public file URL. The actual downloadable link is typically stored separately by the plugin or customization handling the file uploads.

To help narrow this down, could you please let us know which plugin or custom implementation is being used to add the “Uploaded Files” section to the order? WooCommerce core does not include this section by default, so the method for retrieving the file URL depends on how the upload functionality was implemented.

If this is handled via custom code, please share the relevant snippet using: https://pastebin.com or https://gist.github.com

That will help us check whether the file URL is being stored as order meta or generated dynamically, and point you toward the correct API method for retrieving it.

Hi @kirstinv,

I understand why that caught your attention, and thanks for sharing the related thread as well.

In the topic you mentioned, the warnings were ultimately caused by custom code running on the site. The user later confirmed that after adding additional conditional checks into that custom code, the warnings stopped appearing.

At the moment, we cannot confirm that the same applies to your site without first checking whether there are any active customizations interacting with WooCommerce REST API endpoints or product category queries.

Could you please let us know if you currently have any custom code active on the site, for example:
– Custom snippets added via Code Snippets plugin
– Custom functions added in functions.php
– Theme customizations
– Custom WooCommerce REST API integrations
– Third party scripts or plugins that modify product/category queries

If possible, please share the relevant custom code snippets using https://pastebin.com, https://quickforget.com, or https://gist.github.com so we can review whether additional conditional checks may be needed there as well.

Hi @giorgi1992,

Thanks for sharing the screenshots and the log details. I can see that the accounts were reconnected, but Merchant Center is still not connecting correctly, so let’s go through the connection reset once more using the exact connection test page.

Could you please confirm if you opened this link directly on your site?
https://example.com/wp-admin/admin.php?page=connection-test-admin-page
Please replace example.com with your own domain, then run these steps in order:

1. Under Merchant Center, click MC Disconnect.
2. Under Google Account, click Disconnect Google Account.
3. Under Jetpack, click Disconnect Jetpack, if available.
4. Go to your Google account security settings here, https://myaccount.google.com/security, remove WooCommerce access, then reconnect Google for WooCommerce from the plugin setup.
5. Go back to the same connection test page and click Cleanup All Products.
6. After that, click Sync All Products.

From the log you shared, I can also see entries showing that several product IDs were not found in this WooCommerce store. That usually means Google for WooCommerce is trying to sync or update products that no longer exist, were deleted, or are no longer available in WooCommerce. Running Cleanup All Products first should help clear those stale product references before starting a fresh sync.

For the WP Rocket and Perfmatters part, the settings you changed look like the right area to check. For now, please keep optimization features like delayed JavaScript, unused CSS removal, preload, and any REST API disabling options turned off while testing the sync. You can re enable them later once we confirm the Google product sync works normally.

After running the cleanup and sync steps, please check WooCommerce > Status > Scheduled Actions again and let us know whether the new gla actions complete successfully or continue failing.

Hi @0108daniel,

Thanks for testing that and sharing the updated Rich Results result link, this helps narrow things down further.

At this point, Google is still only detecting Breadcrumb schema and not Product/Offer schema, which explains why prices are not appearing in Google search results.

Since the Yoast settings now look correctly configured, the next thing I would recommend is testing with another SEO plugin temporarily, such as Rank Math, to see whether Product schema begins appearing properly there.

This can help confirm whether the issue is specifically related to the current Yoast + theme/schema integration. I would recommend the following steps:

1. Temporarily switch from Yoast SEO to Rank Math on a staging site if possible
2. Retest the same product URL again in: https://search.google.com/test/rich-results
3. Check whether Product rich results begin appearing instead of only Breadcrumbs

Also, as mentioned earlier, The7 theme is known to include its own schema handling and overrides, so there is still a strong possibility the theme is suppressing or modifying the default WooCommerce Product schema output.

Because of that, I would also recommend a theme conflict test:

1. Temporarily switch to a default theme like Storefront or Twenty Twenty-Four
2. Retest the same product URL again
3. Check whether Product schema and Offer/price data begin appearing

If Product schema appears after switching either the SEO plugin or the theme, then we can confirm the issue is not coming from WooCommerce itself, but instead from the SEO/theme schema integration.

You can also continue checking the schema output directly here: https://validator.schema.org/#url=https%3A%2F%2Fmodel-kits.nl%2Fproduct%2Fgecko-models-116-princess-and-dog%2F

What we want to see there is: “@type”: “Product” and an “offers” section containing the price/currency data.

Please let us know what the Rich Results Test shows after trying those tests.

Hi @wattsyourwebsite,

Thanks for sharing the additional screenshot and details. From what I can see, the scheduled actions are not limited to Mailchimp only, there are also actions related to WooCommerce Payments, WooCommerce Webhooks, and admin import tasks staying in a past due state.

Since the actions complete successfully when run manually, that points more toward the queue processing being delayed rather than the actions themselves failing. This can sometimes happen when WP Cron is not triggered consistently by site traffic, or when there is server level caching or resource limitations slowing down the Action Scheduler queue.

Could you please try the following:

1. Go to WooCommerce → Status → Scheduled Actions
2. Click Pending or Past due
3. Use the “Run” option on a few batches and confirm whether the backlog number starts reducing over time
4. Check with your hosting provider if WP Cron is disabled at the server level, or if there are any server resource limitations, such as low PHP workers, CPU throttling, or aggressive caching
5. If you are comfortable doing so, you can also temporarily disable the Mailchimp for WooCommerce plugin and monitor whether new past due actions continue accumulating

I’d also recommend clearing any server/page cache after that and monitoring the queue for a few hours. You can learn more about Scheduled Actions here: WooCommerce Scheduled Actions Documentation

Let us know how things go after testing those steps.