Problem/Motivation
Menus often contain nested information. Currently, there is no way to retrieve subtree links.
We need a way to include them in the main payload, or maybe provide a sub resource path that specifies a tree root
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | 3170358-14.patch | 10.4 KB | larowlan |
| #14 | 3170358-14-interdiff.txt | 463 bytes | larowlan |
| #13 | 3170358-13.patch | 10.41 KB | larowlan |
| #13 | 3170358-13-interdiff.txt | 1.63 KB | larowlan |
| #11 | 3170358-11.patch | 10.33 KB | larowlan |
Comments
Comment #2
decipheredConfirming this issue is present and needs resolving as high priority.
See example of issue here: https://dev-druxt.pantheonsite.io/jsonapi/menu_items/main
Comment #3
decipheredThe source of this module is mostly the Rest Menu Items module.
One of the specific areas of code that relates to this issue is: https://git.drupalcode.org/project/rest_menu_items/-/blob/3.0.x/src/Plug...
By setting the min depth we can access the subtree items, so it's then just a case of recursively iterating over the data and building the required resources.
I will attempt to get a patch available for testing soon, but if I am unable to I am happy to provide context on what needs to be done.
Comment #4
decipheredThe attached patch deals with the subtree. It is under-tested, and likely needs more work, but it's a starting point.
Comment #5
decipheredUpdated with a slightly saner approach, and have tested using the
druxt-menunode module.Comment #6
mglamanso this puts them all in a root collection, and then the frontend needs to sort out the tree depth, correct?
Comment #7
decipheredCorrect. All menu items are at the root, then it's up to the JSON:API query to retrieve the required data.
To retrieve all root items, you can simply request all items without a parent.
Then, as you walk through the tree you can pull in the next level as required by filtering items that have a specific parent.
Comment #8
larowlanHere's some expanded test-coverage for ensuring we see the menu-items we expect and that the parent field is populated.
This test also contains pieces we will be able to easily modify to demonstrate the bugs in #3170340: Apply cacheable metadata to the response object and #3171184: Filter our inaccessible menu links
e.g. the fixture contains an inaccessible item that we can remove for #3171184: Filter our inaccessible menu links test coverage.
It also contains a content entity that we can edit and re-save, to demonstrate the cache issue in #3170340: Apply cacheable metadata to the response object
I'll postpone those on this
Comment #10
larowlanComment #11
larowlanThe test fail here comes from #3171184: Filter our inaccessible menu links - the 'Inaccessible' items are not string, but in fact instances of TranslatableMarkup which causes caching assert issues.
I'll re-categorize that as a bug
Comment #13
larowlanDoh, forgot testbot runs in a subdirectory
Comment #14
larowlanCS fixes
Comment #15
decipheredI have tested this against the `druxt-menu` module and everything appears to be in working order on the JSON:API Menu Items side.
Marking as RTBC and will commit in the next few hours.
Thanks all, appreciate the effort.
Comment #17
larowlanComment #19
marcvangendWhile I'm sure that improvements were made in this issue, I'm missing some documentation. I think I understand dat subtree items are now added to the response, albeit not nested, but on the root level of the response data.
But I also read the following:
Does this mean there I can add parameters to my request to limit the menu items to a maximum depth, and/or to retrieve the children of a specific parent item?
Thank you for your help.
Comment #20
decipheredHi @marcvangend,
As this issue is closed it would be best to open a new issue with the question so that we can ensure it gets tracked and actioned correctly (e.g., you get an answer, and the answer gets turned into documentation).