Preload text tags for product attributes in variant related fields

[SkyLundy]

What
This changes the behavior of how text tags are rendered for product variant fields. Rather than load variant tags using AJAX on input, the tags are loaded as options and rendered on page load making them available when clicking on the field.

Why
I'm not sure if pre-rendering was previously considered but this solves two issues that I encountered.

Variants become unusable when the name of the attribute is shorter than 3 characters or is 3 characters and one is a non-alphanumeric character. An example is length such as 12"
image

The second field will not populate even if a correct value such as 12" is entered, it will blank on loss of focus.

Values such as 12", 20", 30", etc. could never be accessed when configuring variations for a product because the value of 10 is shorter than the 3 letter AJAX cutoff and (some? all?) non-alphanumeric characters are stripped for the AJAX request.

The second improvement that this brings is making is easier to use variants that have many options. I found myself forgetting the names of some the variants so I had to reference the configuration page. It's also possible to not be aware of all of the variants because the user may not be familiar with the shop, or has never seen the variants before. In the case of the lengths example, it would be easy to intend to add all lengths as variations but not typing all of the needed characters, i.e. typing 10", 12", 20", but forgetting or not being aware of 30" so those are never seen by the user.

What Changed
Pre-rendering the tags on page load, disabling AJAX in the InputfieldTextTags config for attribute options, and updating the method name to reflect the new behavior.

Additional Considerations
I'm not sure if this makes the AJAX endpoint located in PwCommerceHooks::hookFindPWCommerceProductAttributesOptions() unnecessary so that was kept as is.

Result

[SkyLundy]

@kongondo Is there a preferred way of submitting PRs? Should there be an issue opened first?

I'm working through setting up a shop so if I see something I can help out with during the course of my work I'd be able to contribute.

[kongondo]

Hi @SkyLundy . This is a great addition, thanks! I'll review and merge.

[kongondo]

@kongondo Is there a preferred way of submitting PRs? Should there be an issue opened first?

I'm working through setting up a shop so if I see something I can help out with during the course of my work I'd be able to contribute.

Hi. Would be great if an issue was opened first - tagged as a bug or a new feature.

Secondly, PRs should be made against the dev branch and not main.

Thanks for willingness to contribute!

[SkyLundy]

@kongondo No problem! I wasn't clear on what you'd prefer but wanted to get the ball rolling while I had the code ready.

If you can create a CONTRIBUTING.md document for the repo that describes what you outlined above and any other requirements/recommendations that you would like to have contributors adhere to that would be great.

If you'd like to set a precedent for the repo I can close this without a merge and create a new PR that follows the steps you mentioned. All up to you.

Also if it saves some time, an issue template. I tried to cobble a descriptive format together in this PR, but you could get what you want faster if there's something to follow.

Thanks for open-sourcing the module!