|
Trojan
|
January 25, 2021 at 12:50 pm
We are getting an error when checking people in on the app – “Error Occurred: Requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible”.
Please advise.
Dann
|
|
Tony
|
January 25, 2021 at 1:29 pm
Hi there,
Can you please run through the steps related to this on the troubleshooting section here:
https://eventespresso.com/wiki/ee4-event-apps/#troubleshooting
I’d like to capture the requests being sent to and from the server to see if anything stands out there if that’s ok? To do so I’ll need temp login credentials I can use in the app which you can send using this form:
https://eventespresso.com/send-login-details/
|
|
Trojan
|
January 25, 2021 at 2:05 pm
For clarity, as the event author, I am not able to check someone in and my role is Administrator (for the whole site). We have installed the Members plugin – are you asking that we create all those roles in the troubleshooting guide or does the event admin have all those privileges by default. Setting you up with admin so you can see. FYI – the ee_edit_checkin is not on the available permissions list.
|
|
Tony
|
January 25, 2021 at 2:22 pm
We have installed the Members plugin – are you asking that we create all those roles in the troubleshooting guide or does the event admin have all those privileges by default
No, there’s a specific section for the error you reported on the link, just follow those steps.
Confirm the URL you entered into the app an flush permalinks.
During testing, just use an administrator account as admins have full access. Testing other roles can be done once we know the admin account works if needed.
|
|
Tony
|
January 25, 2021 at 3:12 pm
Hmm, ok. So the problem is due to the requests being sent to HTTP and then redirected to HTTPS. Doing so is fine for GET requests (the app pulling data IN), but not POST requests (the app sending data to your site, like a checking) which is why your not getting this on every request.
To explain a little, when you input your domain into the app, it sends a HEAD request to the site using HTTP to see if the request is redirected. On your site, it is, but then the HTTP requests are all still valid and the app continues to send the requests to HTTP.
Generally, that HEAD request tells the app to use HTTPS for the requests that follow but for some reason with your set up that’s not happening.
Do you have any code on the site used to ‘clean up’ the site headers? The difference between requests on your server and mine is the REST API request headers have been removed from the response.
|
|
Trojan
|
January 25, 2021 at 3:26 pm
Went through the troubleshooting steps and we are on EE 4.10.10 and WordPress 5.6. We reset the permalinks and we still get the same error.
We are logging in as http://trojansafety.com (we only enter trojansafety.com) and with my admin username and password.
Anything else we can try?
|
|
Trojan
|
January 25, 2021 at 3:31 pm
We have a 301 redirect going from HTTP to https. Should we remove that – their previous site was not https. Their new site, that we built, is https with event espresso.
|
|
Trojan
|
January 25, 2021 at 3:44 pm
Not sure if this is related but some users are getting this error “Your form data could not be applied to any valid registrations…” This also happens to us sometimes when we are trying to register people. any thoughts?
|
|
Trojan
|
January 25, 2021 at 8:25 pm
How much of a delay is there between someone registering and their registration showing up in the app?
|
|
Tony
|
January 26, 2021 at 5:29 am
We are logging in as http://trojansafety.com (we only enter trojansafety.com) and with my admin username and password.
How do you know you are logging via http? If you mean you are not entering https into the URL field, that’s correct. Don’t include the URL schema in that section as the app should work that out for you, unfortunately, that’s exactly what is failing with your setup, although I can’t see why.
Your site is not trojansafety.com, its http://www.trojansafety.com and I can see all of the requests being directed there (including the requests in the app).
We have a 301 redirect going from HTTP to https. Should we remove that – their previous site was not https. Their new site, that we built, is https with event espresso.
The 301 is fine, its what I have set up on my site.
Do you have any code on the site used to ‘clean up’ the site headers? The difference between requests on your server and mine is the REST API request headers have been removed from the response.
Not sure if this is related but some users are getting this error “Your form data could not be applied to any valid registrations…” This also happens to us sometimes when we are trying to register people. any thoughts?
Hmm, that’s usually a caching error, or something on your site is clearing transients.
If you add a registration and then stop on the attendee information page, wait say 10 minutes and just refresh, does it show an error?
How much of a delay is there between someone registering and their registration showing up in the app?
None, its live data. You may need to swipe down to refresh the cache though.
|
|
Trojan
|
January 26, 2021 at 9:21 am
No matter what I enter for the URL, https, HTTP, or just trojansafety.com, the app shows http://trojansafety.com/ when I try to log out and then login in again. No matter which way I login, I still get the error when checking someone in. I deleted and then reinstalled the app but that made no difference either.
Is the REST API header an issue – can you tell me specifically what you need us to do?
In the app, is there a way to see the person’s registration form details – specifically the comments field?
|
|
Trojan
|
January 26, 2021 at 9:47 am
We have some people that are paying by invoice where they will be billed later via an accounting system. The transaction status shows incomplete. Does that status affect anything in EE – can we have it default to a complete or paid status automatically?
|
|
Tony
|
January 26, 2021 at 10:13 am
Is the REST API header an issue – can you tell me specifically what you need us to do?
It is an issue, but I can’t say if it causes the current issue with the app as it’s not something I can reproduce on my servers.
As far as what you need to do, I don’t know what code you have running on the site so I can’t tell you specifics although you’re looking for code like this:
// Disable REST API link tag
remove_action('wp_head', 'rest_output_link_wp_head', 10);
// Disable oEmbed Discovery Links
remove_action('wp_head', 'wp_oembed_add_discovery_links', 10);
// Disable REST API link in HTTP headers
remove_action('template_redirect', 'rest_output_link_header', 11, 0);
If you are removing those actions, comment the above on your site and retest. The app communicates with your site using the REST API, it uses the above headers to confirm the URL. I think it would be strange for this to cause the error mentioned but it’s the only difference I can see on the login request.
In the app, is there a way to see the person’s registration form details – specifically the comments field?
Not currently, the app doesn’t pull in registration questions, I’m assuming ‘Comments’ is a custom question you’ve added to the registration form?
|
|
Trojan
|
January 26, 2021 at 10:50 am
I will try your suggestion. Are you able to check someone in (trojansafety.com) with the app without getting the error?
Yes, the comments is a custom question. What about a link to the person registration info – that would be helpful. Also, would be great to show the company name too. Our client has multiple attendees from the same company coming to their courses.
|
|
Tony
|
January 26, 2021 at 11:39 am
I will try your suggestion. Are you able to check someone in (trojansafety.com) with the app without getting the error?
No, I get the same error you are getting on your site but I can’t reproduce the same issue on any of my sites to troubleshoot on.
Yes, the comments is a custom question. What about a link to the person registration info – that would be helpful. Also, would be great to show the company name too. Our client has multiple attendees from the same company coming to their courses.
Currently, you can’t add additional fields to the mobile apps without changing the code within the app itself. I can add the above feedback to our roadmap but either way it’s not something you can add into the app with a snippet unfortunately.
|
|
Trojan
|
January 26, 2021 at 2:56 pm
Anything else we can try?
We did switch from our staging server (not secure) to the live server (https) last Friday. We never did try to check anyone in on the staging server.
Hoping to get to the bottom of this. What are the next steps?
|
|
Trojan
|
January 26, 2021 at 3:51 pm
Hi Tony
We keep getting this warning on our server. Suggestions?
2021-01-26 17:38:09 Warning 99.199.70.123
mod_fcgid: stderr: PHP Warning: session_start(): open(/var/lib/php/session/sess_f94t8h19avfrflj91libei07kl, O_RDWR) failed: Permission denied (13) in /var/www/vhosts/wowbrandingweb.com/trojansafety.com/wp-content/plugins/event-espresso-core-reg/core/services/session/SessionStartHandler.php on line 65, referer: https://www.trojansafety.com/registration-checkout/?uts=1611700610
Apache error
2021-01-26 17:38:09 Warning 99.199.70.123
mod_fcgid: stderr: PHP Warning: session_start(): Failed to read session data: files (path: /var/lib/php/session) in /var/www/vhosts/wowbrandingweb.com/trojansafety.com/wp-content/plugins/event-espresso-core-reg/core/services/session/SessionStartHandler.php on line 65, referer: https://www.trojansafety.com/registration-checkout/?uts=1611700610
Apache error
These two warnings on our logs keep on repeating.
|
|
Tony
|
January 27, 2021 at 4:30 am
Anything else we can try?
Did you remove the code I mentioned above to include the headers on the request?
I see you’ve removed the 301 redirect and I can now check registrants in if I use your full domain when logging into the app – www.trojansafety.com
Adding the URL schema also forces the login to use https if you set it – https://www.trojansafety.com
The strange part is the app can usually work all of this out on it’s own but something specific to your set up is preventing it from doing so, although what that is I can tell right now.
PHP Warning: session_start(): open(/var/lib/php/session/{session}, O_RDWR) failed: Permission denied (13)
Looks like apache doesn’t have access to sessions and that will be why checkout fails with the error from earlier (“Your form data could not be applied to any valid registrations…”). Why yo are only getting that for some users an not other I’m not sure but you’ll need to contact your host and have them fix the above, it a config issue rather than an EE issue.
Your site needs access to create and read sessions for EE to work.
|
|
Trojan
|
January 27, 2021 at 5:18 pm
wait – are you saying you can now check people in by login in with http://www.trojansafety.com? I just tried it and it did not work for me.
Our host tells us that they cannot replicate the PHP warning – it appears that warning is no longer happening.
I just retried login in with the https and I can check people in.
I really need to understand what happened – our client is nervous about the reliability of the system and I want them to love Event Espresso.
|
|
Tony
|
January 28, 2021 at 4:58 am
wait – are you saying you can now check people in by login in with http://www.trojansafety.com? I just tried it and it did not work for me.
Yes, at the time HTTP was working if you use the full domain – www.trojansafety.com
There was no 301 redirect happening at the time and check-in/out worked with that setup.
However, if is test that now, it does not work and I can see there is a 301 set up again (Note I’m using Fiddler which is a debugging proxy that captures all traffic to/from my devices so I can view the requests)
I just retried login in with the https and I can check people in.
Yeah, I can see it works if I use https://www.trojansafety.com as the URL set in the app.
I really need to understand what happened – our client is nervous about the reliability of the system and I want them to love Event Espresso.
Just to be clear, I haven’t changed anything on your site when testing this. It looks like the issue here is/was indeed due to the 301 redirect, but it’s a little odd.
When you use trojansafety.com in the app’s URL field what should (and does for other sites) happen is the app works out the URL it should use from there. It does this by sending a HEAD request to the URL you provide and then monitors what happens to that request, if its redirected to HTTPS and/or www. it follows that redirect and then uses the ‘new’ URL for any subsequent requests but it doesn’t on your server.
I can show you an example of this from within Fiddler, on your site, when you connect with trojansafety.com this happens:
https://monosnap.com/file/U7O7FxYLh3HJwJ7YYEJRfa9sdwVV4p
As you can see trojansafety.com is checked and it does indeed redirect the request to https://www.trojansafety.com however the apps then continue to use trojansafety.com.
The above is ‘fine’ (although not ideal) got GET requests (GET requests retain their ‘data’ when 301’d) but it simply can not work for POST requests (which is what the check-in/out request is) as POST requests DO NOT retain data when redirected, they switch to a GET request with no POST data.
If I use https://www.trojansafety.com within the app, the same HEAD request happens but because we are already using the ‘correct’ URL in the app, any subsequent requests then also use the correct URL and are no longer 301’d.
Again, from Fiddler:
https://monosnap.com/file/6JerLLyHjisjJmkcANokmEetLmbbkV
The top section is the original login requests and the request to pull in the events etc, all exactly the same as before only no redirect needed.
The bottom section is me checking in and out my registration, they work because they aren’t redirected.
This is what happens when I test check-in/out with just using trojansafety.com in the app:
https://monosnap.com/file/Sr6nPolM3FjK3GdgCBqGVMoy8kewuW
The first request is the POST request to check the registrant in, that’s then 301’d to https://www., as mentioned above the POST data is removed and it switches to a GET request, which is why check-in/out breaks.
So that’s the ‘why it happens’ on the app, but right now I can’t tell you what the cause of the behaviour is. The only difference I can see between the 2 HEAD requests from your server and when I do the same testing on mine, is your HEAD request does NOT return the REST link headers I asked you about earlier.
Example from your site:
https://monosnap.com/file/hlkyfDHlhyflEgykuezoSB7OXZ6PtS
From one of my servers:
https://monosnap.com/file/fWGVimD972X9AyD6CRyExMY07gWYjz
I’ve obviously blurred the domain out on my requests but the domain isn’t important, the headers are.
|
|
Trojan
|
January 28, 2021 at 11:44 am
Thank you – seems to be working fine now.
One more thing: Where can we find a list of registrations that have chosen to pay by invoice – is there a report or an export that we can generate?
Does EE have a way of handling the invoice option – our client needs to bill them from their accounting system. Please advise if there is a recommended workflow.
|
|
Tony
|
January 28, 2021 at 2:09 pm
For invoices, you have a couple of options and it depends on how you want them to work.
When a user registers and selects Invoice within Event Espresso, what do you want to happen at that point?
You can set the Default Payment Status of your events to be ‘Approved’, however, note that will Approve ALL registrations that finalize regalrdess of payment status so you would then need to monitor those.
Or, if you only want registrations that selected Invoice to also apply to your sold values, you can manually update those to be ‘Approved’.
|
|
Trojan
|
January 28, 2021 at 2:58 pm
This reply has been marked as private.
|
|
Tony
|
January 28, 2021 at 3:03 pm
1. Clients that choose to pay by invoice usually are booking for multiple people, so we are looking where we can find a list of registrations (vs attendees) for the courses we are selling. Does a list exist?
No, we don’t have a list of registrations that specifically chose the Invoice payment method.
However, if you use a Default Registration Status of Approved, it is possible (via a code snippet) to add an additional filter on the registration list so that you can filter by Registration Status and also Transaction Status.
For example, selecting ‘Approved’ registrations with an Incomplete transaction status (a TXN Status of ‘Incomplete’ simply means the monies paid into that transaction is less than the monies owed).
Will that work for you?
|
