Incorrect root categories when extending includeFields

[themreza]

Current behavior

These are the default included fields for ElasticSearch category queries, as defined in the default.config file:

"includeFields": [ "id", "*.children_data.id", "*.id", "children_count", "sku", "name", "is_active", "parent_id", "level", "url_key", "url_path", "product_count", "path", "position"]

According to these fields, only the id field of each category's children_data should be loaded.

In my project I needed to implement a desktop menu which required more information in children_data, namely children_data.name and children_data.url_path.

I extended includeFields to [ "id", "children_data.id", "children_data.name", "children_data.url_path" ,"*.children_data.id", "*.children_data.name", "*.children_data.url_path", "*.id", "children_count", "sku", "name", "is_active", "parent_id", "level", "url_key", "url_path", "product_count", "path", "position"].

ElasticSearch now provided the extra fields, but the root categories suddenly disappeared in Vue Storefront. After digging through the code, I found the problem to be in the CATEGORY_UPD_CATEGORIES mutation.

When the new categories are retrieved from ElasticSearch, there is a loop going through children_data and creating slug fields recursively if the children_data.name field exists.

Responsible line: https://github.com/DivanteLtd/vue-storefront/blob/master/core/modules/catalog/store/category/mutations.ts#L25

Which uses https://github.com/DivanteLtd/vue-storefront/blob/f3c218d7a202718915d13a87f09ee57a04396c0b/core/modules/catalog/helpers/slugifyCategories.ts#L21

This problem only exists in v1.11.0+. I switched to the old slug creation code and it works. So that's where the bug is.

Old slug creation code: https://github.com/DivanteLtd/vue-storefront/blob/hotfix/v1.10.6/core/modules/catalog/store/category/mutations.ts#L21

Expected behavior

Steps to reproduce the issue

Repository

Can you handle fixing this bug by yourself?

• YES
• NO

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

• Browser:
• OS:
• Node:
• Code Version:

Additional information

[pkarw]

Thanks! @gibkigonzo can you fix this by first chance?

[Michal-Dziedzinski]

Hi @themreza, Wouldn't extend includeFields to [ "id" ,"*.children_data.id", "*.children_data.name", "*.children_data.url_path", "*.id", "children_count", "sku", "name", "is_active", "parent_id", "level", "url_key", "url_path", "product_count", "path", "position"] be enough for your needs? Removing extra fields without asterisk allows you to display categories correctly.

[themreza]

@Michal-Dziedzinski I actually tried that too. The ElasticSearch query is fine. The problem is with the processor afterwards where a slug is being created. If you check the code, whenever there is a name present on children_data, it malfunctions.

[pkarw]

@Michal-Dziedzinski can you take second look at this when the slugify fails in this case as @themreza described?

[pkarw]

@themreza any console errors?

[Michal-Dziedzinski]

I'm already looking for that, there are no console errors

[themreza]

@pkarw Yes, there aren't any errors, but just an odd behavior when new config fields are added.