Ajax add to cart not working

Can we see the site using the default Twenty Fourteen theme with all other plugins deactivated?

FYI, the /tmp folder on Shared is (logically enough) shared with all users on the server.

max_Q, what’s your domain? I can see if tmp got full.

esmi, if there’s any debugging I can do for you on the box, let me know ??

Good morning (where I am, anyway),

Here’s the problem. This is an existing site I’m rebuilding in WordPress for a client. It’s behind an “under construction” page and it’s in pretty rough shape. They wouldn’t want me exposing it in it’s current condition.

I’d be happy to send either of you a login privately, or undertake any debugging you’d like.

BTW, the “under construction” page is being provided by a plugin, but I disabled it (briefly and late at night), along with all the other plugins, to troubleshoot this problem.

Regards

The under construction plugin has to be a strong suspect in this. Some of them can stop eShop in its tracks. So ideally, you need to test with this plugin deactivated, deleted and staked through the heart.

Which of the eShop widgets are you using?

@ipstenu-dh: Thanks for the offer. Will let you know if anything needs to be checked on the box.

Hmmm, it was deactivated, but not deleted or staked. There were no javascript errors in the console, though. I will delete it, briefly, and let you know what happens. How do you stake a plugin thorough the heart? ??

Personally, I’d suggest resetting the plugins folder using PhpMyAdmin. It has been known for an apparently inactive plugin to still cause problems but this method does seem to kill them off.

Ok, so I deactivated and deleted the under construction plugin. The only plugin running on Twenty Fourteen is eShop. The result was the same, “Added” displayed, but nothing added to cart.

There is a wrinkle I didn’t notice before, though: the cart widget (eShop Cart Improved) is set to display the full cart, and on a page refresh it shows “Your Cart Is Empty,” “View Cart” and “Checkout” under the title. After the ajax add to cart, everything but the cart title disappears. After a page refresh “Your Cart Is Empty,” “View Cart” and “Checkout” are displayed again.

What happens you you add something to the cart via a product post or page rather than using the widget?

I am adding from a post page. I just had the eShop Cart Improved widget in the sidebar to see the contents of the cart after doing an ajax add. But I can confirm that the widget isn’t wrong, going to the cart shows it is empty.

Then it would seem to suggest that you do have a server sessions issue. Have a look at https://quirm.net/wiki/eshop/troubleshooting/checkout-and-empty-carts/

@ipstenu-dh: Can you see if session.auto_start and/or output_buffering to set to On on the server?

My phpinfo shows:

session.auto_start Local Value Off Master Value Off
output_buffering Local Value 0 Master Value 0

Can you set up site-specific php.ini files on Dreamhost?

Hi esmi,

From the documentation it appears you can. Happily, it won’t be necessary. I have a resolution, and it doesn’t involve the server setup or eShop.

First of all, thank you for all the time and effort you’ve put into helping me trace this issue. It’s much appreciated. Maybe this thread will be useful to someone else, someday.

So I realized that the session id’s were different between the two ajax calls, as well as being different from the session id of the cart page. The reason, I found, was eShop wasn’t getting sent cookies for either of the ajax calls, so it was creating a new session, and setting new cookies, for both of them.

Now, what would prevent a browser from sending a cookie to a domain it has a stored cookie for? I should have thought of this right away (and you may say “yes, you should have”): same-origin policy. I’m running admin over https with FORCE_SSL_ADMIN, and of course all ajax calls in WordPress are directed to the admin area (/wp-admin/admin-ajax.php). So the browser sees https !== http and refuses to send the session id cookie. Visiting the product page over https allowed the whole process to work as designed. So the moral of this story is if you want to use WordPress ajax with sessions, and you’re running admin in ssl, the page that sets the session id cookie has to be using ssl as well.

I’m still researching methods of passing sessions between http and https. It may be as simple as calling session_start() at the beginning of the function. Of course, just forcing access to the whole shop over https would solve my problem, but I know you don’t support using eShop with ssl. Does that mean there are known problems, or just that I’m on my own? At any rate, I’m marking this resolved.

Regards

So the browser sees https !== http and refuses to send the session id cookie.

Oh – that would never have occurred to me if you hadn’t pointed it out.

Does that mean there are known problems, or just that I’m on my own?

More that you’re on your own. We’ve never been able to really test eShop out using SSL as all of our demo sites are on shared hosting rather than a dedicated remote box.