Uppercase JSON cannot be parsed

As usual, immediately after posting the issue, I find the bug. The issue is ParserBase->executeSources(). Will debug further.

Ok, so here's a tentative fix for this. This makes the JSON property names case-sensitive by using $source['value'] instead of $source['machine_name'].

However, this bug is not limited to JSON; I noticed that one of my Feeds Tamper plugins has a workaround for CSV names as well. So I think that perhaps the use of machine names rather than the value should be changed globally.

Thanks for finding the bug (although I haven't tried to reproduce it yet). I remember I had made a change to the CSV parser in Feeds for a similar issue in the past, but there was a reason that I needed to revert that fix.

Anyway, it would be useful to have test coverage here.

I don't remember all the details anymore, but it was this issue that I reverted later: #2997951: Custom mapping source should use value as item getter instead of machine name? → .

It is failing tests, so it at least needs work. Although I'm not certain (because it was long ago), I would think #2997951: Custom mapping source should use value as item getter instead of machine name? → and #3015786-8: Changes for latest dev version of Feeds → contain useful information for dealing with this issue.

Thank you for the links; those are helpful.

I agree this needs tests. I'm having a little trouble with debugging the tests in ddev at the moment, so once I get that figured out, I'll try to fix this.

I think it would be good to test both lowerCamelCase and snake_case JSON properties, since those are the two common ways to write JSON property names.

Added tests, but I still need to fix the existing tests. I'm having trouble figuring out what is wrong.

Another problem: even with this fix, if you map the Feeds item (feeds_item): Item GUID to a lowerCamelCase property, it will fail (the property is not read). Setting it to an all lowercase property name does work.

So it seems the item GUID is read differently than other properties, and perhaps should be tested separately.

Another issue with the current MR is that the Mapping UI displays the machine name if the casing differs from the input name.

For example,

metaDescription (metadescription)

This is probably to indicate that the () value must be used (because Feeds doesn't currently handling casing), but in this case, since the MR adds support for casing, it is confusing to show the machine name and it should be removed.

And another problem: My testing was all through Feeds Tamper, where this MR helps out.

But if you map a field and do not tamper it, even with this MR, Feeds will expect lowercase, not uppercase.

TL;DR: This is going to be a hard problem to fix, so for now, I suggest putting a clear message on the project page: Uppercase characters are not currently supported in JSON keys (for example, { "uppercaseDoesNotWorkHere": "You can use uppercase here" }).