|
January 6, 2025 at 6:35 am
Thanks – well It worked on mobile or laptop if I was logged in as the admin on the website.
The reason its not working (on any device) is down to those critical pages being draft.
As an admin (logged in) ou can view those draft pages using any device, but public visitors can’t see those, so it will fail on any device not logged in.
But I followed your link and the page was set to “draft” so I public published it as you reccommended.
That’s good, all of the EE critical pages need to be published publicly for EE to work, those are the only 4 pages we require for EE to work.
How did this get changed all the sudden as all my other events did this too all the sudden. I’ve been using for a year with no issue.
This isn’t happening for a specific event, it’s an issue with your Event Espresso configuration on the site so it happens to all events becuase it is a critical page that is the problem. All events go through the Registration Checkout page, the events themselves pass all of the data over to the checkout so if there is an issue with checkout it affects everything.
I can tell you that EE will not change those posts to be draft, we require them for EE to work so the only thing EE will ever do with them is create them and publish them on initial activation. Anything after that is done outside of Event Espresso.
Maybe we changed a setting somewhere by accident. It looks like all the critical pages are unpublished?
Unfortunately, that’s not something I can give you an answer to.
The change here is going to be something changing those posts from outside EE, but I have no idea what, it’s not something I’ve seen happen before.
Can I send you a screenshot of those and do I need to change those?
Sure, if you want to send a screenshot over to support[at]eventespresso.com I’ll take a look, but yes, all of the critical pages should be published publicly.
Should I uninstall the WP Rocket that the host told me to install in order to fix this?
I don’t understand why they had you install that plugin, they’ve asked you to install a caching plugin adn then exclude EE from the cache…. but if you didn’t have WP Rocket installed in the first place it wouldn’t have been caching EE and so wouldn’t need to exclude it.
If the site runs without the cache, I’d clear the cached within WP Rocket and deactivate it.
Is that Cache thing they told me about not an issue?
Caching is a way of reusing data for multiple requests… say you load a page on your site. WordPress pulls in all of the data for that page and builds out the content to then display to User A.
User B comes along and views that same page, if nothing changed on that page then rebuilding all of the page isn’t very efficient, if you can use everything that was sent for User A and send it to User B… great! Thats quick and efficient.
Where that becomes a problem is e-commerce (like Event Espresso) becuase User A and User B’s data will NEVER be exactly the same, we need to keep those separate, so you can’t cache that data and resuse it.
That means that if you use caching on the site, EE pages need to be excluded from it. This is where I’m a little confused as to their recommendation of using WP Rocket… if there wasn’t a cache in the beginning then the issue wasn’t with caching (as there was none) so their solution was then install a caching plugin and exclude EE from that caching?
Caching is fine, if you exclude EE’s pages from the cache, but I don’t think (based on the info you’ve given) that caching was/is the problem so far.
|
