LovingBro (woo-hc)

Hi @zenbaei,

Thanks for testing that out and sharing your findings, I can see how the different order statuses and stock behaviour are making this flow confusing, especially when trying to balance stock reservation and availability.

What you’re observing is actually tied to how WooCommerce handles stock per order status:

• Pending payment orders reserve stock for a limited time (based on the “Hold stock” setting)
• On hold orders immediately reduce stock and keep it unavailable
• Manually switching statuses does not always re-trigger stock reservation logic the same way as during checkout

So when you switch an order to “Pending” manually, WooCommerce does not re-run the stock reservation process, which is why stock validation is not firing as expected afterward.

To help move forward, here are a few suggestions:

1. Check the “Hold stock” setting
   Go to WooCommerce > Settings > Products > Inventory and confirm the hold stock duration is set
   https://woocommerce.com/document/configuring-woocommerce-settings/products/#inventory
   This controls how long stock is reserved for pending orders
2. Avoid manually changing order status for testing stock behaviour
   Manual changes bypass parts of the checkout validation logic, so results may not reflect real checkout behaviour
3. Focus on the original issue (stock validation bypass)
   Since you’ve confirmed this still happens, even without the card gateway, this points more strongly to:
   • A customization or plugin altering checkout flow
   • Or a hook that creates the order before validation completes
4. Next step, isolate further
   If possible, try:
   • Default theme (Storefront)
   • Only WooCommerce active
   • Test with simple product and limited stock

If the issue still occurs in that clean setup, that would be very important to confirm.

If you can, please share your System Status Report using https://pastebin.com or https://gist.github.com so we can review your setup more closely.

Looking forward to your update, happy to keep digging into this with you.

Hi @sveilore,

I can see how concerning that must have been, especially with the site going down unexpectedly after things were working fine. Glad to hear your hosting provider was able to get things back up quickly.

From what you’ve described, this is unlikely to be a core WordPress issue. The .htaccess file is typically modified by plugins, themes, or manual changes, and if incorrect or incompatible rules are written to it, that can indeed take the site down.

In your case, it’s possible that a plugin update, such as Elementor or another plugin interacting with server rules, may have triggered a rewrite or added directives that your server didn’t handle well. While WooCommerce itself doesn’t usually modify .htaccess in a way that would cause this, other plugins or caching and security tools often do.

A few things you can do moving forward:

• Check with your host if they can share what specific rule caused the issue
• Review recent plugin updates around the time of the crash
• Keep regular backups so you can quickly restore if this happens again
• If you have staging available, test updates there first before applying them to your live site

You can also learn more about how WordPress handles .htaccess here:
https://wordpress.org/documentation/article/htaccess/

If this happens again and you’re able to capture the contents of the .htaccess file at the time, feel free to share it via https://pastebin.com or https://gist.github.com and we can take a closer look with you.

Let me know if you’d like help reviewing anything further 🙂

Hi @djdannyc,

Thanks for taking the time to share such a detailed report, I can see you’ve traced this quite thoroughly and identified where the notice is being triggered, which is really helpful.

You’re right that this notice is tied to the changes introduced in newer WordPress versions where translations are expected to load on or after the init hook. Based on your findings, it does look like the translation call is happening earlier than expected within WooCommerce core.

At this point, this appears to be something that would need to be handled at the core level rather than something configurable on your site. I’ll raise this internally with the development team for a closer look so it can be properly reviewed and addressed.

In the meantime, just to provide some reassurance, this is a notice and should not affect site functionality. If you’d prefer not to see it in your logs, you can temporarily suppress notices by adjusting your debug settings, for example: https://wordpress.org/documentation/article/debugging-in-wordpress/

If you notice any functional impact tied to this or anything else alongside it, feel free to share more details and we can dig deeper. Appreciate you flagging this 👍

Hi @petnwooo,

It is great to hear back from you and I am really glad you were able to identify the cause and get things working correctly, especially with both the variation data and special characters now importing as expected.

For future reference, it would be helpful to always share follow-up updates or feedback as a reply under the original thread you started. This keeps everything in one place and makes it easier for others facing a similar issue to follow the full context and solution.

Here is the original thread for reference: https://wordpress.org/support/topic/variation-data-wiped-during-csv-import-failed-with-full-and-partial-mapping/

If anything else comes up, feel free to reach out anytime 🙂

Hi @wpisco, thanks for taking the time to dig into this so thoroughly, the level of detail you’ve shared really helps paint a clear picture of what’s happening here.

From what you’ve described, this does look very much like an issue specific to how the scheduled batch runs via Action Scheduler in WooCommerce 10.7.0, rather than with the underlying data stores or the orders themselves. Your observation about \DivisionByZeroError not being caught due to the catch (\Exception $e) block is especially helpful and likely explains why the failure is not being properly logged.

Given that manual imports and the historical import tool both work as expected, and the failure is isolated to the async batch process, this points strongly to a regression in the batch processing logic in this version.

At this stage, the best next steps would be:

1. Share a System Status Report so we can take a closer look at your setup. You can paste it via https://pastebin.com or https://gist.github.com
   You can get it from WooCommerce > Status > Get system report.
2. If possible, enable logging and check for any related entries under WooCommerce > Status > Logs, particularly around the time the scheduled action runs.
3. As a temporary workaround, you can continue using the manual “Import historical data” tool if needed, since that path is working correctly.

Please share the SSR when you can, and we will continue from there.

Hi @epidemics01,

Thanks for the follow up, I can see you’re looking for a free option to add extra fields like name and phone number to your registration form, that’s a very reasonable approach.

Yes, there are free plugins that can help with this. A good option you can explore is this plugin: https://wordpress.org/plugins/registration-form-for-woocommerce/

It allows you to extend the WooCommerce registration form with additional fields such as first name, last name, phone number, and more, without needing custom code.

For your conditional logic requirement, like showing company fields only when “Company” is selected, you may still need a more advanced form builder or a plugin that specifically supports conditional fields, as most free tools have limited support for that.

Regarding email verification and preventing auto login after registration, that will still require a separate plugin focused on user verification and login control.

Overall, combining a free registration field plugin like the one above with a verification plugin is usually the most practical and stable setup without additional cost.

Let me know if you’d like help narrowing this down further based on your exact setup, happy to guide you.

Hi @epidemics01,

It looks like you’re aiming to build a more advanced and controlled registration flow than what WooCommerce provides out of the box, including extra fields, conditional logic, and email-based account activation, I can see how important that is for your setup.

Out of the box, WooCommerce keeps registration intentionally simple, so what you’re describing will require extending it with additional functionality. The most stable and recommended approach here is to use a dedicated plugin rather than custom coding everything from scratch.

For adding custom fields like first name, last name, phone number, and confirming passwords, you can use plugins that extend the registration form. For example: https://woocommerce.com/document/custom-user-registration-fields/.

For conditional logic, such as showing company fields only when “Company” is selected, you will need a plugin that supports conditional fields. Plugins like “WooCommerce Checkout Field Editor” or form builders such as “Fluent Forms” or “Gravity Forms” with WooCommerce integration are commonly used for this type of setup.

Regarding the registration flow changes:
• To prevent automatic login after registration, you can disable this via custom code or plugins that control login behavior
• For email verification and account activation, you will need a plugin specifically designed for user verification. Plugins like “User Registration” or “WooCommerce Email Verification” can handle sending activation links and only enabling accounts after confirmation

Since you’re also using the Woodmart theme, it’s worth noting that some themes override WooCommerce templates. If you run into issues, testing with a default theme like Storefront can help confirm whether the theme is affecting the behavior.

If you prefer a fully integrated approach, using a form builder with WooCommerce support is often the most flexible and future-proof solution for combining custom fields, conditional logic, and controlled registration flows in one place.

Hi @carinep,

Thanks for the detailed explanation here, I can see how confusing it is when the formatting is correctly saved in the backend but stripped out on the frontend, especially when you are not using any extra plugins.

From what you have described and observed, you are on the right track. With block themes like Twenty Twenty-Four, the product short description is sometimes rendered via the Post Excerpt block (wp-block-post-excerpt) instead of the classic WooCommerce short description output. That block intentionally strips most HTML for consistency and security, which is why your <ul>, <li>, and <br> tags are not preserved.

This is not something CSS can resolve, since the HTML itself is being removed before it reaches the browser.

A couple of ways you can approach this:

1. Replace the Excerpt block with the proper WooCommerce block
   Go to Appearance → Editor → Templates → Single Product, and check if the template is using a pattern or template part where the Excerpt block is embedded. In some cases it is nested inside a Group or Pattern, so it may not be immediately visible.
   You would want to replace it with the Product Short Description block (if available in your editor).
2. Switch to classic rendering (PHP template override)
   If the block editor route does not expose the correct block, you can fall back to WooCommerce’s native output which preserves formatting. This usually involves overriding the template or ensuring the_excerpt is not used in place of woocommerce_template_single_excerpt.
3. Temporary workaround using filters
   Since the content is being passed through excerpt-related filters, you can try forcing allowed HTML more explicitly, for example:

remove_all_filters( 'woocommerce_short_description' );
add_filter( 'woocommerce_short_description', 'wpautop' );
add_filter( 'woocommerce_short_description', 'wp_kses_post' );

That said, if the Excerpt block is in control, this may still be overridden at the block level.

You can read more about how WooCommerce templates and product content are structured here: https://woocommerce.com/document/template-structure/

If you can share a quick screenshot of your Single Product template structure via https://snipboard.io, I can help pinpoint exactly where that Excerpt block is coming from and guide you on replacing it cleanly.

Looking forward to your update, happy to keep digging into this with you.