Start a discussion on custom booking flow

[jonathan-dejong]

Hi!

My client has requested that we look into the possibility to create a completely custom booking/checkout flow. It's a bit insane but we'll research is and see if it would be possible.

I was wondering wether I could discuss this with you pro devs that actually created EE! Here's an rough example of the flow they want: https://www.dropbox.com/s/5b2mplgc2706bl4/shop.html?dl=0

I know it's an insane task and it will take long time.. :/ Basically.. the question is. Would it be possible to use your hooks and functions to still have the bookings save through EE as regular registrations etc. even tho we build the entire frontend ourselves?

What are the pitfalls? What tips can you give? Is there a better way to think?

VERY grateful for any information/feedback :)

[nerrad]

Hi jonathan, just want to make sure you know that the EE repo is public on github in case what you shared isn't intended to be publicly accessible.

Short answer, building your own entire frontend is certainly doable. But not easy. You may want to wait until we get our REST API complete (with write access etc) because that will make it much easier to implement a custom front-end. @mnelson4 can comment more to that.

[jonathan-dejong]

Hi Darren,

Thanks. That's not an issue since it's just a mockup with dummy-content :)

The REST API does sound like it'd be pretty sweet and I've had a look at it before but as you say it did not seem to suppose any posting. I'd love to hear more about that! Do you have a roadmap or something one can see or a timeline for the improvements to REST API?

And let's for arguments sake say we can't use or can't wait for the REST API?

[nerrad]

Jonathan I trust you understand that its not as simple as saying, "use this hook" and "use this hook" and you'll get what you'll want. I can say that you can build a custom frontend and have it totally replace our checkout process using the code in EE. But to actually tell you how to do that is not something we can take time to do right now.

So to answer this question:

Would it be possible to use your hooks and functions to still have the bookings save through EE as regular registrations etc. even tho we build the entire frontend ourselves?

If you build the entire frontend yourselves, you won't really be utilizing any existing hooks in our checkout, but instead using the classes and methods exposed in those classes to replace our checkout. The only hooks you would need to concern yourself with are any do_action hooks that the messages system utilizes to send the appropriate notifications (assuming you still want the messages system to send notifications).

What are the pitfalls? What tips can you give? Is there a better way to think?

Those questions are too general at this point in your scope. We can't really answer with anything useful because we don't know the approach you intend to take and the scope of your project. The rough example of your flow doesn't really help anymore with that either other than illustrating you want to have a custom frontend ;)

Sorry I can't be more help @jonathan-dejong. It sounds like an exciting project but at this point your queries are too general to help us be specific in our answers. I'll leave this open in case any of our other team members want to chime in.

[jonathan-dejong]

I completely understand Darren :)

It is a bit of a shot in the dark and all I really wanted was a yes/no to the question wether it would be possible. It's great to get nuggets like looking out for the do_action hooks you talk about.

If and when I take this on I may ask more specific questions which I hope will be alright. I'll look forward to @mnelson4 chiming in on the REST API

Do you have a roadmap or something one can see or a timeline for the improvements to REST API?

Thank you very much Darren

[mnelson4]

I'm actually working on integrating the EE4 REST API into EE4 core, and then putting basic write functionality into it. However at least initially it will require authentication before you can write anything to do the database. That means that only site admins will be able to register folks, not just anyone (which is currently the case with SPCO). So would you want only admins to sign folks up? Or would you want anyone to be able to register themselves (without previously having an account on the site) using this system?

[jonathan-dejong]

Since (for us) it would replace the entire front-end of EE we'd need anyone to be able to write/sign up.. However I'm thinking that it should be possible to circumvent this by actually doing the writing as an administrator if it's possible to authenticate manually. Hope I'm being clear :)

So the REST API would have to be able to write to a new registration with all that entails (multiple tickets, multiple registrants for a single registration etc.). I realize this might be asking a lot but Ooooooh how I would love to be able to work towards your API instead of drowning in internal php classes etc.

[mnelson4]

if it's possible to authenticate manually

seeing how the EE4 API is built on top of the Wordpress REST API that might be more of an issue to explore with them. If that doesn't work out you could do some server-side tweaking to allow certain requests through.

So while I expect to have authenticated write access available soon (as in the next few weeks or possibly months), having UN-authenticated write access has a lot more uncertainty involved. But it's good to know someone would use if it were developed.

[tn3rb]

@jonathan-dejong

I don't mean to let any wind out of your sails, but considering the EE API doesn't yet currently have any write capabilities, and surely won't have complex enough write capabilities to handle the entire checkout and registration process anytime soon (although I could be wrong)... I think you may have to learn to navigate your way through the internal PHP classes to do what you are proposing.

So that said, in order to replace the entire frontend, the first thing you are going to have to do is deregister most, if not all, of the existing EE shortcodes, modules, and widgets so that you can replace them with your own. This can be done via the following hooks:

• 'FHEEEE_Config__register_shortcodesshortcodes_to_register'
• 'FHEEEE_Config__register_modulesmodules_to_register'
• 'FHEEEE_Config__register_widgetswidgets_to_register'

We also use a custom post type endpoint to route requests to the /events/ page, which you may want to change to point to something else. This can be done simply via the admin on the Event Espresso - Events > Template page. Or you may also want to remove that endpoint completely via the 'FHEEEE_Register_CPTsget_CPTs__cpts' filter, although I'm not sure off the top of my head what chaos that may cause, so proceed with caution.

Next, you'll basically just want to create your own modules, and use EE_Config::register_route() to route requests to the appropriate module. So for example, the current Single_Page_Checkout module registers some routes (dynamically) like:

EE_Config::register_route( 'attendee_information', 'EED_Single_Page_Checkout', 'run', 'step' );

to route any requests to:

domin.com/?step=attendee_information

to the EED_Single_Page_Checkout::run() method.

You can also use custom permalink rewrite rules to make your custom actions look a little nicer (see: https://codex.wordpress.org/Rewrite_API/add_rewrite_rule).

From there, you will need to basically query for any of the event / venue / datetime / ticket information that you need, as well as anything to do with the registration form questions, and display that however you are planning to do so. The bulk of your work is going to be in displaying the queried information and then processing submitted form data. To do the latter, you will basically have to create the following (possibly incomplete list of) object records:

• 1 transaction
• 1 registration for each ticket unit purchased
• 1 attendee record for each unique new person as determined by the reg form details
• 1 answer record for each registration form question OTHER than those associated directly with the attendee (first name, last name, email, etc) which get saved to the attendee meta
• corresponding line item records for the transaction, and tickets
• 1 payment record for each attempted payment

Please look at the single_page_checkout module and all o fit's registration step classes to see what I have done. Those are some pretty big nasty monolithic classes to dig through, but your code won't have to be as complicated because yours will surely just have to do things the one way you want it to, as opposed to having to accommodate thousands of customers wishes. Please note, that you may also need to hide any controls in the admin that are for controlling functionality on the frontend if they are rendered useless by your changes.

You will also need to employ the EE_Payment_Processor class unless you plan on processing payments directly via your own gateways.

With regards to triggering notifications, the business logic for deciding when to send messages can be extremely tricky depending on what your criteria is for determining that, but the actual process for triggering is pretty simple. We use the following "filter switches" to turn notices on or off:

// to turn notices ON
add_filter( 'FHEE__EED_Messages___maybe_registration__deliver_notifications', '__return_true', 10 );
// or OFF
add_filter( 'FHEE__EED_Messages___maybe_registration__deliver_notifications', '__return_false', 15 );

and the following action to send the registration details to the messages system:

'AHEE__EE_Registration_Processor__trigger_registration_update_notifications'

You may be able to get away with using a lot of the methods in the EE_Transaction_Processor and EE_Registration_Processor classes for doing a lot of the data processing that needs to happen at the end of the checkout process.

Anyways, hope that helps get you started. Should keep you busy for the next 6-9 months at least.

[jonathan-dejong]

@tn3rb Thank you! I am now equally fascinated and horrified ;) What percentage of truth vs gag is in this? :fearful:

Should keep you busy for the next 6-9 months at least.

I'm doing this all as a research-step and am going to have to present a timeframe later this month. Your estimate is probably a lot better than mine that's why I'm asking.

Luckily they won't need any sort of payment processing as they do that completely internally in a different system. I'm actually using this snippet to deregister the payment step:

//Completely remove the payment options stage of EE checkout
function jf_ee_remove_payment_step( $reg_steps ) {
    foreach( $reg_steps as $step => $value ){
        if( $value['slug'] == 'payment_options' ) {
            unset( $reg_steps[$step] );
        }
    }
    return $reg_steps;
}
add_filter ( 'AHEE__SPCO__load_reg_steps__reg_steps_to_load', 'jf_ee_remove_payment_step' );

They're not using any widgets or shortcodes either so I guess all my focus will be on the modules.

[tn3rb]

I wouldn't put much value on my time estimate because I am unaware of the extent of your plans nor your coding style (fast n loose vs slow and cautious). It's possible somebody could produce a "functioning" frontend in a few months, whereas a well planned and tested UX with significant security and defensive programming measures taken would take much much longer.

When you say you are "deregister the payment step" using the 'AHEESPCOload_reg_steps__reg_steps_to_load' filter, I'm assuming that's what you are doing now for the client correct?

Based on the simple mock-up you provided earlier, I think you would need to bypass the Single Page Checkout (SPCO) altogether, because your mock-up included ticket selection on the same page as the reg form. SPCO assumes that tickets have already been added to the EE_Cart via a Ticket Selector embedded on an Event Post single or archive page, so it's logic may not work with what you are planning. I'm assuming your client's site is for a big yearly event and doesn't require an "event list" nor anything like Multiple Event Registration.

... actually... you could potentially still use SPCO by inserting a new reg step as the first step, and process the ticket selection during that step, that way you could still use the existing attendee information step (possibly) or even a heavily modified copy of it. Assuming your client's site is hosting only ever hosting one site, then you can get away with knowing what the registration form questions will be, since there will only ever be one event per year (event hard the event ID as a constant at the top of your controller class).

So when someone clicks to "Register", you take them to the registration page, allow your version of SPCO to create a Transaction and 1 Registration object, then process the ticket selection during your first reg step (submitted via AJAX) and modify the existing registration object with the newly acquired ticket info. then process the registration form questions using the attendee info step, then finalize.

So it may be possible to modify the existing SPCO module to do what you want, but I can't foresee off the top of my head what kinds of problems you might run into. It may be easier in the long run to simply build your own controller module from scratch and run your logic blocks in their own sub classes like the reg step classes I have, but yours wouldn't even have to function as steps.

[jonathan-dejong]

Puh okay this is a lot of information to take in! I'm very grateful for your insight @tn3rb

Yes we're currently disabling/removing the final payment step through that code and they will not have any payment in our custom solution. I would say I'm a fairly cautious coder but not necessarily slow.. this is however a bit out of my comfort zone as I have not built something so extensive with controller modules and classes/subclasses. I'm sure that if you think it'd take a few months then that's a modest estimate of what it'd take for me if I do everything up to par.

For arguments sake.. is it possible to just skip all SPCO and simply keep a custom frontend which runs queries to post data to the ee_ tables as needed? Or are there internal things that need to occur with these modules that makes direct posting to DB impossible? I'm asking this because one of the clients are somewhat technical and I know he'll make my life hard and ask why we can't just do this and be done within a month or two.. sigh

[tn3rb]

@jonathan-dejong

is it possible to just skip all SPCO and simply keep a custom frontend which runs queries to post data to the ee_ tables as needed?

ya absolutely. That was the assumption I made when writing my first response where I listed a bunch of object records that you would need to create ( 1 transaction, 1 registration, etc ).

are there internal things that need to occur with these modules that makes direct posting to DB impossible?

no shouldn't be. All of the appropriate model classes should be loaded for you by the time your module runs, so to create a new transaction you can simply do something like:

EE_Transaction::new_instance(
    array(
        'TXN_timestamp'     => time(),
        'TXN_total'         => $cart_total,
        'TXN_paid'      => 0,
    )
);

one of the clients are somewhat technical and I know he'll make my life hard and ask why we can't just do this and be done within a month or two..

I guess if the client was more than "somewhat technical" then they would understand why you can't just spit out several thousand lines of code out and expect it to work perfectly.

The SPCO module has over 9,000 lines of code in it and the Ticket Selector has nearly 2,000. So not including the event display, you will be writing a replacement for 11,000 or so lines of code. That said, you probably don't need to write anywhere near that amount because your code won't need to be as flexible as ours, because you have a single use case you are targeting.

[jonathan-dejong]

My guess is that if we go ahead with this I won't get the time to do it properly but rather we'd end up with something like the above where we just post to the DB.

I'm pretty sure regardless of what I do it'll be at least 5 000 lines of code. As you say the client hits that "sweet spot" where he knows to request things but not how horrible it'll be for me to do it ;)

I'm also going to look into what they actually need/use in EE and how difficult it'd be to build a custom solution for them. Since there are quite a bit that they don't need (like payments, CRM/contacts etc.). I'm sure it would take at least as long as customizing EE but that way I'd at least be sure things wont break each time we do an update :)

Puh..

Huge thank you @tn3rb @nerrad and @mnelson4 ! I'll likely pester you again.. Have a nice day!