Posted: November 6, 2012 at 2:19 pm
|
Hi, I’m using EE 3.1.27.1.P (+ MER 1.0.4, CF 3.1, and RE 1.1.7), and have the following cart shortcode in place:
When I’m logged into WP, clicking the button shows the redirecting message and I’m sent to the cart page as expected (and However, if the button is clicked when NOT logged into WP, after the redirect, instead of the cart, the following error message is displayed: > It looks like you are attempting to refresh a page after completing Any ideas why this is happening? Thanks, |
|
Something to add is that I’ve duplicated the site and database (using the staging feature of WPEngine), and on the staging site everything works okay, even for non-logged in users. I’ve tried removing the Custom Files directory in production, to see if the default template files that came with EE would work okay, but I’m seeing the same issue where the cart page will not render, and shows the error mentioned above. I can’t see any differences in permissions for the plugin files between prod and staging. Totally stumped. |
Hey Brian, Do you have any custom templates in the /wp-content/uploads/espresso/templates directory? Try renaming that directory to something like templatesold to see if that corrects the problems. |
|
|
Hi, Jonathan, Yes — not sure if you saw my update, but I tried doing that, and while the built-in “add to cart” function does work, if you actually click a link to view the cart, the cart page displays the aforementioned error. |
Do you have a price set for the event? If it is a free event, the price needs to be set to 0.00. |
|
|
Yes, I actually have two test cases for this. One for a free event (price and surcharge set to 0.00) and another event with 3 pricing levels. The behavior is the same in that the cart won’t load. |
Sorry to backtrack, but you said you removed the Custom Files directory. Did you mean the templates directory in wp-content/uploads/espresso? Can you give me the URL to your site? |
|
|
Yep, in my testing I renamed the uploads/espresso/templates directory so that they were no longer being picked up. I can’t give the site’s URL on a public forum (it’s not been launched yet), but if there is a way I could email you directly, that would work. Thanks, |
I understand. If you want, we can log into the site so we can investigate further If that’s okay with you, please send WordPress admin level log in credentials via the contact form on this page: https://eventespresso.com/contact/ Please select the “I am sending login info as requested” department form. |
|
|
We are having the same issue as Brian. If you can please post the solution once its resolved, we can apply that to our install as well. |
|
Jonathan: I’ve posted the site info to you as requested. Thanks! |
|
Hi, Jonathan — any chance you’ve been able to see what’s going on with my EE installation? |
Hey Brian, Sorry for the delay. I am looking at your site now. I see you have some custom plugins that I don’t want to touch. Can you try to rule out any plugin conflicts by deactivating all non-Event Espresso plugins? Then test to see if the problem is still occurring. |
|
@kromero if you are still having problems, can you start a new topic so we can assist you there? Thanks. |
|
|
I’ve disabled everything but EE plugins, purged the site caches, and the error still comes up on the cart redirect. Could it be an issue with the DB or something? Please take a look and let me know when I can re-enable the plugins. Thanks! |
Okay. You can re-enable them. I am still looking. |
|
Brian, Can you compare the two installations (the one on live and the one on staging) to see what the difference is? |
|
|
To create the staging environment, I used WP Engine’s built-in staging tool. As I understand it, they just snapshot all files and DB, and setup a staging URL that points to that instance. For comparison, I did check file permissions, particularly with respects to the EE plugins and custom files, and saw that they had the same owner/group and access settings. I’m going to try doing a restore into a new instance (essentially what the staging environment is), and see if that works. It sucks not knowing what’s happening though 😉 |
|
The restore into a new instance did NOT fix the issue. I’m going to backup the DB and try and restore the staging site’s DB in its place to see if that makes a difference. The only other thing that comes to mind is that the staging site’s WP_HOME/SITE URLs are hardcoded in wp-config.php, whereas it depends on the DB for the prod site. |
|
Jonathan, Interesting to note that both Brian and I have our install on WPEngine. This could be a WPEngine caching issue. Do you still want me to create a new topic? I have a support token out on this and Josh was helping me on it – so I think between following this topic and the support token I’m covered, right?
|
|
@kromero: Did you try launching a staging instance off the one where the cart isn’t working? In the staging environment it works for me. As far as caching goes, I’ve disabled obj/trans cache and forced cache clears during my testing, but I guess cached resources could be something to look at. |
|
Just did! You’re absolutely right, it works in the staging environment. My gut tells me its a WPEngine setting for live sites that is disabled for the staging area. |
|
More tests to add to the list:
What are the dependencies for rendering the cart on the page? That would be a good place to start, since that’s where the issue starts. Page loads, but an error where the cart should be. |
|
Hi Jonathan, Josh and Brian – Good new from WP Engine that could solve the issue, WP Engine support states: “You’re right on the money! The staging area is different than the production area for a few different reasons. First and most important — all caching is disabled in staging. If you’re using a checkout process or shopping cart of some sort, please let us know what path/URL that is on and we can put some caching exclusions on there to reflect the changes of the individual users!” I’m going to move forward with this and see if that resolves it. Best – Kristina |
|
@kromero: I hope you’re right — I’ve submitted a ticket to WPE with the events page path as well. Thanks! |
|
[RESOLVED] For sites hosted at WP Engine, due to their aggressive caching mechanism, you must request that the URL(s) where your Event Espresso cart is located be excluded from caching. This is as simple as opening a support ticket with WPE, providing the URL or path where your cart is located, and explaining that caching is preventing the plugin from functioning as designed. A WPE engineer has to review the request, but once approved, the change goes in immediately. Here’s a brief recap of my scenario, for others’ reference:
Thank you Jonathan and kromero for your help in isolating where the issue was occurring so that this could be resolved. Cheers, |
The support post ‘Add to Cart Requires Logged-in User?’ is closed to new replies.
Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.