Support

Home Forums Event Espresso Premium Add to Cart Requires Logged-in User?

Add to Cart Requires Logged-in User?

Posted: November 6, 2012 at 2:19 pm


Brian Alexander

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:

echo do_shortcode( '[ESPRESSO_CART_LINK anchor="RSVP" direct_to_cart=1 moving_to_cart="Redirecting...please wait" class="button rsvp inline enabled"]' );

When I’m logged into WP, clicking the button shows the redirecting message and I’m sent to the cart page as expected (and ?regevent_action=show_shopping_cart is appended to the page URL).

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
> your registration or your cart is empty. Please go to the events page
> and try again.

Any ideas why this is happening?

Thanks,
Brian


Brian Alexander

November 6, 2012 at 2:53 pm

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.


Jonathan Wilson

November 6, 2012 at 2:57 pm

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.


Brian Alexander

November 6, 2012 at 3:01 pm

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.


Jonathan Wilson

November 6, 2012 at 3:08 pm

Do you have a price set for the event? If it is a free event, the price needs to be set to 0.00.


Brian Alexander

November 6, 2012 at 3:16 pm

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.


Jonathan Wilson

November 6, 2012 at 4:06 pm

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?


Brian Alexander

November 6, 2012 at 4:33 pm

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,
Brian


Jonathan Wilson

November 6, 2012 at 4:48 pm

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.


kromero

November 6, 2012 at 4:59 pm

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.


Brian Alexander

November 6, 2012 at 5:13 pm

Jonathan: I’ve posted the site info to you as requested.

Thanks!


Brian Alexander

November 8, 2012 at 11:13 am

Hi, Jonathan — any chance you’ve been able to see what’s going on with my EE installation?


Jonathan Wilson

November 8, 2012 at 12:19 pm

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.


Jonathan Wilson

November 8, 2012 at 12:23 pm

@kromero if you are still having problems, can you start a new topic so we can assist you there? Thanks.


Brian Alexander

November 8, 2012 at 12:56 pm

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!


Jonathan Wilson

November 8, 2012 at 1:02 pm

Okay. You can re-enable them. I am still looking.


Jonathan Wilson

November 8, 2012 at 2:18 pm

Brian,

Can you compare the two installations (the one on live and the one on staging) to see what the difference is?


Brian Alexander

November 8, 2012 at 3:10 pm

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 😉


Brian Alexander

November 8, 2012 at 4:34 pm

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.


kromero

November 8, 2012 at 4:56 pm

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?

  • This reply was modified 11 years, 5 months ago by  kromero.


Brian Alexander

November 8, 2012 at 5:07 pm

@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.


kromero

November 8, 2012 at 5:18 pm

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.


Brian Alexander

November 8, 2012 at 5:21 pm

More tests to add to the list:

  • restoring the DB from the staging site (which works) did not fix the issue in prod
  • hard-coding WP_SITEURL/WP_HOME did not fix it (it’s hardcoded in staging)
  • changing the siteurl and home URL to WP Engine’s default did not work (I have a subdomain alias for prod)
  • resetting permissions and dumping the cache (WP Engine features) did not work

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.


kromero

November 8, 2012 at 7:50 pm

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


Brian Alexander

November 8, 2012 at 8:17 pm

@kromero: I hope you’re right — I’ve submitted a ticket to WPE with the events page path as well.

Thanks!
Brian


Brian Alexander

November 8, 2012 at 9:13 pm

[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:

  • Site hosted with WP Engine
  • Multiple Event Registration redirect to cart using [ESPRESSO_CART_LINK] shortcode does not display cart, but displays error “It looks like you are attempting to refresh a page after completing your registration or your cart is empty. Please go to the events page and try again.”
  • Issue does not occur if user is logged into WordPress
  • WPE-generated staging site is not affected by this issue
  • Events list located at http://mydomain.wpengine.com/calendar/
  • Opened support ticket with WPE and requested that /calendar/ be excluded from caching
  • Non-logged-in users are now able to see the cart and complete registrations

Thank you Jonathan and kromero for your help in isolating where the issue was occurring so that this could be resolved.

Cheers,
Brian

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.

Event Espresso