Using this configuration in combination with the page persistence strategy will yield 'no context path available' errors because the getCollectionItemConfigName from the page persistence strategy adds jcr:content when it wasn't supposed to.
You get faulty links like ...FooterConfig/jcr:content/menu/menu1/jcr:content/links instead of ..FooterConfig/jcr:content/menu/menu1/links where it's actually persisted and thus triggering these kind of issues. Changing the getCollectionItemConfigName in the PagePersistenceStrategy to the code below seems to fix that issue.
i assume this applies to the same code example as in WCON-60.
i cannot reproduce this issue. did you a apply a custom context path strategy, or picked on from those provided by the wcm.io context-aware configuration extensions (e.g. absolute partents/root template)? if yes, please document the configuration of these strategies that you used.
It does apply to the same code sample as in wcon-60.
I did use this in conjunction with AbsoluteParentContextPathStrategy with the following config:
I'm however not entirely sure that this is caused by that context path strategy (it might be) - but the problem seemed to be fixed when applying the proposed fix in the getCollectionItemConfigName method of the PagePersistenceStrategy
i was able to reproduce the issue. the fix you proposed fixes your special usecases, but breaks other ones (e.g. a configuration that is itself defined as collection should be stored as separate pages).
i think a deeper fix is needed for this issue, probably including a fix to the caconfig impl itself as well.
the problem should be solved in the latest version:
Configuration Extensions 1.6.0: AEM Page persistence strategy: Ensure AEM page is created also for nested list configuration without properties on the first level.
Configuration Editor 1.5.0: Make sure jcr:content node names does not appear multiple times for deeply nested collections.