Best way to pass customer session info from Javascript API to PHP API

Hi FoxyCart Team,
I'm specing out a system for a client and they would like to use the Javascript API for most of their site. That said, I would like to use the PHP API (the PHP api by Luke here: https://github.com/FoxyCart/foxyclient-php) to add custom fields from a custom order system. (Client wants absolute control of the ship_to address and wants to have auto fill at checkout. They also want the address synced between FoxyCart and our custom system.)

Let's say a customer starts their FoxyCart Session from the normal store, what's the best way to pass that information along to the PHP session from JS?

Also, let me know if I'm asking a stupid question. I'm just trying to solve a design issue.
Thanks,
Ryuhei
Tagged:
Comments
  • lukeluke FoxyCart Team
    Hello @Ryuhei. Can you help me understand what you mean as far as passing along the PHP session "from JS"? Can you walk me through, start to finish, what you're wanting to accomplish? Where is the user logged in, what data is passed to the cart, what data is manipulated via the hAPI, what happens after checkout, etc?

    That should be helpful for us to get on the same page.
  • RyuheiRyuhei Member
    Hi @luke
    Great. Here's a super generic, but hopefully helpful diagram.

    image



    The client has a custom order form that posts to our PHP serverside app.
    The serverside app is then used to print some materials required to make the product. Our client wants to have addresses stored on both sides (our app and the FC system).

    We're going to use multi-ship since each item is generally sent to a different recipient. When the user enters the address on the "Custom Order Form", we were hoping to send that data to the FC session custom fields via PHP. That address then would be reused in the FoxyCart checkout to pre-fill the address for that specific multi-ship. Does that make sense?

    In addition to the custom order system, they have other items on different parts of the website which require just the JS sessions.

    What I'm wondering is what happens when I initialize an FC session from both JS (from the client) and PHP (from the server)? They're not going to be the same session, so is there a preferred way to sync them?

    TL; DR
    I want to pass the custom address fields collected in the "custom order form" to the FC custom fields system from the serverside PHP. FC JS session and PHP server side sessions need to be in sync for this to work right?

    Thanks,
    Ryuhei
  • fc_adamfc_adam FoxyCart Team
    @Ryuhei,

    Just wanted to clarify something with you based on what you posted - do you need these custom values entered in the "custom order form" before the customer completes their order? Or just after the order is completed to print materials to make the product?
  • RyuheiRyuhei Member
    hi @fc_adam,
    That's a non-negotiable change in workflow. It would defeat the whole "fun" and investment that the user would put into the form if they were presented with a payment option before hand.

    Also, it would be out of the question to store the data in the FoxyCart custom fields for the entire form. The backend that they're using would have to be rewritten entirely if that were to be the case.
  • fc_adamfc_adam FoxyCart Team
    @Ryuhei,

    No worries. In that case, and based on your diagram - what I would suggest is using our single sign on functionality to prepopulate the customers cart with the information you have stored on your side. This would actually be via PHP rather than from javascript.

    The SSO endpoint is primarily for allowing you to synchronise logins from your own website to the FoxyCart checkout flow. You can however make use of it for whatever other purpose you need. In that instance, it becomes a way for you to execute code silently right before the customer proceeds to the checkout.

    Details on SSO here: http://wiki.foxycart.com/static/redirect/sso
  • RyuheiRyuhei Member
    Thanks @fc_adam,
    I'll look into the SSO based solution.
    I may just look into passing the FC Session ID also.
    I may come back during implementation with more questions.


  • RyuheiRyuhei Member
    @fc_adam,
    Since SSO seems to be the best method you've mentioned, I have a question about your example SSO endpoint redirect code here: https://wiki.foxycart.com/integration/php/shared_authentication_example

    So, I understand why you want me to use this code, but here's my conundrum....
    I also looked up how to make a user through the API and it makes sense...
    But, what if I don't want to collect a password? How do I store this user as a guest customer? Does SSO require us to have a login for the user? Most people coming through do not want to make an account.
  • fc_adamfc_adam FoxyCart Team
    @Ryuhei,

    SSO does rely on the customer having a user account. We do also have prepopulation where you pass in certain field names to be able to prepopulate the customer's address details. Unfortunately this doesn't work with multi-ship though, only working with straight billing/shipping fields.

    In order to pre-fill multiship addresses, the customer will need to have an account.
  • RyuheiRyuhei Member
    @fc_adam,
    Okay. So, SSO isn't the solution we're looking for.
    I guess if that's the case, I'll just make a REST API on my end that we can call from the checkout process.

    So, for reference, here's my new workflow:
    1. FC loader.js gives us a session id via cookies.
    2. Use FCSID, pass that along as the FC session value to our app
    3. At checkout on Foxycart, I'll place a JS on the checkout system which will make a call to our app (using FCSID and the assigned multi-ship name).
    4. Our app will respond with the address data as json
    5. The checkout form will pre-populate with said data.

    What do you think?

    Also, thank you so much for helping me and being patient. I really do appreciate your help!
  • brettbrett FoxyCart Team
    Hi @Ryuhei.
    Nice idea there. Sounds like you've got a pretty solid understanding of all the pieces you'd need.

    The one caveat: Our checkout has quite a bit going on, so if you see any strangeness with disappearing data (the values you insert), let us know. I don't think you'd run into issues with the approach you've described, but if you do, we can help you out pretty quickly. (Or if you're interested, take a look at the FC.json values after you enter things manually. When Twig re-renders things, it'll populate from the FC.json object. So if you have issues, just set the values in the FC.json in addition to setting them on the inputs themselves.)
  • RyuheiRyuhei Member
    @brett thanks for the note. I'll watch out with that.
    Most of the code I'm implementing won't use the defulat DOM objects (except the inputs) so I'm hoping there won't be much collision.
    If I come across stuff, I'll definitely get back to you! Thanks.
  • RyuheiRyuhei Member
    Hi @brett,
    I've started to implement the system and I've hit a road block.
    I have a question about FCSID. Does it change from the time you're shopping to the time you're in a checkout? (I'm picking up the FCSID from cookies FYI) I'm not sure if I did something wrong, but its not matching for me.

    Thanks,
    Ryuhei
  • RyuheiRyuhei Member
    @brett, actually, I figured this one out myself. All you have to do is to include the existing FCSID into the form or the link that you're dealing with. Solved!
    might look something like this in your field:

    <input name="fcsid" type="hidden" value="<?php echo $order->fcsid ?>">
  • RyuheiRyuhei Member
    @brett, now that I'm very close, the only thing that I'm having issues with is the zip code. I'm putting the values in via jQuery, but I can't really make the "GO" button do its thing (at guessing cities/states). I've tried to fake a focus/change on the input, but its not having any of it. Also, if I manually press the GO button, the value does disappear.

    I know you talked about setting values in the FC.json, but how can I do that before the checkout page renders? Any thoughts? (Am I supposed to set that value while I'm in the cart code?)

    Thanks,
    Ryuhei

    PS: I wrote two PHP libraries to simplify client cart modification (from the server side) and another one to handle the Transaction XML loading. I'll probably publish those once I'm finished with this project.
  • brettbrett FoxyCart Team
    @Ryuhei, can you whisper an example where we can take a look?

    If you're just talking about setting the zip code, can you clarify when / where you're trying to set it (serverside, clientside, at what step in the process)? You might be able to check the network tab to see the requests that are fired off when a zip code is entered (client side), and mirror that. But you also maybe could look at checkout prepopulation:
    https://wiki.foxycart.com/v/2.0/checkout#pre-populating_the_checkout_with_customer_information

    Sounds like you've made a ton of progress! Can't wait to see it in action.
  • RyuheiRyuhei Member
    @brett we're very very close. There is an issue left. It seems that the auto-city-state system guesses cities that actually don't exist. For example, for my office address' zip code 98122 it should guess "Seattle", but it gives us "East Union" (the street we're nearest). Can you tell me if there is a way around this one on the FoxyCart end?

    Thanks.
  • brettbrett FoxyCart Team
    Hi @Ryuhei.
    So sorry for the delayed response on this. We use Thomson Reuters data for that. Do you have others that are off? We'll log the problem with them and hopefully they'll get it fixed in next month's update.

    (That said, "East Union" does appear to be somewhat valid. USPS's system recommends not using it, but they know what it is if you put it in here: https://tools.usps.com/go/ZipLookupAction!input.action )
  • RyuheiRyuhei Member
    @brett Awesome. That does answer my question. I'll let you know if we find things that seem off.
    Thanks!
    Ryuhei
  • brettbrett FoxyCart Team
    @Ryuhei, quick update: We talked to the tax data provider and they've said they'll remove East Union:
    …we list all possible cities listed as an accepted city in each zip code, USPS has since rescinded that East Union is an accepted city for the zip code specified.
    Let us know if you find anything else and we'll bring it up with them :)
  • RyuheiRyuhei Member
    @brett
    Thanks for the update. We also found another problem with the client.

    He enters in 94710 (Berkeley) and he gets Albany. Since Albany and Berkeley share the zip code and the system automatically selects Albany (alphabetical) its kind of an issue. I do have the data on my end and know that the user entered Berkeley earlier. That said, there isn't a Javascript callback or a function that I can override so that I can modify the data at the right time (knowing that the city field is filled out).

    Is there a way to fix this? (BTW, I already tried setting the city via FC.json and that didn't pan out.)
    Thanks!
  • fc_adamfc_adam FoxyCart Team
    @Ryuhei,

    For any postcode that shares multiple possible city/state pairs - the user can select the desired option by clicking the dropdown for the city/state. After entering "94710", you can chose between both Albany and Berkeley.
  • @fc_adam, @brett

    We do have one lingering issue with the zip code lookup that we need some help sorting out. It's confusing our returning customers and they're unable to check out smoothly. Here's the situation...

    When a new customer (i.e., not registered with FC) moves through our custom ordering process, through the cart, and into the checkout page, everything works fine. We automatically input the zip code into each instance of the shipping form on the checkout page (via the method @Ryuhei discussed above). The zip code lookup automatically does its thing and presents the city match(es). All is well.

    The problem arises when the customer isn't new. If the customer's email, which we are also transferring directly into the checkout page (since we collect it earlier in the process) is a match in the FC system (i.e., they are registered), the page focus remains on Step 1 so that it can ask for a password. Simultaneously, further down the page, the zip code lookup(s) seem to be doing they're thing, but they always get stuck on "Loading..." and iterate over and over and never produce any results. If you delete the zip code and type it again and hit "Go," it then finds a match right away. But of course our customers just assume the server is down because all they see is "Loading..." and don't know to re-try it.

    How can we tweak our code to make sure the same exact zip code lookup process happens regardless of whether the customer's email address is already on file or not?

    You can reproduce this scenario by ordering something here with an FC-registered email address, and then proceeding to the checkout page: http://www.leafcutterdesigns.com/custom/orders/package
  • fc_adamfc_adam FoxyCart Team
    @Leafcutter,

    Interesting. We'll take a look.
  • fc_adamfc_adam FoxyCart Team
    @Leafcutter,

    Sorry for the delay - I just tried to replicate the error you described, but once I hit the checkout, while the password field is displaying, so is the city/state field and consequently the shipping options as well.

    Are you still experiencing this issue on your side?
  • @fc_adam, @brett

    Seems this issue has morphed a bit. Everything seems to be faster now (perhaps due to the migration) and we're no longer seeing the "Loading..." hang up. So that's good. What we're seeing now (that we never saw before) is that when we transfer multiple ship to addresses into the checkout page (via the method @Ryuhei discussed above) along with an email address that is already registered, only one shipping address is showing up on the checkout page. The other shipping address, which previously also populated just fine, is getting lost in the ether. You can replicate this via the same method discussed above but be sure to order two items shipping to two unique addresses with an email address already in the FC system.

    I tested this same multiship scenario with an email address not already registered, and both shipping addresses populated just fine. I also tested a single shipto scenario with a registered email address, and that also worked okay.

    Could this new problem be related to the migration? Either way, how do we fix this?
  • fc_adamfc_adam FoxyCart Team
    @Leafcutter,

    I just tested out your replication steps there - and using an email address for a customer that previously ordered, it prepopulated the address correctly for what I entered. If you're not seeing it being entered, you'll need to look into your custom javascript that is triggering that to see what may be happening.

    One thing I did see though was the postcode lookup remain in "loading" mode. Looking into the requests, I was able to see that the request did complete, but for some reason (possibly related to how you're filling in the information) it was stuck in that loading state.

    I manually triggered a rerender of the page by javascript, and it correctly displayed the found address.

    Perhaps that could be something you could try - triggering a rerender once your prefill is complete. That would look like this:

    FC.checkout.renderCustomerShipping()
  • @fc_adam,
    I do include that code in our javascript to re-render the shipping.
    Here's how the workflow goes for the javascript field population:

    1. Data is fetched from our server

    2. It is populated in the FC.json fields

    3. The Shopping information is re-rendered (The mentioned renderCustomShipping method)

    4. I catch the fact that the rendering is finished (using the "render.done" catch). At this point, I manually press the "Go" buttons to populate the city/state/region info since FC doesn't have a way to programmatically trigger that data fetch.
    This is when our problem happens (loading not stopping issue).

    BTW, by manually press the "Go" button (on step 4), I just trigger a jquery .change() method on the zip field. Do you guys have any way of triggering zip/city validation programmatically? It would solve this problem we're experiencing.
  • fc_adamfc_adam FoxyCart Team
    @Ryuhei,

    Try triggering it like this: jQuery("[name='shipping_postal_code']").trigger("input.fc.fc-postal-code");
  • @fc_adam,
    I'll try that and see if we can make it work.
    Thanks,
    Ryuhei
Sign In or Register to comment.