Support » Plugin: PayPal for WooCommerce » Won’t return to staging site after PayPal

  • Resolved Jim

    (@jwmc)



    I’m testing Paypal Express Checkout through your plugin on a staging site, using Paypal sandbox, to try to resolve some issues we had on the live site. The first thing I’m running in to is that Paypal is sending me back to the live site.

    Is there something I have to set to get it to go back to staging?

    FYI, on PayPal sandbox merchant settings, I have no return chosen and no return url set, as I read on other threads that’s the way it should be with Express Checkout.

    The page I need help with: [log in to see the link]

Viewing 11 replies - 1 through 11 (of 11 total)
  • A bit more info: I checked the log, and it is indeed sending Paypal the URL of the live site:
    [RETURNURL] => https://www.cookandconnect.com/wc-api/WC_Gateway_PayPal_Express_AngellEYE/?pp_action=get_express_checkout_details

    Same with the Cancel URL.

    Plugin Contributor Oliver

    (@angelleyesupport)

    Hi @jwmc,

    Sometimes when you migrate from a live site to a testing site things can get left behind in the database depending on how you did the migration. It sounds like some of the data in the database is still pointing to your live site. Please double check those actual values in the database and make sure everything is using your staging URL as expected. Then this problem should go away.

    Let me know if you have any other questions.
    Thanks!

    Thank you Oliver, that’s what I was wondering.
    Jim

    Hmm, here is a reply from Siteground about this. Maybe they handle staging differently from some hosting companies, probably for good reason, but it makes it hard to test payments. The only thing I found to work was WooCommerce Paypal Checkout plugin, which doesn’t really go to the Paypal site but puts Paypal in a modal window, so I guess there is no return to do.

    From Siteground:
    Thank you for contacting our Help Desk.

    The URLs for your WordPress application are not changed on the staging copy, meaning that when a staging copy is created staging1.cookandconnect.com still has the domain cookandconnect.com setup within the database. The tool then uses multiple Apache modules to modify the header information along with rewriting all URLs on a server level to stagingN.domain.tld as an example(in your case staging1.cookandconnect.com).

    This is done so we can ensure the WordPress application does not have any URL or domain related issues once it is pushed to live. If a plugin or other website component requires the use of the WordPress base URL as it is set within the database and settings of the application it is likely that this could trigger errors and potentially redirects to the live site, as their functionality could inadvertently be bypassing the setup of the staging tool.

    With this in mind, I would advise you to consult this issue with the plugin developers to see if there is an alternative way to resolve this issue, as we highly discourage changing the URLs of the staging copy as this could lead to issues when the site is live.

    If there is no other alternative, we can try to change the base URLs of your WordPress application in the staging copy, however as I mentioned this is not advised.

    Plugin Author angelleye

    (@angelleye)

    There is still a return, but it sounds like you installed the other plugin directly on the staging site..?? This means it would correctly load everything with the staging URL instead of the live URL.

    They have confirmed that they are not updating the sites fully for staging, which is very unfortunate. I’ve heard lots of good things about SiteGround, but this one would be a negative for sure. They are saying that it could cause problems when that site goes live, but that’s really not the proper way to be using staging sites. When migrating from one domain to another of any kind there are procedures to ensure everything moves every as expected, and you won’t have any problems. This allows you to fully run things on any domain you want.

    Also, based on what you’ve done now, you’ve got this other EC plugin installed directly on the staging site, so it’s properly using that domain URL, but then it sounds like that wouldn’t properly update when you move that from staging to live. So their theory about not causing problems really only works if you’ve done all of the initial configuration on the live server, and you don’t do anything extra when on staging, which really defeats the purpose.

    There are ways to do migration like this manually to avoid the problems you’re having with their automated tools, or you could look at something like UpdraftPlus Premium, which includes a migration tool that will handle it all for you. That’s a paid plugin, but if you’re going be doing this a lot it would be well worth it.

    Jim

    (@jwmc)

    Thank you for the extensive reply. I would really love to be able to test this in my staging environment. Is there someplace in the plugin where I could temporarily hard-code the return domain for staging? I know it’s not the ideal solution but at this point I need a simple fix.

    ***********

    By the way, I’ve noticed lately, whenever I’m on the settings page for Paypal for Woocommerce – Express Checkout, I see near the top of the settings window a portion of a php warning. It also shows up in the php_errorlog whenever I’m in that settings page:

    [19-Jul-2018 12:39:03 UTC] PHP Warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in /home/cookand3/staging/3/wp-includes/wp-db.php on line 1102

    The plugin doesn’t seem to call this directly, but maybe indirectly?

    Plugin Author angelleye

    (@angelleye)

    @jwmc, I’m sorry for the delay getting back to you.

    The best way to fix this problem would be to update the database so that it uses the staging site URL everywhere it should instead of the live URL. Another option would be to set the site and home URL values in your wp-config.php file. Here’s a guide for how you could do that: https://codex.wordpress.org/Changing_The_Site_URL

    I would give that a try from the staging site.

    Thanks, that was a good suggestion and I had high hopes, but alas . . .

    If I define both WP_HOME and WP_SITEURL, or only WP_HOME, to the URL of the staging site, the site breaks, some kind of redirection error.

    So I defined only WP_SITEURL. The site worked in general, but the same problem with payments as before.

    I appreciate you trying to help!

    Plugin Contributor Oliver

    (@angelleyesupport)

    After setting the values in the wp-config file, did you saved permalink in wp-admin > settings > permalinks? Please do save every time you do any such change to the value in the database gets updated. You can also check in you access for some statics rules for such redirection, may be..

    Thank you for the suggestion. I tried again defining both variables or only WP_SITEURL, this time resetting permalinks after. Unfortunately same results as before.

    I will work with hosting support and see if they have a solution.

    • This reply was modified 1 month, 3 weeks ago by  Jim.
    Plugin Author angelleye

    (@angelleye)

    Okay, well as mentioned, you really need to get that database updated to run on the proper domain that the staging site is running from. If the DB has different values set for those things than the site itself you’re going to have problems like this with lots of different plugins/themes/etc.

    Keep in mind our plugin allows you to set sandbox mode at the product level. You could configure your live site with both live and sandbox credentials, but leave the global setting to live. Then setup a “test widget” product, and at the product level you can enable the sandbox for that product. Then when you checkout with that item in the cart the plugin will know it should use the sandbox so that you can complete your test all the way through.

    This way you’ll be running from the proper domain, you can leave the site live except for the one test product, and you can run your tests accordingly.

Viewing 11 replies - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.