Using WordPress HTTPS Messes up Cart
December 6, 2013 at 1:28 pm #146544
I am attempting to set up SSL for the admin portion of my site. I’ve got an SSL certificate installed and working fine. Now I want to force SSL on the admin, and possibly on the checkout page.
I thus downloaded the WordPress HTTPS plugin and set it to force admin SSL. However I notice that now if I add plugins to the cart on my site, then go to the cart /checkout page, the cart is empty. No matter which plugins or how many I add, the cart on the checkout page is always empty. Disabled WordPress HTTPS and everything is back to normal. Any ideas what might be going wrong here?December 6, 2013 at 6:16 pm #146665
Hey wpmayor! I’ve got a few ideas! Let me do some digging and I’ll get back top you!December 7, 2013 at 9:54 am #146979
I’ve got my web host SiteGround to look into it, here’s what they said:
I carefully investigated it and it seems that the initial reason the shopping cart was not working properly, was due to the cookies setup. WordPress, by default, would setup cookies for httponly, unless otherwise told. This means that, when your visitor signup with a non-SSL connection, a cookie is setup with httponly flag, which is not available to the script when the connection is changed to SSL. I’ve fixed this by removing the httponly flag, but unfortunately, there is a different problem now — the edd function, upon adding a product, returns a value of -1.
The request is made via the admin-ajax.php file with a call to edd_add_to_cart() function, it does not however return a correct answer. I’m afraid that I’m unaware of the inner workings of this particular plugin however and would recommend you to contact its developers for further information why this might be happening.December 9, 2013 at 5:27 pm #147820
So my initial ideas didn’t turn out to be relevant… I’ll keep looking though!December 9, 2013 at 10:54 pm #147945
Here’s some further info from the host:
The cart uses AJAX call to /wp-admin/admin-ajax.php which eventually is considered as part of the admin interface and the connection is changed to SSL. This is why I think the problem is due to SSL and non-SSL cookies being lost.December 11, 2013 at 12:53 pm #148706
Did you test in other installations? The EDD site itself uses SSL throughout the site but this isn’t best practice since SSL slows done pages a bit.December 12, 2013 at 10:27 am #149181
I’ve tested in a few setups… both development and live… The live one is setup the same way EDD is with a site-wide SSL, so it’s possible that’s eliminating the error.December 12, 2013 at 10:39 am #149189
The WordPress HTTPS plugin tends to do this. Sometimes it works, sometimes it doesn’t.
I’d recommend you ask SiteGround to force the checkout and admin to SSL for you. They can setup an apache rule that forces it (that’s how I do it on pippinsplugins.com).December 12, 2013 at 11:09 am #149249
Thanks will see if it works when we set it up manually.December 12, 2013 at 1:06 pm #149296
Here’s the response I got:
The other way to do this is via a http to httpS redorect but in order to do this, your WordPress will have to be reconfigured with the httpS domain. Otherwise, there will be a redirect loop.
Before I do it, can you please contact the developer again and ask them to provide more details on what Apache rule they used to sort this issue out at pippinsplugins.com . We can then see if we can apply the exact same solution on your server with us.December 12, 2013 at 1:56 pm #149331
I had WP Engine do it for me so I can’t tell you the exact rule, but I’ve done it on servers myself before and it was simply a permanent redirect in the vhosts file. For example, permanently redirect /checkout to https://yoursite.com/checkoutDecember 12, 2013 at 2:01 pm #149333
I can confirm this, both on a live server as well as on my home computer test system (Windows 7 Pro running Xampp).
There is another thread about this, but it never got solved. Seems the only solution is to make your entire site secure and hope it doesn’t slow down too much. Change your site URL in wordpress to use https so that all links generated by menus and such will be secure links, and update any manual links you used in any posts. Then, the only little catch was if somebody goes to your homepage with a non-secure URL, then that page will not be secure and if you have any add-to-cart buttons on that page, you’ll get the same empty cart message when going from non-secure page to secure cart page. But, if you use a static home page, then you can use the WordPress HTTPS plugin to force your home page to also be secure.
That has been the only workable solution I have found, because on both sites that I’m setting up, as well as my Win7 home development machine, I can make the error happen every time if you add to cart on a non-secure page and then switch to the cart on a secure page.
The only other solution so far is to disable the AJAX add-to-cart functionality so that the page refreshes when you add something to the cart… then it doesn’t seem to matter if the product pages are non-secure and the cart is secure.
I’m not sure why this is happening only with EDD. I use WooCommerce on a couple of other sites, in conjunction with WordPress HTTPS to make only the checkout page secure, and everything works fine even with their AJAX add-to-cart actions enabled.December 12, 2013 at 2:12 pm #149341
Making your entire site SSL only is definite NOT the only solution. I have it set up on https://pippinsplugins.com where only the checkout is SSL and it works perfectly. I also set it up on http://cgcookie.com with only the checkout as SSL.
I’m not saying there isn’t a bug (I’m pretty sure there is one somewhere though it only affects some sites), but it definitely doesn’t affect everyone.December 12, 2013 at 3:16 pm #149400
Sorry, didn’t mean to imply that it was affecting everyone on every site, but I can certainly reproduce it every time on 2 of my sites running on a Linux server, as well as my Windows 7 machine using a Xampp server, and I’ve had the same problems here at the Easy Digital Downloads store on more than one occasion before you changed this store to be all secure.
I would love to see a solution that doesn’t involve the work-around I’ve done to make my sites work. And, since we know it currently doesn’t work on my live server as well as my Windows 7 machines, I’m more than happy to do some beta testing for you while trying to track down the issue.
I am nowhere near your skill level at programming, but I do OK with PHP, MySQL, and WordPress, so let me know if there is anything I can do to help test any possible solutions out. I’m happy to test things out on my live server as well (on a closed/private site). However, I’m not comfortable with diving into shell level commands, and playing around with things like VHosts… a bit above my knowledge level, although I could probably get some help from the company that hosts my dedicated server.
Your plugin is great for the download stores I’m trying to get going, as it’s nowhere near as big and bloated as WooCommerce, so I’d love to help make EDD even better if possible.December 12, 2013 at 5:13 pm #149431
Here;s what they told me from hosting:
WordPress is an application that automatically redirects to the domains that it is configured to work with. This is why, as I tried to explain again, we can not create a permanent redirection to httpS for only one page URL of your site. At least I, together with my colleagues, could not think of a way to do it without causing a redirect loop with the inbult domain management functions of WordPress.
Contact a professional WordPress developer. Have them create the necessary rewrite rules and we will then be glad to assist you with implementing them.December 13, 2013 at 11:45 am #149769
That’s certainly not true. I’ve set up the rules myself and they work perfectly.
Here’s the rule I used in the vhost file:
Redirect permanent /membership/registration https://cgcookie.com/membership/registration Redirect permanent /checkout https://cgcookie.com/checkout Redirect permanent /shop https://cgcookie.com/shop
This is done while leaving the standard WP options for home and site URL as httpDecember 13, 2013 at 3:36 pm #149892
Here’s what they told me:
Please try to add the redirects on top of your .htaccess file before the application’s default rewrite rules otherwise they might be overwritten.
I’d like to have some simple instructions for setting this up, I’m sure there are more people who have or will encounter this issue.December 16, 2013 at 9:37 am #150759December 18, 2013 at 11:08 am #152040
On cgcookie.com once you go to checkout the connection changes to SSL and when you go back to other pages the connection remains SSL and doesn’t revert back to SSL. Is it possible to revert back and keep SSL isolated to the checkout page?December 18, 2013 at 3:12 pm #152144
That’s simply because we aren’t forcing it to one or the other on the product pages, so it’s simply inheriting the previous state.December 18, 2013 at 7:39 pm #152227
Thanks, makes sense. Here’s the latest reply from the server guys. I asked them about enabling SSL for the checkout page as well as the wp-admin part of the site, and whether it was possible to switch SSL off when navigating from the checkout page back to another page of the site:
I have tried to setup a redirect from checkout pages to a non-secure HTTP connection when visiting back other pages of the site, and I also tried to create a redirect to a secure HTTPS connection for the administrative pages of the website, I am sorry to say however that my attempts were to no avail.
Redirecting access to the Dashboard of the site was tricky due to the fact that a simply 301 redirect rule for requests made to /wp-admin/ did not do the trick, as the login script (wp-login.php) also had to be accessed securely, and the URL to the login script requires a redirect back to /wp-admin/ to be passed in the URL as a query string.
Matching this query string made the redirect more complex, however in the end the biggest obstacle was the what Val explained earlier in this ticket – the fact that SSL and non-SSL cookies are being lost. Once secure access to the administrative area of the site was enabled through any means, adding products to the cart and proceeding to checkout lead to an empty cart due to these reasons.
I also tried to redirect requests from the checkout pages to other portions of the site back to a non-secure HTTP connection, however without success I am afraid. What made this difficult was creating a proper rewrite condition that would redirect HTTPS checkout pages back to a non-secure HTTP connection without actually damaging the original redirect for a secure checkout access.
I would recommend that you check out with the Easy Digital Downloads team, as the issue with disappearing products from the cart once admin SSL access is enabled appears to be due to the inner workings of their plugin, as Val pointed out before. Thus I trust that they should be able to provide further help.
Regarding the redirect for checkout pages back to a non-secure HTTP connection, I personally do not believe that this would be possible without damaging the performance of the site or the original redirect for secure checkout pages. Or at least I was unable to find a way to achieve this during my investigation and research of this situation.December 19, 2013 at 9:26 am #152541
At the end of the day I ended up with a protected checkout page working ok, but as soon as I set force_ssl_admin the cart breaks again. Pretty frustrated about how much effort all this takes.December 19, 2013 at 9:39 am #152552
With force_ssl_admin enabled, does it work if you disable ajax in Downloads > Settings > Misc?December 19, 2013 at 10:21 am #152579
YesDecember 19, 2013 at 3:57 pm #152724
That gives me a better idea of what it is.
For the time being, are you fine without ajax?December 19, 2013 at 4:37 pm #152740
Yes that will do the job for now Pippin.December 19, 2013 at 7:58 pm #152792
Great.January 5, 2014 at 1:37 pm #159735
For what it’s worth, I am also having this issue of using AJAX with the WordPress HTTPS plugin. The buttons I use that directly add an item and take you to the cart work fine. And when I was testing without SSL/WordPress HTTPS, everything was functional.
Is it something that is going to be resolved in 1.9? Or is it a WordPress quirk that is out of the hands of EDD?January 5, 2014 at 6:52 pm #159876
@Evan There is not anything getting changed in 1.9 related to this issue.
I’ve done extensive testing and it has something to do with how the WordPress HTTPS plugin forces the HTTPS.
The best way to resolve it that I have found is to force the HTTPS on the server level, instead of at a plugin level.January 6, 2014 at 1:50 am #160001
Thanks for the reply, Pippin. Wasn’t sure if there was anything that was in motion to be altered in EDD, so figured I’d ask.
So to force the HTTPS on the server level, does that need to be done on the product/shopping pages (where the AJAX buttons are) and the checkout page?
I tried forcing it on the server level and unchecking the WordPress HTTPS plugin option, but then I’m having weird behavior in the cart (like I can’t select PayPal as a payment method — even if I select it and move to the next step, it goes to the default of Stripe) and then it also won’t process a payment. It’ll just reload the page on the same step.
Any ideas on what might be happening there?
You must be logged in to reply to this topic.