Hey there,
Sorry we missed your email!
We have discovered the source of this and should have a fix out by the end of today.
Just to confirm, this can happen if frontend caching is in place. Do you know if that is the code for you? After the fix frontend caching shouldn’t be a problem.
Thread Starter
jaspin
(@jaspin)
I do have fastCGI caching set up. I went ahead and disabled it but that didn’t solve the issue. I’ll keep an eye out for that update and mark this as resolved once I can confirm that it takes care of the issue. Thanks!
Thread Starter
jaspin
(@jaspin)
Just wanted to check in and see how that fix was coming along. Thank you!
@jaspin We just pushed out the update which should fix this for you! You can find it in your WordPress admin dashboard under “Dashboard” > “Updates”.
Let me know how it goes for you!
Thread Starter
jaspin
(@jaspin)
Just a had a chance to test it out. Now I’m just receiving error code “values_missing” with the message “Values were missing. Please try again.”.
Any suggestions for me? Thank you for your help so far!
@jaspin That’s strange!
We are running the same version on https://churchtithewp.com and aren’t seeing that issue anywhere in our tests! Are you able to send a link to your website where Church Tithe WP is set up so I can take a look?
Thread Starter
jaspin
(@jaspin)
@jaspin I can’t seem to find the page where Church Tithe WP is set up! Do you know if it is currently unpublished? If so, you can privately email the URL to that page to us at support@churchtithewp.com
Ah I was able to locate it in your popup at the bottom of the page.
I am seeing a few strange things happening. One of those is that the request is coded to be a POST request, but on your site it is being run as a GET request. That means that the POST body is being stripped out before it is executed, and thus none of the values are being passed to the endpoint! That is why it is returning that “values_missing” response.
Do you know if you have any plugins installed that might modify the way javascript is executed, or modify the way javascript ajax calls are carried out?
Digging further, it looks like there might be some kind of redirection happening on your server, which is stripping that out. This was an issue that I found online that seems like it might be related:
https://github.com/postmanlabs/postman-app-support/issues/450#issuecomment-50894350
To clarify, the redirection I am seeing appears to be going from:
https://hmcworship.com/
to
https://hmcworship.com/wp
Thread Starter
jaspin
(@jaspin)
Hm. I’m using a wordpress boilerplate called Bedrock. It puts static core wp files in their own /wp directory. I didn’t even realize this could be an issue but I just read through the documentation and found this list of common issues. Is it possible that the plugin has hardcoded some file structure assumptions in?
Thank you again for all of your help!!
Interesting! We do not hardcore any file structure assumptions no. Rather, we localize the URLs for all ajax calls using wp_localize_script and pass in the proper URL as set in your WP site settings. I checked the localized variable on your page for the AJAX URL, and it is correctly pointing to https://hmcworship.com/wp/, so that helps to show that it is not making any file structure assumptions.
But the issue isn’t about your AJAX calls getting a 404, which a hardcoded path assumption would typically cause in a situation like this.
Rather, something is converting the AJAX/Fetch call from a “POST” to a “GET” which is stripping out all of the payload variables.
I was not able to find that on the bedrock site anywhere, but it might be worth reaching out to them to ask why a POST request using javascript fetch might get converted to be a GET response, with the payload stripped out.
One thing to try as well is to deactivate all other plugins temporarily, to see if any of them might be causing this change. It being Bedrock could still be unrelated to that POST/GET swap.
I also wonder if your server is set to listen on port 80 (http) but is redirecting all requests to 443 (https).
What is your WordPress address set to in your WP admin dashboard under:
– “Dashboard” > “General” > “WordPress Address (URL)”
– “Dashboard” > “General” > “Site Address (URL)”
Do those begin with “http” or “https”?
I am seeing some people talking about browsers doing this conversion. A couple of people mentioned that a browser will convert a POST to a GET during http->https redirection, but only if there is a trailing slash.
I would like to attempt removing that to see if it resolves the issue for you.
Do you mind emailing us again so I can send you a temporary zip of the plugin to test that?
support@churchtithewp.com
