|
t3accounts@wichita.edu
|
March 20, 2017 at 1:58 pm
I am having an issue with the EE 4 App for Iphone. What is happening is that the check-in/check-out status is not being correctly displayed (basically alot of yellow where there should be green and vice verse). The issue only seems to occur when a person is checked in or out via the attendee list. The list will confirm that a person has been checked in/out and will correctly display the checked in/out symbol until you exit the app or refresh the Attendee list in some way. After a refresh of the list the status will revert to whatever it was before you made the change and then give an error if you try to check that person in/out again. The app was initially having the same issue with android until I disable SG Super Cache, after which point it works fine. I am using EE 4 with WP 4.7.3 and the Avada theme. If anyone has any idea why this issue is occurring, the help would be greatly appreciated.
|
|
Josh
|
March 21, 2017 at 2:34 pm
Hi there,
It sounds like it’s related to the caching. Maybe the caching plugin can be configured to not cache requests to the WP REST API endpoints for Event Espresso?
|
|
t3accounts@wichita.edu
|
March 21, 2017 at 3:12 pm
Thanks for the reply. While it does seem to be a caching issue, it doesn’t appear to be the SG Super Cache, as I have that plugin deactivated and have cleared every cache I could find.
|
|
Josh
|
March 22, 2017 at 9:01 am
Simply deactivating a caching plugin doesn’t always disable the caching. What will happen is a caching plugin will add a constant to the wp-config.php file to activate caching and caching can still happen even if you deactivate the caching happen. You can also check the mu-plugins folder for a caching plugin, those don’t get deactivated from the WP plugins page.
|
|
t3accounts@wichita.edu
|
March 22, 2017 at 1:10 pm
Actually I just realized I was mistaken about the name of the plugin. It is actually SG Optimizer. I looked for remnants of the plugin in relation to your previous post however there was nothing in wp-config.php, nothing in htaccess, and I couldn’t even find the mu-plugins folder (however I am certain that SG Optimizer is not a mu-plugin, and there are no other caching plugins on this site). If the issue isn’t caching, what would be the next most likely culprit?
|
|
t3accounts@wichita.edu
|
March 22, 2017 at 2:08 pm
We tested on the Android app and that is working without any issues. Looking at Android and iOS Apps side by side, it seems the iOS app has some issues that need to be fixed. After login on iOS App, the registration information is not refreshed until the view is changed from default to any of the other 3 views at the bottom – alpha desc or numberic asc and desc. Even on those view, the checkin info is not refreshed. This is frustrating as we picked this plugin and shared checkin functionality info with client – only to find out now that its not working out of box for iOS environment. We host on Siteground and its super cacher is disabled. We also are not using any other caching plugin on this website. Please look into this issue and provide specific resolution that we can try.
|
|
Josh
|
March 23, 2017 at 9:44 am
Can you post some screenshots that show what you’re trying to describe?
You can host the images somewhere an post the links here, we have some options posted here:
https://eventespresso.com/wiki/troubleshooting-checklist/#screenshots
|
|
t3accounts@wichita.edu
|
March 23, 2017 at 1:24 pm
Here is the link to a word doc with screenshots that should help paint a picture of the issue.
http://dev.tthree.org/wits/wp-content/uploads/2017/03/Android-vs-IOS-issues.docx
|
|
Josh
|
March 23, 2017 at 3:16 pm
The WP REST API responses can be cached, which may be what’s happening there. I wonder what would happen if we sent a REST API request outside of the app for that same attendee list, if it would send the older attendee list or the current? If you can complete the secure form on this page:
https://eventespresso.com/send-login-details/
someone from EE staff can try sending a request via the REST API to the registrations endpoint and investigate further.
|
|
t3accounts@wichita.edu
|
March 23, 2017 at 3:52 pm
Alright I have sent the form.
|
|
Josh
|
March 24, 2017 at 9:24 am
Hi there,
I added a REST API loggging plugin to your website so we can see the actual API requests from the apps, and from using the Postman client.
One of the odd things we saw was on your server an API request for the registration list would result in there being 2 logged requests. Normally there should only be one.
There’s one request logged when I send a request for the registration list via Postman.
The two requests from the Android app were identical.
With iOS, the first request contained all of the registration info along with the current check in value. Here’s an excerpt of the data from the first request. The second logged request contains only one registration in its data. Here’s an excerpt of that request data.
When we compare by testing our dev servers, the apps are only logging one request, there’s no missing data, and the apps function as expected. This is the case with both the iOS app and the Android app.
So this raises a few questions: Why two Requests instead of one when the apps request registration lists from your server? Why does the second request only have one registration?
Also, is the server you’re testing on right now going to be the same server that you’ll use for production?
|
|
t3accounts@wichita.edu
|
March 24, 2017 at 11:19 am
Thanks for your debugging efforts. This dev website is hosted on Siteground which is a decent hosting company. You guys had some survey done in 2015 and had Siteground on the top of the list. Production website will be also on Siteground as well.
The 2 requests question – We wish we have more insight into it – it seems more on your developers end to answer that. We tried even a cleaner test instance out of the box with nothing in it and only event espresso. Android App works ok there as well but iOS App gave same issues. It seems Android App is much more polished, functional and have error handling (for e.g. multiple checkin scanning) as we tested registration functionality further.
We are going to recommend to client to use Android App only. Are there any other options at this point you want us to try out?
|
|
Josh
|
March 24, 2017 at 11:33 am
We haven’t seen this issue happen on other sites that are hosted on Siteground. Can you put a site on the server that’s going to host the production site?
|
