Discount code: allow to use the section outside the "edd_checkout_form_wrap"

[dashkevych]

Enhancement Request

Currently, the discount code only works if it's located inside the edd_checkout_form_wrap container: https://github.com/easydigitaldownloads/easy-digital-downloads/blob/e79a1a607d87632d730aff1cd26bb4faae6b23fe/assets/js/edd-checkout-global.js#L55

If it's moved to a different location then the discount code does not apply to the total amount.

The discount code is wrapped within its own container: edd_discount_code. Would it be possible to use edd_discount_code instead of edd_checkout_form_wrap ?

Justification or use case

There are some cases when the user might move the discount code section. For example, it can be moved to the checkout cart form:

[amdrew]

For a 2 column checkout layout (https://github.com/SellBirdHQ/theme-store/issues/58) I've repositioned the discount code field outside of #edd_checkout_form_wrap. Because of this, the discount field no longer works like the above explanation.

I agree that we should not be targeting #edd_checkout_form_wrap as it limits the position of the discount code field.

Few options:

1. Target .edd-discount-code-field-wrap instead which is the closest parent div to the .edd-apply-discount input.

2. Target the closest parent element of the .edd-apply-discount input without specifying a class.

3. Target the .edd-apply-discount input itself without targeting a parent first. I personally don't see an issue with this so probably my preferred approach unless there's a reason why we specifically need to target a parent element first.

An example for 3 above:

Before:

(Replaced the $checkout_form_wrap variable with #edd_checkout_form_wrap for clarity)

$('#edd_checkout_form_wrap').on('click', '.edd-apply-discount', apply_discount); // Prevent the checkout form from submitting when hitting Enter in the discount field

After:

$('.edd-apply-discount').on('click', apply_discount); // Prevent the checkout form from submitting when hitting Enter in the discount field

[cklosowski]

I could see that being useful. I think the main reason it's targeted that way is so much of our checkout is driven by that ID as the parent of the entire checkout.

I don't think there is too much risk in loosing up the targeting here as long as we don't change a necessary class that exists for the functionality.

[spencerfinnell]

This has gotten me before too. Would love to see this change.