Add optional query display name

[chriszarate]

Queries do not currently accept a display name, but I believe a display name will be useful in the future. Asking for it now (optionally) might pay off in the future.

[github-actions]

Test this PR in WordPress Playground.

[ingeniumed]

Thoughts around making it mandatory? That way we don't need to worry about fallbacks, and it does force users to think about the purpose of the query.

This'll make some of the code I added in #530 redundant which is great as we shouldn't be generating that name ideally.

[chriszarate]

It's a breaking change. That's the main reason I made it nullable.

[ingeniumed]

That's a fair point, and I think I have a solution from it. We can leverage the migration framework that'll be introduced in #530 to generate the display name in the same way that the PR does already. That way, the nullable could be dropped while not breaking anything already existing.

This can happen in a follow up PR

[ingeniumed]

Never been so eager to review a PR such as this one

[pkevan]

I don't know if this has been thought about yet, but how are we planning to use internationalization within the plugin?

I guess display name is an easy one to start with, although if the input is via a user then maybe that isn't important to them, but it might be for end users if it's display somewhere user facing.

[chriszarate]

I don't know if this has been thought about yet, but how are we planning to use internationalization within the plugin?

We've thought about it a little:

1. For plugin code, we make an effort to localize our own strings with a consistent text domain. It undoubtedly needs attention and improvements.
2. By design, we ask plugins users to define their configuration at runtime (e.g., register_remote_data_block( /* big configuration blob */ ), so they are free to localize strings within that config, including display names and other user-facing content.
3. For data returned from remote data sources, I don't know if we have a strong opinion. Internationalized APIs might be controlled by parameters that could be adjusted at runtime (e.g., via a filter) depending on the user's location or language preference. Or plugin users could use generate to perform localization themselves. I don't know if there is a strong need for it.

[pkevan]

I don't know if this has been thought about yet, but how are we planning to use internationalization within the plugin?

We've thought about it a little:

1. For plugin code, we make an effort to localize our own strings with a consistent text domain. It undoubtedly needs attention and improvements.
2. By design, we ask plugins users to define their configuration at runtime (e.g., register_remote_data_block( /* big configuration blob */ ), so they are free to localize strings within that config, including display names and other user-facing content.
3. For data returned from remote data sources, I don't know if we have a strong opinion. Internationalized APIs might be controlled by parameters that could be adjusted at runtime (e.g., via a filter) depending on the user's location or language preference. Or plugin users could use generate to perform localization themselves. I don't know if there is a strong need for it.

Thanks! That makes sense - I wonder if we should provide an example of this?

I'm more thinking around the use-case whereby the plugin is configured across many sites (maybe not via the plugin itself but some mu-plugin code), and these sites have different languages - we should help them in these scenarios somehow.

[chriszarate]

I wonder if we should provide an example of this?

I'm more thinking around the use-case whereby the plugin is configured across many sites (maybe not via the plugin itself but some mu-plugin code), and these sites have different languages - we should help them in these scenarios somehow.

I think 1 and 2 should solve for this, with some additional effort. I created VIPCMS-1316 to track this