Fix for Commerce token population

[aheathgr]

This fixes #52 where tokens weren't populating on Orders.

hook_tokens() takes a $data array of objects, and the code checks to see if $type is present in the array.

In Drupal 7, the $data array often had multiple keys. The ones supplied by the Rules module, for example, have dashed keys, e.g. my-entity. The ones supplied by the Salesforce Suite module had underscores, e.g. my_entity. The Drupal 7 code worked because both keys were available in the $data array.

In Backdrop, $data only contains one array, and we were encountering mismatches of dashes and underscores. As a result, Commerce code was exiting early instead of replacing our tokens with the expected values, because it wasn't finding the type it was expecting in the $data array to begin with.

This commit updates Commerce to check for both dashed and underscored versions of the type when looking for the correct entity type in $data.

It also fixes a bug with chained tokens: first, a strucutral fix so that the switch code will run, and second, an issue with an array union: the module was setting the default owner field value to "name", and even when that value got set via token_replace(), the array union (+=) was clobbering the new value with the default name value.

[aheathgr]

@argiepiano Hey there! Remember when you mentioned you had been in the weeds with tokens? Here's a pull request we'd love your eyes on, in case you have any additional thoughts. Thanks in advance!

[Simon85-2]

Attention: Opinion of an amateur

Concerning the first part of the fix:
This seems to be a very specific case where the problem occurs.

I never had any issues with tokens when using a standard commerce system + some additional commerce modules (partly via Coder Upgrade) + rules.

Also looking in "Browse available tokens", I can only see tokens with dashed keys (including all commerce keys).

Wouldn’t it be better to make the changes in the root cause — the Salesforce Suite?
Or to modify the general Backdrop Tokens system so that it only accepts dashed keys for example?

[argiepiano]

I have to agree with @Simon85-2. Entity tokens in Backdrop (by default, and unlike D7) uses lower underscores, BUT (important BUT), it can also take the dashes syntax, even though they are not documented. This decision was made by a previous maintainer of Entity Tokens (to unify token syntax), and it did create issues like the ones you are describing, specifically with field tokens (e.g. date fields) when token fulfillment was provided by both, core, and Entity Tokens, and the fulfillment resulted in clashes (array returned instead of a value). Those issues were fixed within Entity Tokens on individual cases.

Rules has two ways of entering data: one is through the Data Selection widget, where Rules shows dashes (this method doesn't use the token system). The other is Direct Input mode, where you are supposed to type the actual token. This is probably where the problem with double entries for tokens happen.

While I haven't looked at the PR here, @Simon85-2 comment makes me think that your PR is actually removing all the tokens with underscore syntax.

My suggestion is to find a different way to avoid those clashes with Salesforce tokens.

I will look at the PR more closely and try to provide alternatives. This will take me about a month.

In the meantime, I'm still seeing many tests failing, which is alarming. I would suggest fixing those tests before continuing to make changes to Commerce.

[aheathgr]

Howdy! Thank you both for your thoughts!

First - context being important, and not evident from this one PR - I'm with Giant Rabbit, the team working on the alpha release for this module. We've been holding that release until we get a few last updates committed, and one of the top priorities is getting those tests resolving. (We're close! There's just one last one test with VAT taxes that's proving stubborn, but we'll get there.) To be clear, the testing errors have all related to syntax updates associated with the shift from Drupal to Backdrop, and PRs like this one are not coming back clean when we run test in an environment that includes our fixes to the tests.

Additionally, to be clear, this PR actually doesn't touch the tokens themselves (e.g. commerce-owner).

Rather, it addresses an inconsistency with the entity type name of the object containing those tokens. We're seeing both commerce-order and commerce_order passed along to hook_tokens() as the entity type name in the $data array. Previously, the code was just checking for the dashed version (commerce-order) before running token replacements, and it meant that the underscored version wouldn't get considered at all, resulting in blank tokens.

This wasn't an issue in Drupal because both versions of the entity type name were always present in the $data array that was passed to hook_tokens(). (For the record, our guess is that Drupal was making all entity type tokens, from all modules, available at any given time, and that Backdrop is handling this more efficiently.)

Our suggested update checks first for the dashed version of the entity type, and then checks for an underscored version as a fallback. This should ensure compatibility with both the underscored and dashed versions of the entity name, restoring what the behavior was in Drupal. (We considered trying to make the update to the Salesforce Suite module, as that's another one of the modules we ported, but we're still not sure whether that's the only other module employing the underscored version of the entity name or not.)

We welcome any thoughts and ideas about this, and appreciate anything you want to share. (I'll add that it feels like the safest route to take in the interim as we prepare this alpha release.)

Thanks in advance!

[elisseck]

This description does make sense to me, looking at the PR involved. Because it has been rebased on top of my branch where automated tests started passing (fails were for unrelated reasons), and they're still passing... I'm going to merge this.