Can’t complete a ticket purchase as guest

We’ve recently migrated our website to a modern managed hosting partner, and are having difficulty with ticket purchases now. When a guest (not logged-in visitor) goes to https://newwavesingers.org/events/click-here-for-tickets-to-the-saturday-12-6-25-700pm-performance-of-sounds-of-the-season/? … selects some tickets and clicks ‘Register Now’, they get sent to an “Oops, that page can’t be found” at this URL: https://newwavesingers.org/registration-checkout/page/#checkout … instead of the expected content (which logged-in visitors CAN see at the same URL). Any thoughts on what might be causing this error? We need to be able to sell tickets for our upcoming holiday concert. Thanks for your help and hoping for a speedy resolution! The page I need help with: [ log in to see the link] Hi there, This URL: https://newwavesingers.org/registration-checkout/ Would be the ‘standard’ URL most EE installs have, but when I navigate to that page, I’m not seeing the output I would expect. This page: https://newwavesingers.org/registration-checkout/page/ I can’t view as I get a 404, is that another page saved as a child of Registration Checkout? If so has it been privately published? What do you see when you click the above link whilst logged in? Go to Event Espresso -> General Settings -> Critical pages. What page is listed for ‘Registration Checkout Page’ on that section? (Click the ‘View’ link next to it, where does that take you?) Hi Tony, thanks for your speedy response. I ran through your list of things to check, and have some additional details that might help us diagnose and resolve this issue. First off, the standard EE checkout page you referenced is indeed the page specified in our ‘Critical Pages’ screen. When I visit that URL (that is, https://newwavesingers.org/registration-checkout/ ) directly, without initiating a ticket first, in either a logged-in or unlogged-in state, I see a regular page and headline, but the shortcode isn’t pulling in any additional data so the page is empty otherwise (if that’s not normal). When I’m logged in, and I start a ticket purchase, I get sent to a VERY different URI: https://newwavesingers.org/registration-checkout/?uts=1762880906#checkout . That page delivers the totally expected, totally correct ticket purchaser next step experience: Steps / event+ticket deets / attendee details intake form / ‘Proceed to Finalize Registration’ button. A few additional details that might help further with diagnosis / resolution: I tried adding a 301 redirect, from /registration-checkout/page/ to https://newwavesingers.org/registration-checkout/ , passing all query parameters as-is. This did land a not-logged-in ticket purchase attempt on the right page (no more added /page/#checkout at the end of the URI, no more ‘Oops… 404’ message) but did not seem to properly pass the querystring value in a way EE could use. Try for yourself, starting your purchase attempt from this URL if it’s helpful: https://newwavesingers.org/events/click-here-for-tickets-to-the-sunday-12-7-25-400pm-performance-of-sounds-of-the-season/ The old version of this website we brought over during migration ran a MUCH older version of EE, which I updated during migration and tested, in a general way, but had no live event at the time to test ticketing functionality. This is our first attempt to provide EE event ticketing after the rebuild. I used WP’s default export/import tool, rather than a migration plugin, because the old site was a standalone WordPress build but the new incarnation is a daughter site on a multisite network. I’m not certain if the old site used a different permalink structure than my rebuild. Could that impact this issue somehow? Should I try setting permalinks to ‘Plain’ instead of ‘Post name’? Anyway, appreciate your thoughts and guidance on where to go from here. Tony, any chance you can feed back on this soon? I don’t want to leave my client hanging with no way to resolve this problem ahead of their upcoming holiday concert Dec 7. They brought EE to the party – it’s not my usual choice of event ticketing tool – but I made a good-faith commitment to help support their use of it, with the understanding in advance that a lot of that support would come down to timely assists / insights from the EE developer. Hope you can help us out; if not, they might need to consider alternatives. Thanks in advance for your expert assist! Hi there: When I visit that URL (that is, https://newwavesingers.org/registration-checkout/ ) directly, without initiating a ticket first, in either a logged-in or unlogged-in state, I see a regular page and headline, but the shortcode isn’t pulling in any additional data so the page is empty otherwise (if that’s not normal). That is normal because there is no session information in the browser. When I’m logged in, and I start a ticket purchase, I get sent to a VERY different URI: https://newwavesingers.org/registration-checkout/?uts=1762880906#checkout . That page delivers the totally expected, totally correct ticket purchaser next step experience: Steps / event+ticket deets / attendee details intake form / ‘Proceed to Finalize Registration’ button. That is correct, the url is referencing the checkout process with a timestamp to break any potential caching to make sure the browser and checkout data stays fresh and accurate. I tried adding a 301 redirect, from /registration-checkout/page/ to https://newwavesingers.org/registration-checkout/ , passing all query parameters as-is. This did land a not-logged-in ticket purchase attempt on the right page (no more added /page/#checkout at the end of the URI, no more ‘Oops… 404’ message) but did not seem to properly pass the querystring value in a way EE could use. Try for yourself, starting your purchase attempt from this URL if it’s helpful: https://newwavesingers.org/events/click-here-for-tickets-to-the-sunday-12-7-25-400pm-performance-of-sounds-of-the-season/ A couple things: 1. It is highly irregular to have the extra /page/ in the route while your events are not also in that same sub directory. Normally this means that WordPress is installed in /page/, but yet your events are published without /page/. 2. Adding the redirects may complicate your ability to debug further because you’re not getting the real responses during testing. so basically: /registration-checkout/ is getting redirected to: /registration-checkout/page/ which is getting redirected to: /registration-checkout/ it’s the first redirect to /registration-checkout/page/ that appears to be breaking things See #3. 3. You’ve also 301 redirected the proper Event Espresso request to /registration-checkout/?uts=….. which is going to cause failures. So, these redirects are actually causing conflicts. 4. Have you updated your .htaccess file for the new web host? That file normally has to be reconfigured when you changes hosts and servers. Other things: 1. Look at your network response headers, you have some caching happening. Contact your host (looks like Kinsta and ask them to exclude your ecommerce pages from caching). More on that here: https://support.eventespresso.com/article/473-how-to-setup-no-cache-exclusion-rules-for-event-espresso Have your host take a look at your .htaccess file, but you need to figure out all the redirect issues, because that’s what is breaking things. If you want us to look into this for you, please purchase a support license and a support token so we can look into it directly. Resolved, with help from my hosting tech support team. FYI (in case this comes up for other users), I had toggled (per my usual practice) a Yoast Advanced setting, to strip unregistered querystring pairs, that was interfering with EE’s regular functioning. Unchecking that obscure lil’ box cleared the whole problem right up. Thanks again for eliminating some possibilities in advance that helped me and my support guys focus on likelier culprits. :Benjamin Thank you for the follow-up and your valuable contributions. WordPress’s flexibility in allowing users to install any plugin or theme without coordination can lead to conflicts or an excessive number of features and code, resulting in a bloated website. That can make the website hard to maintain, especially when it comes to ecommerce like events and tickets. Glad we could help. Keep up the good work. 👍