churchtithewp

Hey there,

Thank you for the detailed response! We have fixed this and it will be available in the next update, which will be later this week. Postal-Codes/Zip-Codes will no longer be required, unless the card has a zip code attached. This is determined on a card-by-card basis on the fly, powered by Stripe.

Hey there,

Prepaid cards should definitely work. I assume that your pre-paid card does not have a postal-code/zip attached to it, which is why the field did not appear. Were you unable to purchase without the zip code? If so, do you mind sharing the error message you got when purchase was attempted?

Hey Josh,

If you log into your Stripe account, you can go to “Developers” > “Webhooks”, and look at the response of one of the “payment_intent” webhooks. If there was an error, it should show there.

Apologies for this! I am wondering if it is a similar issue to your other issue, with the server redirects causing something unusual. If you’re able to find that I think we can track it down for you.

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?

[email protected]

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”?

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.

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.

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

• This reply was modified 4 years, 8 months ago by churchtithewp.

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?

@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 [email protected]

@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?

@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!

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.

Hey Jaspin,

Sorry to hear you are having this issue.

My first thought is that there might be another plugin causing an error during the same process.

The way it works like that when you make a change, it automatically attempts to push that change to your database in the background. It does that using something called “AJAX”.

During that AJAX event, all of your plugins are running (not just Church Tithe WP). If one of them is outputting an error, it can result in the response from your server not being when the AJAX call expects, and then our system will show that “unsaved” label, because we can’t be sure it was saved.

You mentioned that you checked in the console, which is great. One thing you can do to confirm this is flipping from the “console” tab to the “network” tab, and then make a change to one of the fields so that it says “unsaved”. You should see the AJAX call appear in the network list of events. If you click on it, you can check the “response” to see what it says. If there’s an error message there, it will point us to the cause!

P.S. If that was confusing and you’d like us to help you out more hands-on, you can create a user account for us with the email [email protected], and we can log in to to a look for you! Once this is resolved you can delete that user account to remove our access again.

Glad to hear it!