This was working fine before the WooCommerce update. It appears that __doPostBack is no longer defined or available in the updated environment.
Has anyone else encountered this issue? What is the recommended alternative or fix for triggering this kind of postback behavior in the current WooCommerce version?
Any guidance is appreciated. Thanks!
This topic was modified 11 months, 3 weeks ago by codemsivakumar.
I understand how frustrating it can be when a WooCommerce update unexpectedly affects custom code that was previously working. The __doPostBack function is a JavaScript method typically associated with ASP.NET, and it’s not something WooCommerce or WordPress natively includes or relies on.
It’s likely that the WooCommerce 9.9.4 update modified how scripts are loaded or optimized on your site, and as a result, the environment that previously allowed this function to run is no longer in place. Since this method isn’t part of the WordPress or WooCommerce core, it’s best to replace it with a more WordPress-compatible approach.
If your goal is to trigger a server-side action when clicking the link, consider using:
A standard form with a hidden field and submit button
An AJAX request using jQuery.post or fetch() to handle it dynamically
Or a custom PHP handler using admin-post.php
Let me know more about what the button is meant to do, and I can help suggest a WordPress-compatible solution.
It seems we haven’t heard back from you for a while, so I’ll go ahead and mark this thread as resolved. Feel free to reach out whenever you’re ready to continue.
Here is the implementation to show a confirmation popup which will be displayed earlier on doPost <a onclick=”AddEmptyconfirmationPopup();” id=”lnkbtnEmptyCart” class=”button–empty” href=”javascript:__doPostBack(‘$lnkbtnEmptyCart’,”)”>Empty cart</a>
Post Woo update, it breaks this functionality and throws the mentioned error.
Thank you for the update and clarification — I really appreciate you taking the time to explain. I’d like us to take a step back and re-evaluate the issue together.
I’ve reviewed your original message and the error you shared, and based on what I’m seeing, this doesn’t appear to be something caused by WooCommerce or WordPress itself.
Just to clarify, the __doPostBack() function is specific to Microsoft’s ASP.NET Web Forms. It’s typically used in .NET applications built with tools like Visual Studio to simulate form submissions to the server.
On the other hand, WordPress is built entirely on PHP and doesn’t use .NET technologies. Its frontend relies on HTML, JavaScript, jQuery, the REST API, and AJAX, but it does not include or generate the __doPostBack() function in any part of the core software or standard WooCommerce plugins.
Given that, it’s likely this code was introduced by:
A custom script,
A third-party plugin,
A widget copied from a .NET-based platform, or possibly through a migration from a .NET-based system that carried over some legacy code.
To confirm, I did a search through the WooCommerce code repository (including older versions) and found no reference to __doPostBack, which supports this conclusion.
To move forward, I recommend checking with your hosting provider or developer to search your site’s primary files (themes, plugins, or custom scripts) for references to __doPostBack. This should help identify the source.
Thank you for your reply. I agree that this doesn’t seem to be caused directly by WooCommerce or WordPress itself. However, I noticed that after upgrading WooCommerce to version 9.9.4, the __doPostBack() function throws an error. When I revert back to version 9.8.5, the same code works as expected and shows the popup.
Could something in the 9.9.4 release be affecting this behavior?
I understand how puzzling it must be to see your custom code stop working right after a WooCommerce update, especially when it previously functioned as expected. While we can’t pinpoint a specific change in WooCommerce 9.9.4 that would affect the __doPostBack() method directly, it’s possible that changes to how scripts are loaded or handled in the frontend may have disrupted how certain non-native JavaScript functions behave.
Since __doPostBack() isn’t a function included in WooCommerce or WordPress, the most sustainable solution would be to rework your code using WordPress-compatible techniques. This can include using standard form submissions, AJAX with jQuery.post() or fetch(), or PHP endpoints like admin-post.php for triggering server-side actions. These approaches will remain stable across WooCommerce updates and improve your site’s compatibility.
Also, keep in mind that WooCommerce updates sometimes expose compatibility issues in custom or third-party code that previously went unnoticed.
Let me know what that button is meant to trigger, and we’ll see if there is any option we can suggest.
As for the button — it’s currently used to prompt the user with a confirmation popup to clear the cart. When the user clicks “Yes,” the popup closes and an AJAX request is triggered to delete the cart data.
While __doPostBack() isn’t part of WooCommerce or WordPress, it’s possible that a plugin or theme component you’re using was registering that function indirectly, and something in WooCommerce 9.9.4—such as updated script handling, deferred JavaScript execution, or stricter sanitization—may have changed the timing or conditions under which that external script loads.
So while WooCommerce doesn’t use or remove __doPostBack() directly, the update may have impacted how custom scripts are enqueued or rendered on the frontend, especially if the script that defines __doPostBack() was injected inline or depended on specific hooks or markup that WooCommerce adjusted in 9.9.4.
To move forward, we recommend checking:
Whether the script defining __doPostBack() is still present in the page source (view source in your browser) after updating to 9.9.4.
Whether that script depends on a specific WooCommerce hook or template file that may have changed in 9.9.4.
If the script is enqueued through a theme or plugin, ensure it’s still properly hooked using wp_enqueue_script() and that it’s not being blocked or deferred unexpectedly.
In WooCommerce 9.8.5, the cart-custom.js?ver=6.8.1 script file is present on the page.
However, after updating to WooCommerce 9.9.4, this script is missing from the page source (viewed via browser). It’s no longer loading in the <head> or anywhere else in the markup.
public function __construct() { if ( is_cart() ) { wp_enqueue_script( 'cart-order-cart',get_theme_file_uri() . '/assets/js/cart-custom.js'); }
This reply was modified 11 months, 1 week ago by codemsivakumar.
I had a look at WooCommerce 9.8.5, and I couldn’t find any file named cart-custom.js included by default. Based on the name, it seems likely that this script is being added by your theme or a custom plugin, rather than by WooCommerce itself.
Could you double-check whether this file might be registered or enqueued by another part of your setup, perhaps a child theme, plugin, or custom function?
Thanks for confirming that the script is being enqueued from your child theme. That helps clarify things.
Since this issue stems from a custom script (cart-custom.js) not loading as expected after the WooCommerce 9.9.4 update, it looks like a compatibility conflict between your custom code and changes introduced in that version. As __doPostBack() is not part of WordPress or WooCommerce, and the script defining it is custom, we recommend reviewing the logic behind how and when it gets enqueued.
You might want to revisit the condition in your child theme’s code:
WooCommerce updates may have changed how templates or page checks behave, which could prevent the script from being enqueued as before. It would be best to test alternate conditions (like is_checkout() or checking against specific page IDs) or explore using wp_enqueue_scripts with proper hooks and priority.
