Convert hyphens to underscores for jinja variable syntax

[kurtrwall]

Any data that needs to be accessed in jinja2 is through a named variable that holds that data. The naming syntax of jinja2 does not allow hyphens. This takes any variable named with a hyphen and converts the hyphen into underscores.

@dpford @Scotchester @willbarton

[Scotchester]

I think we should probably do this, but I'm curious, what currently happens if there's a hyphenated name in the JSON output? We simply can't access it in Jinja?

[kurtrwall]

That's right. To test, try to replace an image with the consumer-stories image size. It should be something like post.thumbnail.images.consumer-stories.url. It won't work.

[Scotchester]

So this change shouldn't break anything already in place, correct?

[kurtrwall]

No because it's only looking for hyphens and replacing those with underscores. The only code that accesses those variables by the hyphened name doesn't access it through the wp-json-api plugin so we're safe on that front.

[Scotchester]

👍 I just noticed that the README includes a line stating the current stable version. This seems unnecessary, given the version number in the main PHP file and the tags/releases. Can you please remove that README line in this PR?

Let's make this and #5 (when that gets updated to use maybe_unserialize()) 1.1.5.

[Scotchester]

Just ran into a place where this would be useful. Gonna go ahead and merge so I can update it in my UnityBox WordPress.

[Scotchester]

This only applies to images? We need this to apply to all custom fields.

[Scotchester]

Also, any particular reason why str_replace wouldn't work?

[KimberlyMunoz]

This may be silly, but would using brackets instead of dot notation be helpful here?

images.consumer-stories.url -> images['consumer-stories']['url']

[Scotchester]

I think that works, but I do love the simplicity of the dot notation...

Are you implicitly arguing for not forcibly converting them? I can see the argument for that. "Either don't use them when you define your keys, or deal with bracket notation."

[Scotchester]

P.S.: I have a working modification to fix the custom field names running locally.

[KimberlyMunoz]

Actually, I didn't know if there was a reason why we couldn't use bracket notation that I hadn't seen yet.

I'm a little hesitant about forcibly converting, especially in cases where something like contact-us and contact_us could both exist and cause an error that would be difficult to debug later. But if it makes things easier for developers and we have a check for similar slugs, it's probably fine and I don't have any ideological objections to it.

[Scotchester]

Could probably use opinions from other FEWDs that have worked with WordPress data in Sheer. /cc @virginiacc @cfarm @jimmynotjim @sebworks @anselmbradford @himedlooff

[kurtrwall]

@KimberlyMunoz makes a good point about the bracket notation, though I share the same sentiment as @Scotchester about the dot notation.

To be clear, this PR came out of a choice in Wordpress to use the post-thumbnail built in image size. The name could not be changed so I created this PR to deal with it. Now that we aren't using that built in image size name, there is no direct need for it from me at this point.

str_replace would work just fine in this case, and it should probably be used instead.

[Scotchester]

I guess I'm coming around to not doing this. People can either avoid hyphens, or deal with the bracket notation.

[kurtrwall]

Do we want to revert the PR then?

[Scotchester]

Yeah, I think we do. @KimberlyMunoz, what do you think?

[KimberlyMunoz]

I think so. If we're going to revert, better to do it quick before things get built on it.