Expose catalog configuration data as a new info query type.

[zetlen]

Description (*)

Exposure of catalog configuration data as a catalogInfo query type.

Expected behavior (*)

The data whose defaults are set in Magento_Catalog/etc/config.xml and whose overrides can be set in the database should be available for query, in order to configure, build, and deploy Progressive Web Apps which honor that configuration.

Benefits

Unlike most other PWAs, PWA Studio and Venia aim to be as controllable by the Magento 2 admin UI as possible. If the administrator sets a new default for any of these fields, a PWA should do its best to honor that. Most of the time, that requires making a large query to the store instance while rendering the PWA, so things like pagination defaults and URL suffixes can be built into the runtime.

Additional information

This issue came up when the PWA team examined how to treat URL suffixes for SEO-friendly catalog URLs. Initially, we simply hardcoded the standard .html extension to check for pages which we need to dynamically route with a GraphQL query to urlResolver. There are two problems with that:

• CMS pages and other custom pages need not have the .html extension
• The actual extension is configurable by the administrator in Configuration > Catalog > Search Engine Optimization > Category URL Suffix / Product URL Suffix.

Therefore, we need to be able to access this through some API. If the information is privileged, then we can begin using authentication over GraphQL if necessary and doing the call on the server side alone.

Relevant issues:
magento/pwa-studio#936
magento/pwa-studio#1029

[VitaliyBoyko]

Hi @zetlen
The functionality to get configs has been implemented within type StoreConfig (basic implementation and usage see here #182).
Could you please define which exact configs you need? So we can add them.
Thank you!

[zetlen]

@VitaliyBoyko As we implement features in Venia, we try to use store configuration instead of hardcoding things, so that Magento admins can control their PWA display as much as possible. Therefore, we may eventually use everything inside the <catalog /> element.

If you can make a single change that exposes all of those values, we would like that. None of them are sensitive; they all drive frontend behavior. Could we just put all of them into the storeConfig type?

Maybe that's hard to do, or it's a bad idea to expose all these values at once. In that case, we'll ask for config values to be exposed one by one. For the use case I described in this ticket, we would need product_url_suffix and category_url_sufffix.

[VitaliyBoyko]

Hi @zetlen
We don't want to expose all elements within some node (as <catalog />) due to possible security issues. Therefore we add only needed configs on demand.
@naydav @paliarush Correct me if I'm wrong.

I will add product_url_suffix and category_url_sufffix as soon as I can.

Thank you!

[zetlen]

OK, thank you! For additional admin configurability, may I please request that you add all of the elements that are currently present in the <frontend /> and <seo /> elements? Those all appear to values that are safe to publicly expose, and they would enable admin control of the frontend.

[naydav]

#650