fix: Accommodate CiviCRM's desire for perk options by implementing faux...
fix: Accommodate CiviCRM's desire for perk options by implementing faux singleton-options for no-option perks
As documented in #132 (comment 3091502) and https://gitlab.torproject.org/tpo/web/civicrm/-/issues/162, there is a bug somewhere in the handshake process between donate-neo and CiviCRM in which perk items which are not intended to have selectable options (such as "t-shirt size") are not being detected by CiviCRM as being selected - presumably because they are not passing along an option SKU, merely the perk ID itself.
While this should eventually be addressed in a more holistic manner, the imminent launch of YEC2024 demands a quick solution, and so this MR represents a solution that is implementable with only the code available in donate-neo (e.g., the code I have write access to).
This MR adds a single option to no-option perks, with a related SKU. This SKU should be reflected in CiviCRM by adding a single option listing in the "Options" textarea. For example, the sticker pack has been given a fake option labeled "Sticker" with the SKU STI-CKR-00; ergo, in this perk's CiviCRM listing, the "Options" textarea contains the text STI-CKR-00=Sticker. (This is how perk options and their SKUs are arranged to match for perks containing more than one option as well.)
When donate-neo is rendering the donation form, it will probe option groups to see whether they contain only a single perk. If so, a hidden input field is added to the page (literally, <input type="hidden" />), whose value is the SKU, and which has the "disabled" attribute set. The "else" clause of this test will render the fuller option group as a drop-down <select> list, as normal.
There is already a Javascript method, togglePerks(), which hides and shows option lists based on the selected perk. (E.g., when a t-shirt is selected, its drop-down <select> list will be shown; otherwise, its selected option will be cleared and the <select> list will be hidden once more.) This method has been extended to additionally add or remove the "disabled" attribute from these hidden input fields, which has the effect of including or excluding them from form data sent to and processed by the backend.