|
greensatx
|
August 29, 2016 at 11:48 am
Hi,
All of our events are displaying one event’s registration form, when each event should have their own unique form. The event form that is appearing happens to be the only paid event, the rest are free. When I’m logged in to WordPress, the event registration forms show up perfectly fine – the problem only appears on the public user side, i.e. when I’m signed out.
I’ve tried clearing the cache, disabling the cache plugin, and disabling the Bot Trap in reg. form settings, which I found suggested in another EE forum.
Any suggestions? Should I simply upgrade to the newest version of EE?
Here is our events home page: https://www.greensatx.org/events/
Thank you for your help! (P.S. not an expert at this, learning as I go along.)
-Tia
|
|
Lorenzo Orlando Caum
|
August 29, 2016 at 12:43 pm
Hello,
Thanks for letting us know what you have tried. You shared that this works as expected when you are logged in. Who is your web host (hosting provider)?
I looked through a few events and I see that the personal information group is being collected. Since question groups are enabled on a per-event basis, then it is the default behavior to show the personal information group which includes a name and an email address.
Could you share a link to an event where you are asking custom registration questions?
—
Lorenzo
|
|
greensatx
|
August 29, 2016 at 1:27 pm
Hi Lorenzo, thanks for the info.
Our web host is Dreamhost.
Here is an event for which we have a custom form:
https://www.greensatx.org/events/herbs-out-of-the-box-workshop/
And another:
https://www.greensatx.org/events/2016-gala-land-we-love/
I notice they both have the same registration page URL, if that helps: https://www.greensatx.org/registration-checkout/#checkout
-Tia
|
|
Lorenzo Orlando Caum
|
August 29, 2016 at 2:06 pm
Hello,
All events will flow through the registration checkout page as it handles registration and payments (if needed).
If you look at the Herbs Out Of The Box Workshop with the event editor in the WP dashboard, then what do you see check for the question groups in the bottom right area of the screen?
Could you share a screenshot with us please?
https://eventespresso.com/wiki/troubleshooting-checklist/#screenshots
—
Lorenzo
|
|
greensatx
|
August 29, 2016 at 2:49 pm
Ok thanks. Here is the screen shot: https://www.greensatx.org/screen-shots-event-question-groups/
-Tia
|
|
Josh
|
August 29, 2016 at 4:41 pm
This sounds like a caching issue because you mentioned that:
When I’m logged in to WordPress, the event registration forms show up perfectly fine – the problem only appears on the public user side, i.e. when I’m signed out.
If there are no caching plugins in use on this site, you can contact your host and ask them if they can move your site to a server that doesn’t serve logged out visitors of the site from a cache.
Those registration forms are dynamically generated for each registration, but caching will end up serving the same form to later visitors.
|
|
greensatx
|
August 30, 2016 at 12:28 pm
We do have a caching plugin, but it has been disabled for a while. When this problem arose, we re-activated the plugin and cleared the cache, then disabled the plugin again, with no different result. So, with your info, I will see what we can do from here. I’ll come back if we don’t fix the problem. Thank you for your help!
-Tia
|
|
Lorenzo Orlando Caum
|
August 31, 2016 at 7:23 am
Hello,
If the caching has been turned off, then this shouldn’t be still occurring.
Could you follow up with a temporary login so we can help you troubleshoot this further?
https://eventespresso.com/send-login-details/
Please double-check the temporary login information before submitting the form.
Thanks!
—
Lorenzo
|
|
Josh
|
August 31, 2016 at 9:16 am
There’s some built in caching on the server. Here’s a screenshot that shows one example:
https://www.evernote.com/shard/s4/sh/6f7a2487-9d1d-4f83-84bd-3fb90c310995/4c131c3607a8f0a3268e6acda831ff82
The screenshot shows where I added an html comment to the end of the event description. The browser window on the left is logged into the site. The browser window on the right is not logged into the site. Do you see that the html comment isn’t there in the window on the right? That’s because the page is being served from a cache instead of dynamically.
Event Espresso pages need to be served dynamically. Can you contact your host and ask them to disable caching for these pages?
https://www.greensatx.org/registration-checkout/
https://www.greensatx.org/events/
https://www.greensatx.org/upcoming-events/register-for-a-workshop/transactions/
https://www.greensatx.org/upcoming-events/register-for-a-workshop/thank-you/
https://www.greensatx.org/upcoming-events/register-for-a-workshop/registration-cancelled/
|
|
greensatx
|
August 31, 2016 at 9:25 am
Yes, I see the difference. Thank you very much! I would have never found that evidence, nor known what it meant. I’ll contact our host (DreamHost).
-Tia
|
|
greensatx
|
September 2, 2016 at 10:08 am
This was the reply from our host (DreamHost): “Our shared servers do not cache pages by default and it is enabled from a plugin and .htaccess file. I’ve checked your wp-config.php and .htaccess file but see no reference of caching. I recommend to completely remove all unused plugins including the inactive cache plugin and update the outdated plugins listed below to see if that will help.”
So, I deleted plugins we don’t really need, and updated all plugins. The problem remains, and I have asked DreamHost for further suggestions. Do you have any further advice for what to try next, or other helpful information? Thank you.
-Tia
|
|
Josh
|
September 2, 2016 at 2:35 pm
Maybe ask them why edits to pages don’t show up when you’re not logged into the site. That’s typically something you’ll only see when caching is involved.
|
|
greensatx
|
September 6, 2016 at 10:07 am
DreamHost double checked on the shared server to confirm there was no caching enabled server side. They said their shared servers have recently been set up with an OPCache service, however this is disabled by default. They did confirm that OPcache is disabled for our site, by looking at our PHP info.
Since I was still able to see the issue via a proxy site (server6.kproxy.com), they said they “could only assume it’s not caching since the proxy typically display sites without the caching.” DreamHost suggests try clearing both browser and DNS cache to see if that helps after viewing the proxy, but also said it’s starting not to look like a caching error, since they didn’t see any caching enabled on the site or server.
I should mention, this problem happened sometime after I upgraded to the newest version of WordPress, 4.6. Might there be a problem with EE working with this WP version?
-Tia
|
|
Josh
|
September 7, 2016 at 7:11 am
No we have not seen this occur on any other sites running Event Espresso on the current WordPress version, and that would not explain the sequence of events that we observed on your site. The sequence of events being an edit was made to an event, and the edit was visible only while logged into the site. The edit was not visible while logged out of the site.
|
|
greensatx
|
September 22, 2016 at 11:25 am
Hi, I’m just here to give an update. None of the suggestions from Event Espresso or DreamHost fixed our problem, but an update to EE version 4.9.12.p today fixed it. We had updated to the previous newest version last week, which didn’t fix the problem, but this update did! So, thank you for your help and for making changes to the newest version. Whatever you did, it worked!
|
|
Josh
|
September 22, 2016 at 2:38 pm
It was most likely the “Add timestamp parameter to registration checkout URL from ticket selector in an attempt to bust site caching” change that was added to Event Espresso 4.9.10.p.
The problem is, your site is likely still being served from a cache (and opcache shouldn’t be a problem, it’d be another type of caching that would cause these issues). So if you see problems with registrations not being recorded correctly, you can contact your host and ask them to disable any other type of caching that may be enabled (such as database caching, object caching, or page caching).
|
