Closed stevie-mccomb closed 3 years ago
Thanks, @stevie-mccomb for the detailed issue description!
If I get it right, it might be solvable by extending resolveInlineLinkedItems
signature by 3rd parameter $linkedItems
and in default implementation feed this parameter here:
Correct?
@Simply007 Yes, I believe that would resolve the issue, or at least give someone using the SDK the tools to resolve it themselves within their resolveInlineLinkedItems method by searching through the $linkedItems to find the appropriate item by codename.
@stevie-mccomb - could you take a look at #106, I guess this might be fine for initial implementation.
Brief bug description
When registering a custom inlineLinkedItemsResolver to the delivery client, you can't properly resolve linked items that have their own linked items (modular_content) because the linked items just come over as a list of codenames but then there's no variable that allows access to the master list of modular content to retrieve from.
Repro steps
Expected behavior
The inline linked items should either be resolved in the same manner as the non-inline linked items and then passed to the inlineLinkedItemsResolver, or the modular_content list should be accessible to the inlineLinkedItemsResolver so they can be resolved manually.
Test environment
Additional context
N/A
Screenshots
Here is an example screenshot of modular content that can't be resolved. There's an item that has an element (in this case "slides") that is a reference to other linked items and they cannot be resolved.
The two arguments shown here in a custom inlineLinkedItemsResolver don't have the modular content in them and they are the only two arguments that can be accepted. So if the inline item has a list of modular content, then you just get the codenames of the inline content and no actual content to reference or load to the view.