• Resolved sachristan

    (@sachristan)


    This doesn’t seem to work at all, we still get daily people with multiple orders after they have received a SyntaxError: Unexpected Token.

    Posted solution below:

    If you see this during checkout for example, it means that a plugin or theme is throwing a notice during the ajax post and breaking the response.

    To find out which plugin is doing this, view your sever error logs and look for notices. Your host may be able to help you look for this log if you cannot locate it.

    To prevent plugins and themes from outputting notices entirely, ensure debug mode is off in your wp-config file:

    define(‘WP_DEBUG’, false);
    error_reporting(0);
    @ini_set(‘display_errors’, 0);

    Can someone point us in the right direction we have customers who are sending in duplicate orders after their initial order has been accepted.

    Thanks

    https://www.ads-software.com/plugins/woocommerce/

Viewing 15 replies - 31 through 45 (of 50 total)
  • @mike Jolley The only change here is enforcing valid JSON rather than allowing any response. Any output from a plugin, be that a notice, warning, or echoing of HTML, will break this valid JSON response.

    In the call for beta testers, and prompts for developers to test code, no reports came in about the above, no one asked that it change, no Woo gateways broke.

    I have had reports of this error on multiple sites and 4 different gateways (PayPal, CardConnect, Authorize.net, Stripe) and those are only *my* clients, not to mention all of the threads about this. There are lots and lots.

    Disabling error displays on the screen is not exactly a “fix” either. What’s more, this “solution” has not fixed the issue on 4 out of 6 sites. This forced me to contact the gateway developers to update their code. That takes time and in the interim, my client(s) cannot sell their products. And try that with PayPal (Spoiler alert: you can’t).

    To me, if some of the largest gateways return HTML or something else, then WC should anticipate this and not just break and say “No beta testers mentioned this.” That’s a complete cop-out. A simple conditional could solve this and still support the gateways that have not upgraded yet.

    Part of having a successful platform, be it WordPress or WooCommerce is backwards compatibility. You can’t just eliminate support for legacy code (however bad it may be) and then blame your users and developers. This is horrible practice and bad business. You have to take some of the blame for this and you should fix it, not expect everyone else to (even if they *should*).

    What’s more it makes me think twice about recommending WooCommerce for e-commerce with WordPress.

    Plugin Contributor Mike Jolley (a11n)

    (@mikejolley)

    @joshuaiz no-one can anticipate every possible ‘hack’ or use of 3rd party code. Fact is, in all gateway sample code and documentation we’ve never said “hey, you can return HTML here instead of an array” – thats a choice the gateway dev made to change the way WC checkout works. A quick fix if you will.

    > This forced me to contact the gateway developers to update their code.

    Ideally it should have been tested prior to updating. If its a product you’ve bought, the devs should be testing as soon as a beta is announced. The beta process is open. If issues do not come up in beta testing, it cannot be catered for or worked around prior to release.

    @mike Jolley Not sure what you are referring to by “hack” or “3rd party code”.

    Yes I agree it should have been tested by the gateway developers before the update. But this is not dealing with the reality we are facing now.

    The fact that this happened with 6 of my clients on 4 different gateways points to something you should have anticipated. I don’t believe that in proper real-world testing that this issue never came up if it is happening to hundreds (if not thousands) of people now.

    WooCommerce cannot work without gateways and to get this syntax error with gateways that you support out of the box cannot entirely be blamed on 3rd party code.

    While I fully understand that you cannot test for every situation or setup, the sheer quantity of the threads inquiring about this issue should motivate you guys to do *something* rather than throw your hands up, say “we warned you” and blame everyone else. That is not helping anyone.

    Furthermore, as a WP developer, I am having to tell my clients to wait for a fix while they cannot sell their products. It makes me and other developers look bad while we can only sit back and hope a fix comes soon.

    @mike Jolley. How do you account for this happening even when no gateway is being used as in my case? I’ve disabled everything else and am trying to complete it only as pay on pick-up. This definitely isn’t the gateway then. Who do I talk to then to try to find a solution?

    Plugin Contributor Mike Jolley (a11n)

    (@mikejolley)

    @tkieneker regardless of whether payment is actually taken, unless its a ‘free’ order, a gateway is always involved. Do a test with BACS or CHEQUE – those are in core.

    @joshuaiz

    WooCommerce cannot work without gateways and to get this syntax error with gateways that you support out of the box cannot entirely be blamed on 3rd party code.

    Define ‘we support out of the box’? Out of the box we support those built into core – paypal standard, simplify (which have no issues), and the official gateways Woo maintain. None of these should be affected. Anything by external devs is 3rd party.

    The fact that this happened with 6 of my clients on 4 different gateways points to something you should have anticipated. I don’t believe that in proper real-world testing that this issue never came up if it is happening to hundreds (if not thousands) of people now.

    I mentioned before, our own gateways and gateways by 3rd parties who sell THROUGH us were tested. It wouldn’t be feasible to test other gateways not under our control, or behind a pay wall. Thats where the dev-responsibility for testing lies.

    Next time a beta is announced (probably in November) on https://develop.woothemes.com/woocommerce/ feel free to get involved – we’re actively trying to increase the # of beta testers to prevent the likelihood of these issues in the future.

    For now if you’re having trouble getting 2.4 compatibility updates from developers, perhaps its time to switch gateway plugin to one thats more actively supported.

    @mike Jolley For now if you’re having trouble getting 2.4 compatibility updates from developers, perhaps its time to switch gateway plugin to one thats more actively supported.

    I wish I could…that’s just not an option with some clients.

    ****edited after reading previous response by Mike Jolley****

    I was only using paypal standard – no other 3rd party – the one built into woocommerce. And I am using Cheque now and still getting the error.

    Thread Starter sachristan

    (@sachristan)

    Truer words have never been spoken!

    @joshuaiz: While I fully understand that you cannot test for every situation or setup, the sheer quantity of the threads inquiring about this issue should motivate you guys to do *something* rather than throw your hands up, say “we warned you” and blame everyone else. That is not helping anyone.

    Wake up woothemes, this is obviously a chronic issue. Ignoring voices doesn’t accomplish anything but hurt the reputation of store owners and the integrity of your plugin.

    Plugin Contributor Mike Jolley (a11n)

    (@mikejolley)

    @tkieneker If you enable logging as mentioned in the sticky, this will help you identify which plugin is throwing an error. I’ve seen instances where misconfigured caching plugins also change the JSON.

    @joshuaiz who is the author of these gateways? If you let me know where they are from, we can reach out and ensure they know where to find beta releases and announcements.

    @rob only so much can be done if a plugin ignores the API or best practices. Adding hacks to core itself to support (encourage) such practice is more damaging long term. That said, we’re assuming it is a gateway. Any notice or output from code will throw the above error. WP_DEBUG_LOG will help narrow down cause.

    @mike Jolley CardConnect – they are already working on a fix but another client is using PayPal Standard and still getting the syntax error.

    The DEBUG_DISPLAY setting is not working in either of those cases.

    Plugin Contributor Mike Jolley (a11n)

    (@mikejolley)

    joshuaiz Look at WP_DEBUG_LOG – https://codex.www.ads-software.com/Debugging_in_WordPress this writes to a file.

    OR view your console. in chrome View > Developer > Network > XHR, click on the request, and view the response. Error will be there.

    Thanks Mike – I have been using those tools to isolate the error(s).

    I have that set for the CardConnect client – they cannot change gateways but we are working closely with the gateway plugin developer.

    For the PayPal Standard I could not repeat the error – it was intermittent (my favorite :). But there was nothing in the debug.log or in the dev tools console/XHR response at least on my end.

    Jo_djeflabocker

    (@jo_djeflabocker)

    Just wanted to say that the 3rd party plugin “configure smtp” was the faulty piece for me. Hope that can help some of you guys that dont find the solution elsewhere.

    raviraj

    (@raviraj)

    Is there any proper solution yet for this issue? I was creating a payment gateway for client, and it seems to be giving same error as above.I have checked console and everything seems to be fine there. It was working fine for me 10 days back, before last upgrade of woocommerce.

    Thread Starter sachristan

    (@sachristan)

    I believe woothemes have basically absolved themselves from this fiasco from what I gather from @mike responses.

Viewing 15 replies - 31 through 45 (of 50 total)
  • The topic ‘Common Issue – SyntaxError: Unexpected Token’ is closed to new replies.