Support

September 23, 2020 at 4:32 am

Hi there,

What you are trying to do above sounds a little similar to how the Stripe payment method worked and it would simply hide the Finalize button when the Stripe payment method was selected and trigger a click on that element when it was done processing.

Your license has access to that add-on so I’d recommend taking a look in eea-stripe-gateway\scripts\espresso_stripe_onsite.js to see how it handles this.

Thank you for sharing your payment method and whilst you haven’t asked for feedback I did some quick testing with your payment method so I’ll add my notes here should you wish to take them on board.

When you initially activate the payment method it will break any registrations attempting to take place on the site as there will be no public key set, so THIS breaks check out completely. That might not seem like an issue but we’ve seen in the past that people will activate payment methods, realize they don’t have credentials and go off to find them meaning during that time registrations are blocked on their site with your PM. The text displayed doesn’t give any indication that it is from the payment method and the registrant wouldn’t be able to change it either way. Right now it will kill the stript on the attendee information step, like this:

https://monosnap.com/file/3oVTubI9iAnhWxEI93adf221rZnnu1

All I’ve done there is select some tickets after the PM was activated. So I recommend switching that out to simply display a message in the payment form when someone selects the payment method.

—

A bigger issue is that your JS still runs after the user has selected a different payment method if they’ve selected yours at all. So say you have this payment method and Invoice enabled, on the payment options select this PM and select Invoice, once Invoice has loaded click to Finalize:

https://monosnap.com/file/gipRMVdt3FBxiCRrmlylmeF72wzqwt

You JS is still running and prevents me from finalizing. If you take the same path the Stripe payment method uses you’ll see how we prevent that within the add-on.

November 2, 2020 at 1:14 pm

Does this address the issues mentioned in your feedback?

The changes do indeed fix the issues I mentioned.

Do you have any other suggestions or feedback?

I haven’t tested the payment method any further than activating it and adding some dummy values to the settings, I assume the payments work as expected?

Is this something Event Espresso can add as a supported payment method?

We wouldn’t add a payment method we didn’t create and test ourselves into Event Espresso’s core payment methods but we can add you to the list of 3rd party repo’s if preferred?

https://eventespresso.com/third-party-addons/

—

I’d like to ask a question outside of Event Espresso if I may?

I’m curious as to what the benefit is with your current GitHub repo setup vs using say master as ‘release’ with feature branches and automated Github releases? Right now, unless I’m mistaken it looks like you manually zip up a release and include it in the /release directory and if that’s so, I’m guessing there’s some setup I’m missing and just curious what benefit it gives.

The reason I’m asking is I can’t just check out your repo and clone it locally to view it as a plugin, I need to manually change the working tree to your the directory in your /src/ directory or extract the zip and install it.

November 5, 2020 at 3:19 am

Yes, that would be great if you’d add it to the third party addons.

Sure, I’ve created a ticket for this.

I just created a release in that github repo. I just do things a little differently sometimes for time saving sakes.

Sorry to clarify, it’s not just creating releases within Github as that release is exactly the same as your current repo and can’t be used as-is. It has the /src/ and /release/ directories within a release zip meaning it still requires you extract the correct zip etc.

To show an example of a different setup that makes it much quicker for other developers to collaborate with yours, take a look at our waitlist add-on repo:

https://github.com/eventespresso/eea-wait-lists

The root directory of that repo is essentially your /scr/event-espresso-4-secure-submit/ directory, there’s no need to separate src/release as GitHub does it for you with releases. Or (and for me this is the main advantage) the repo can simply be cloned into a directory (which by default will be the repo name) in /wp-content/plugins/ and used as is with no additional effort changing the working directory within git etc.

You’re obviously free to set up your repo however you prefer, I was just wondering if I/we were missing something with a different setup that we could then investigate.