We are using rte component and in the link option trying to link to a content fragment path (A custom requirement). The link option seems to provide a 'page browser' but we are looking to use a 'path browser'.
The reason being currently the link option's page browser, we can navigate to content fragments but the content fragment itself are not visible.
Further looking, we found a call to linkpathpicker(/mnt/overlay/cq/gui/content/linkpathfield/picker/views/column) is adding the hideContentFragment=true as param in URL which keeps the CFs hidden.
Is this a desired behavior that rte (plugin) shouldn't be pointing to a CF?
We can always overlay below path and make the hide value false or remove it.
However, we are looking to find a solution that does not involve an overlay of /apps.
Please share thoughts on what else can be tried. I feel using path browser via link browser may help. Looking into rte configuration documentation unable to find a way that could point to a Content Fragment.
Logically, CFs are used to collect structured data, which does not have any presentation linked to it.
Saying this, CFs are re-useable content, to be consumed by other components, so that components can consume the CF data and render it in a presentable layout.
So ideally, you should create a page, put a component in it, which will consume CF, and in RTE, link the page using the Link plugin.
Hope it makes sense now.
Thank you so much for responding. I agree, however as this is a custom requirement not directly related to showing content in a presentable way rather to fetch the content fragment data and do something with it. ( We get the cf link and use those CF data to present else where)
Regardless of the custom use case I mentioned above, if some project needs to include some content in rte and also add some data from CF to it, if they were able to just link to a CF. Would you know why showing CF in link plugin may be blocked? Doesn't seem so in AEM 6.4 we are on AEM cloud sdk (092022).
I have noticed that the pathbrowser make following request  which has hideContentFragments as true. If we make it false, path browser start returning CFs also. So you have to find out a way to make this flag as false.
@Mohit_KBansal Yes, correct we have an overlay option to set it to false as added in the question, but the question is about avoiding an overlay. Other than this we also have an option to add a filter with /mnt/overlay... based pattern in author which we are trying to avoid as well.
Is there any change in the rte (policy or dialog structure) that can manage this? Overlay and Filter options don't seem to sustainable from AEM as cloud perspective since overlay wise we have to make sure the overlay is consistent with changes to /libs node. Also Filter option is a light baggage to carry..