|
YCParks
|
January 19, 2022 at 11:34 am
Using Question Groups on the registration form, some visitors are seeing the previous submission personal data. Caching is disabled and this doesn’t always occur.
/registration-checkout/?uts=1642617113#checkout
UTS sometimes generates an old value? This seems to be redirected through the plugin, re-showing a previous users’ submission / attendee data. We need a unique form to be generated for each ticket. Guest users should not see the previous submission.
|
|
Tony
|
January 19, 2022 at 11:44 am
Hi there,
In short, this has to be some form of caching.
UTS = Unix Time Stamp … within the plugin, it is literally the value returned by the PHP function time() (meaning the number seconds passed since January 1 1970 00:00:00 GMT) so if your getting ‘old’ values… its because the request was cached. As much as we wish it could sometimes, time never goes backwards 🙂
You mentioned caching is disabled, is that a caching plugin? Which one?
Have you checked for server-side caching?
My guess is there is server-side caching somewhere here, who is your host?
Can you link me to an event I can test?
|
|
YCParks
|
January 19, 2022 at 11:52 am
Hello! We have disabled our WordPress caching plugin & we should not have server level caching. We are hosted with LiquidWeb. The homepage has the calendar with events at: https://parkevents.yorkcountypa.gov/ OR direct: https://parkevents.yorkcountypa.gov/registration-checkout/?uts=1642618171#checkout
|
|
YCParks
|
January 19, 2022 at 12:10 pm
It looks like the plugin is trying to loop through previous registrations / tickets and display them? Is there a setting where we can disable showing other users’ info: /event-espresso-core-reg/modules/single_page_checkout/reg_steps/attendee_information/attendee_info_single.template.php Several plugin files look like they are trying to retrieve this data.
|
|
YCParks
|
January 19, 2022 at 12:23 pm
Can you confirm that your plugin is adding the UTS query parameter? I see in EE_config.core.php: /**
* gets/returns URL for EE reg_page
*
* @access public
* @return string
*/
public function reg_page_url()
{
if (! $this->reg_page_url) {
$this->reg_page_url = add_query_arg(
array(‘uts’ => time()),
get_permalink($this->reg_page_id)
) . ‘#checkout’;
}
return $this->reg_page_url;
}
|
|
Tony
|
January 19, 2022 at 12:57 pm
It looks like the plugin is trying to loop through previous registrations / tickets and display them?
No, it does not display previous registrations.
Is there a setting where we can disable showing other users’ info: /event-espresso-core-reg/modules/single_page_checkout/reg_steps/attendee_information/attendee_info_single.template.php
There’s no setting for this because it’s not a feature, may I ask what it is about that template file gives you the impression that it pulls in past registrations?
Can you confirm that your plugin is adding the UTS query parameter?
Yes, we add the UTS value to the reg page URL.
It is a very basic cache-busting method in which having a unique value in the query string can prevent the browser/server from caching the output and other than that, it isn’t used within Event Espresso.
|
|
YCParks
|
January 19, 2022 at 1:03 pm
It looks like within the single checkout module files, the previous ticket / attendee is being referenced: $att_nmbr = 0;
$prev_event = 0;
$prev_ticket = 0; // plugins/event-espresso-core-reg/modules/single_page_checkout/reg_steps/attendee_information/attendee_info_main.template.php. We do not have any forms of caching enabled; is there any kind of reset or hook we can run on checkout, so a new form is always generated? Thank you!
|
|
Tony
|
January 19, 2022 at 1:12 pm
It looks like within the single checkout module files, the previous ticket / attendee is being referenced: $att_nmbr = 0;
$prev_event = 0;
$prev_ticket = 0; // plugins/event-espresso-core-reg/modules/single_page_checkout/reg_steps/attendee_information/attendee_info_main.template.php.
That’s not what is happening there, it’s nothing to do with the previous registrations/ticket/attendee.
Registrations are created early in the checkout process (when you submit tickets) the SPCO module is looping over those registrations to generate the attendee information form but again, they are NOT previous registrations.
If EE did what you are saying by default it would cause issues for pretty much everyone who uses it, there is no valid reason for EE to pull in and display the previous submission for the registrations. It simply doesn’t work that way.
We do not have any forms of caching enabled;
The only time I see anything like this is when the requests are cached, so your 100% sure you don’t have ANY form of caching enabled?
Not just some form of page caching but OPCache, Object caching such as Memcached, Load balancing etc?
is there any kind of reset or hook we can run on checkout, so a new form is always generated?
No, what you are seeing is not a ‘feature gone wrong’ so there isn’t a reset of any kind. If you are getting a registration form with another registrants details you either have a cached response from them or you’ve taken over their session…. in either case, ‘resetting’ the form isn’t a solution, it masks the problem and could cause more issues when you complete/submit the form.
|
|
YCParks
|
January 19, 2022 at 1:19 pm
Thank you for all the info on this! Instead of going with a ‘reset’ what do you recommend for next steps on resolving this issue? As this is showing personal data; we need to make sure new customers do not see any previous registered users.
|
|
Tony
|
January 19, 2022 at 1:35 pm
The only time I see anything like this is when the requests are cached, so are you 100% sure you don’t have ANY form of caching enabled?
Not just some form of page caching but OPCache, Object caching such as Memcached, Load balancing etc?
What hosting package do you have with LiquidWeb?
|
|
YCParks
|
January 19, 2022 at 1:48 pm
We have their Cloud hosting package; we have full WHM / cPanel access and we can confirm there is not any form of caching (OPCache, Object caching such as Memcached, Load balancing etc)
|
|
Tony
|
January 19, 2022 at 1:57 pm
Ok, so has anything changed recently? Either on the site itself or with your hosting?
Currently, you’re running version 4.9.65.p which was released on July 17, 2018 so this isn’t an issue from an EE update.
Is there something preventing you from updating from that version? We’ve had a lot of bug fixes and for various areas of the plugin in the 3+ years since that version.
|
|
YCParks
|
January 19, 2022 at 2:06 pm
Hello again! We have been experimenting with different plugin versions; it doesn’t matter if we are on the originally working, old versions or the latest edition. The issue is still persisting. We will update to the latest version again.
|
|
Tony
|
January 19, 2022 at 2:08 pm
Ah, ok. So yeah, you shouldn’t get different results with different versions of EE and this issue as the way in which it works hasn’t changed in a long time now.
So then what else has changed, site/server wise?
|
|
YCParks
|
January 19, 2022 at 2:49 pm
Hello!
I appreciate your quick replies. Based on your feedback and suggestions, we’ve made a copy of this site on our staging server.
Now we are on our own server and can rule out caching completely.
We have disabled all other plugins. These are all on the latest version; Only active plugins are:
Event Espresso
Event Espresso – Barcode Scanner (EE 4.6.0+)
Event Espresso – Calendar (EE 4.3+)
Event Espresso – Promotions (EE 4.9.10+)
Event Espresso – Ticketing (EE 4+)
Event Espresso – TransFirst Transaction Express (EE 4.9.17+)
We have reverted to using the default WordPress 2021 Theme. There should be no area for conflict with your plugins now.
However, we are still able to replicate the last issue. We can provide access if you need to look into this further.
Since we ruled out these areas as possible conflicts, what else could be the cause of this issue.
Thanks again!
|
|
Tony
|
January 19, 2022 at 2:52 pm
Is the staging server still with LiquidWeb?
If so it’s still possible to be some kind of config issue.
|
|
YCParks
|
January 19, 2022 at 3:00 pm
Nope–it is a completely different server. We do not have any type of server level caching enabled as this staging server is only used for site builds, not live sites. With everything else ruled out, are you able to take a deeper look into this?
What kind of configuration do you usually support?
Test URL: https://yorkcountypaevents.webpagefxstage.com/?user=positive&pass=powerhouse
1. Bottom calendar on homepage; click any event.
2. Choose ticket option and choose register
3. Form will occasionally load previous submission data
Example: https://yorkcountypaevents.webpagefxstage.com/registration-checkout/?uts=1642629236#checkout Benjamin Mahon and other info populates into Attendee 1–no caching, no other active plugins/theme.
|
|
Tony
|
January 19, 2022 at 3:49 pm
Ok, can you send me login details for that site so I can have a look around?
You can use the form here:
https://eventespresso.com/send-login-details/
|
|
YCParks
|
January 20, 2022 at 9:32 am
Thanks! I’ve submitted that info for you.
|
|
YCParks
|
January 20, 2022 at 11:22 am
Hello again! When looking on staging I noticed that EE was generating a cookie called PHPSESSID. When EE was disabled that cookie was not generating. From there I found where EE was storing transaction data and matching up users with their session ids and found that the new session id that was created and stored in my cookie was not in any of those DB entries, so I believe that my session ID is fresh and unique to me.
I also checked the registrations table and searched for my session ids within the reg_session column and I’m not seeing any of my session ids.
Oddly enough, when I change my session ID to one from the reg_session column and refresh, the form clears. When I refresh again however, I see the previous registration info in the form that I was seeing before — so something within the plugin is incorrectly associating reg data with PHP sessions.
What this looks like: EE is matching up new sessions with old transaction data. It almost seems no matter what session ID we use, its still pulling in old registration data. It’s not an issue with any of our custom code, or our theme, or a plugin conflict, its something within the core registration plugin of EE.
|
|
Brent Christensen
|
January 20, 2022 at 1:05 pm
Hi there YCParks
I’m Event Espresso’s lead developer Brent.
Everything you are explaining sounds exactly like caching.
You are literally being served previously stored content. That is what caching does. Instead of generating new content, it serves up some previously generated content because that’s faster. Everybody swears up and down that caching is turned off on their sites, usually because the first tier support they are dealing with swears up and down that caching is turned off, but it is always caching. Please note that it is in your hosting company’s best interest to serve up cached content because that puts less strain on their systems and pocketbook.
We have seen this scenario play out many times before and it has always been some form of caching that was running. Your best bet is to contact your hosting company (again) but insist on having this issue elevated to the next level of support. Are you on a dedicated server, or VPS, or a generic shared server account (indistinguishable from VPS these days, since it IS a VPS but with super limited resources)? On any kind of cheaper VPS you can almost guarantee that the hosting company is going to be aggressively caching as much as possible to keep the resources used by any single VPS from affecting the performance of the other VPSs on that same server.
So again, this looks exactly like caching, and hosting companies will very often claim it’s not… but it is. I’m not a gambling man, but I would have no hesitation placing a bet on this being caching. Why? Because the number of other things that would have to be going wrong to cause the same thing is just astronomically unlikely.
Let’s walk through the process:
– so as you have discovered, when Event Espresso (EE) is active, a cookie is generated named PHPSESSID. This is all being done by PHP which is the scripting language that your server, and WordPress, and the vast majority of websites on the internet are being powered by. We simply call a function called session_start() and then retrieve the session ID, which is that number stored in the PHPSESSID cookie. Your browser stores the cookie on the computer and PHP uses it to track user actions across multiple requests (please note that this is NOT the kind of tracking that Facebook and other companies do where they send your data off somewhere to build a profile on your behaviours, this is simply the mechanism that PHP uses to chain multiple requests together so that things like online shopping carts work correctly). This session will remain active as long as you are active on the site, but will expire after a while, or if you close your browser down. This is why you did not find your current session ID in the database. If you register for an event and then go into the database you should find your session ID in there.
– once EE receives the PHPSESSID from the PHP session cookie, we use that ID to pull any previous session data from the database. This includes any transaction and registration data for any active checkout processes.
– If we find a record matching the PHPSESSID, we populate the checkout using that information so that the user can continue with the registration process.
Despite there being a LOT of code involved in the entire checkout process, connecting the session ID with a database record is really simple and straightforward. In order for that process to go wrong there would have to be one of the following situations occurring:
– a problem with cookies in general (would affect nearly 100% of the internet)
– a problem with PHP cookies (would affect like 75% of the internet)
– a problem with the MySQL database returning the wrong records (would affect… don’t know a percentage, but millions and millions of websites)
– a problem with the Event Espresso code for connecting a PHPSESSID to a database record (would affect other Event Espresso customers)
– some form of caching serving up previously generated content (would affect that ONE site, ie: would only affect your site)
This is why I said that despite being completely against gambling, I would bet that your problem is caching. In order for this issue to be occurring, either some totally crazy super rare and unlikely problem is happening… OR… your site is being cached, which is really really common (almost ALL servers utilize caching in one way or another) AND causes the EXACT issue you are experiencing. And again, your hosting company is definitely implementing multiple layers of caching within their infrastructure. They ALL do. In fact you would not want to be using a hosting company that uses zero caching of any kind because their servers would just not perform as well. The most likely problem here is that the first tier support at your hosting company does not know enough to solve this problem for you. Force them to elevate the issue and find the source of the caching and have it turned off.
If you want you can forward your cPanel login to us (please confirm this with Tony first, and NEVER post login credentials on the web, only do so via our secure submission process) then we can look through your VPS’s settings.
take care, hope this gets resolved quickly for you.
|
