Maintaining Custom Field SELECT Values after Twig.js template re-render

According to Maintaining Custom Field Values in FoxyCart 2.0, Twig.js template re-rendering can cause Custom Checkout Fields to lose their values prior to checking out. This is exactly what I am facing, specifically with HTML <select> menu.

Is there any reason a select menu example is not included with the others on the wiki? I presumed syntax similar to the Checkbox/Radio examples would work for <select>, but that doesn't seem to be the case.

Here's what I've tried:
<select name="Example_Select" id="Example_Select" class="fc-form-control" formnovalidate="" autofocus="" aria-required="false">
<option value="ABC" {% if Example_Select == "ABC" %}selected{% endif %}>ABC</option>
<option value="XYZ" {% if Example_Select == "XYZ" %}selected{% endif %}>XYZ</option>
</select>
Is there anything wrong with this approach, or perhaps something I am missing?
Comments
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Your approach there is perfect - there is in fact a bug on our side that is preventing the select elements from saving correctly into the JSON. I've created a ticket to get that fixed as soon as possible. For now, would you be able to use a set of radio inputs instead?
  • Good to know, thanks Adam. I will see what I can do. Appreciate you filing the ticket on my behalf.
  • pixelchutespixelchutes Member
    edited January 2015
    FYI, the temporary work-around you provided for manually setting FC.json[this.name] = this.value; during select onchange helps the custom values survive render(), however the issue I am facing now is when there is an error during processing, such as a payment gateway error, the page reloads and the custom fields have lost their values.

    Any thoughts on how to resolve this?

    From what I can tell, it seems the hidden fields do not start out in the JSON as 'h:custom_field_1', but rather "'custom_field_1" with "is_hidden: 1" However, after erroneous submit, they are changed to 'h:custom_field_1' in FC.json, oddly with is_hidden: "0" ?
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Could you clarify your set up here? Are you passing a hidden session variable with an add to cart, and then displaying that in a custom field on your checkout as well? I want to make sure I understand your set up.
  • pixelchutespixelchutes Member
    edited January 2015
    Yes, pre-populating a custom field (h: hidden) included in the cart add. It's not required during the Add to Cart, but if a value is provided, need it to remain populated on Checkout load, render(), payment fail, etc.

    It must be hidden since don't want it included on the Receipt or Email. I have it mostly working, but being in a <select> is adding complications due to the aforementioned bug.
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    So you're wanting to allow the customer to change that value on the checkout as well? Or are you just wanting it to persist from the add to cart through to the final transaction?
  • pixelchutespixelchutes Member
    edited January 2015
    Change it as well. They may not provide a value on the first page, but if so, have another chance to modify their response.

    I think the main problem right now is the "failed payment / page reload" scenario. Everything else seems to be working as discussed.
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    The issue you're running into as part of this is the add to cart hidden session variable is a different type of value to the hidden checkout field - so I think that's why you're seeing the is:hidden value mess up after submitting the checkout. You are setting it to be a hidden value - so I'll look into why that's not maintaining - but I'd recommend for now sticking with just one of the inputs (as in either from just the add to cart or just as a custom field on the checkout) - if you do that it should get you working.
  • So are you saying that a Custom Field on the Checkout page named "h:custom_hidden_1" would not be hidden from Receipt / Email the same was as a similarly named field passed in via Add to Cart?

    FYI, I was able to work around the issue persisting values during a "failed payment" scenario by adding the following check: {% if ( key == "custom_hidden_1" ) or ( key == "h:custom_hidden_1" ) %}
    {% if custom_hidden_1 is not defined %}
    {% set custom_hidden_1 = "" %}
    {% for key, custom_field in custom_fields %}
    {% if ( key == "custom_hidden_1" ) or ( key == "h:custom_hidden_1" ) %}
    {% set custom_hidden_1 = custom_field.value %}
    {% endif %}
    {% endfor %}
    {% endif %}
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Not quite - prepending it with "h:" will still hide it from the email - but a hidden checkout field is different to a session attribute handled within an add to cart. It will be evident by having 2 copies of that "custom_hidden_1" value against the transaction.
  • fc_adamfc_adam FoxyCart Team
    @pixelchutes,

    Quick update - we have a fix rolled out to production to ensure that select values are properly tracked. Thanks for bringing it to our attention.
  • Thank you, fantastic news. Look forward to testing.
Sign In or Register to comment.