[WIP] change default "INDEX_OPTIONS" #2003
Conversation
change "INDEX_OPTIONS" from "coreProductGridWorkflow" to "coreWorkflow". Reason: when the root path "/" is rendered in "ReactionLayout", it will look for combination of layout and workflow to retrieve template from collection "Shop". If "INDEX_OPTIONS" is "coreProductGridWorkflow", "ReactionLayout" will look for "coreLayout" and "coreProductGridWorkflow" in "Shop". Instead, we should retrieve "coreLayout" and "coreWorkflow".
|
|
|
Hi @gepolv, I tested this and it still didn't solve the problem of the default template being used over the set custom one. What is really happening here is that when there is a custom template defined (which means there are two matching Layouts - one being the default and the other the custom), the custom layout should be the one used in rendering. That selection happens here. So the solution should be to add logic to determine and use the custom layout. |
|
Perhaps logic, or maybe even some kinda UI to select the one you want, kinda like the template selector on the PDP page. |
|
Thanks @mikemurray. I haven't considered using a UI like the PDP. But my guess it that, that would need to be considered properly, to determine if it's needed or not. Considering that the issue (#1969) was labeled as "regression", there was a time it was using the custom template when available (over the default). Has there been any previous mention of having a template selector for this page? |
|
We've talked about the ability for users to select templates for anything. Consider users that use the PaaS only; they'll need a way to select different templates for pages as well. In this case, the way the index page works is different from all others. At the very least, it needs to be in the registry so it can be overriden from the database. |
|
@impactmass To better explain the problem, I have two screenshots of Collection "Shop": The first figure shows Item 11 and Item 12. Our current behavior is selecting Item 11 because layout is set as "coreLayoutBeesknees" and workflow is set as "coreProductGridWorkflow". As you can see, the "structure" under Item 11 is not correct. This figure shows Item 12 and Item 13. As you can see, both have the same workflow and layout. however, their "structure"s are different. "Structure" under Item 12 is from the example plugin whose template is "productsLanding" defined https://github.com/reactioncommerce/reaction-example-plugin/blob/master/register.js#27. Conclusion: the logic here is correct because Item 12 (custom plugin) comes before Item 13 (default one). What we need to do is to change "INDEX_OPTIONS" from "coreProductGridWorkflow" to "coreWorkflow", Item 12 will be selected and the issue mentioned in #1969 will be resolved. |
|
@gepolv I agree with your analysis of the problembut I don't agree with your solution. It would only patch this one case where it's grabbing the wrong layout record and not have any affect on other custom layouts. I think the real solution is to load records in such a way that "custom" layouts always override default ones when the records are loaded in the router here We also should not be relying on load order as that is not something that we can assume will always be the same. |
|
@zenweasel reaction/client/modules/router/main.js Line 124 in 8dd49b4 It is still Item 11 in Figure 1, which is still wrong. You basically believe the default workflow should be "coreProductGridWorkflow". What is the reason behind this? In my opinion, "coreProductGridWorkflow" cannot be the default workflow. Instead, "coreWorkflow" should be the default workflow. Correct me if I am wrong. |
change "INDEX_OPTIONS" from "coreProductGridWorkflow" to "coreWorkflow".
Reason:
when the root path "/" is rendered in "ReactionLayout", it will look for combination of layout and workflow to retrieve template from collection "Shop". If "INDEX_OPTIONS" is "coreProductGridWorkflow", "ReactionLayout" will look for "coreLayout" and "coreProductGridWorkflow" in "Shop". Instead, we should retrieve "coreLayout" and "coreWorkflow".
Please provide the following information to help us approve your PR. Failure to provide this
information may result in your PR being closed without comment.
Issue 1969 : Can no longer override workflow/layout structures from a plugin #1969
With this change, the issue mentioned in Issue 1969 can be resolved.