[MGNLPN-474] Get (stateless) personalized content from the Delivery endpoint Created: 22/Nov/17 Updated: 17/Dec/21 Resolved: 15/Jun/21 |
|
| Status: | Closed |
| Project: | Magnolia Personalization |
| Component/s: | None |
| Affects Version/s: | 1.8 |
| Fix Version/s: | 2.1 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Viet Nguyen | Assignee: | Jaroslav Simak |
| Resolution: | Fixed | Votes: | 4 |
| Labels: | VN-Testing | ||
| Remaining Estimate: | 0d | ||
| Time Spent: | 3d 1h 31m | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Template: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Documentation update required: |
Yes
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Headless p13n | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | HL & LD 28, HL & LD 29, HL & LD 30, HL & LD 31 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Story Points: | 8 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
User story:
Notes: Personalization is one of the enterprise features that pure headless CMS do not have, now that we know many customers want to use the pages editor and personalization to populate headless frontends we should provide this. Acceptance criteria:
|
| Comments |
| Comment by Viet Nguyen [ 22/Nov/17 ] |
|
Example use case from customer: /v1/ {component/page path}?previewCountry=br |
| Comment by Marcel Koch [ 28/Jan/19 ] |
|
I'm bumping up this ticket. Was there any further progress regarding that idea? We would like to do the same. Thanks for any hint. |
| Comment by Travis Munroe [ 02/Jul/19 ] |
|
I am also looking for examples of how to leverage Magnolia's personalization feature through a REST endpoint. The documentation says it's possible through a custom Java endpoint (https://documentation.magnolia-cms.com/display/DOCS57/How+to+get+content+as+JSON+-+an+overview#HowtogetcontentasJSON-anoverview-CustomJavaendpoints). Where can I find documentation and/or examples of how to leverage the personalization feature in a custom Java endpoint? |
| Comment by Viet Nguyen [ 02/Jul/19 ] |
|
Thanks for responding and interesting in our new feature, please let me inform our development team for product development priority arrangement. |
| Comment by Christopher Zimmermann [ 07/Oct/19 ] |
|
Workaround from professional services department, not supported: Here is the source for the delivery endpoint v2 modified to return a personalized response (forked from master on September 19th)(Repository only available to enterprise partners): https://git.magnolia-cms.com/projects/SERVICES/repos/rest/browse You can see the change to support p13n in this diff:
|
| Comment by Christopher Zimmermann [ 07/Oct/19 ] |
|
An alternative workaround is to use a standard v2 delivery endpoint to return all the variants and then perform the actual personalization logic in the frontend. In order to get the "variants" via the rest endpoint from the "website" workspace, you need to configure the appropriate child nodes. For example: # Example delivery endpoint v2 configuration: class: info.magnolia.rest.delivery.jcr.v2.JcrDeliveryEndpointDefinition workspace: website rootPath: /travel depth: 6 nodeTypes: - mgnl:page childNodeTypes: - mgnl:area - mgnl:component - mgnl:variants #THESE ARE NECESSARY TO GET THE VARIANTS. - mgnl:page. #THESE ARE NECESSARY TO GET THE VARIANTS. limit: 100 # Then get content with something like: https://demopublic.magnolia-cms.com/.rest/delivery/pagesWithComponents/v1/contact |
| Comment by Mikaël Geljić [ 13/Feb/20 ] |
|
Initial implementation working, with a proper ContainerResponseFilter; two related issues though:
|
| Comment by Roman Kovařík [ 14/Feb/20 ] |
All of these should be solvable by extending ComponentPersonalizationNodeWrapper.
Since then probably bunch of other things depends on this behaviour (it's the only way to distinguish between original and variant node without unwrapping). A custom wrapper mentioned above for your use case would solve this issue. Simple traits probably work without any problems. What about e.g. a cookie trait, are page request cookies usually passed/copied to rest requests? Not sure if I am looking at the up to date code (not sure what's ContainerResponseFilter mentioned above): // Apply personalization if (this.traitCollector != null) { node = new PersonalizationNodeWrapper(node, Components.newInstance(PersonalizationContentDecorator.class), Components.getComponent(VariantMapping.class), Components.getComponent(VariantResolver.class), this.traitCollector, Components.getComponent(WebContext.class)); } can be written as follows // Apply personalization personalizationContentDecorator.wrapNode(node); //this properly returns {{ComponentPersonalizationNodeWrapper}} whereas the code above somehow combines {{ComponentPersonalizationContentDecorator}} and {{PersonalizationNodeWrapper}} And the last question, do we cache by default / do we want to support it? |
| Comment by Christopher Zimmermann [ 14/Feb/20 ] |
|
We want to support caching. But im sure there's complexity around not overcaching / stale content. |
| Comment by Roman Kovařík [ 14/Feb/20 ] |
Is this already implemented as well (I haven't noticed this in the repo linked above)?
Thinking about it again, it should be pretty quick as here is no rendering involved. Not sure how much would cache help. |
| Comment by Christopher Zimmermann [ 14/Feb/20 ] |
|
"Not sure how much would cache help." But with all the integrations going on and external content sources - I see a usecase of Magnolia serving content that is a mix of native and remote content (product information from PIM for example) In that case, seems like caching could be a benefit. Also - is there maybe some efficiencies around resolving the actual content that should be served based on the traits? I guess not at first since we talking about just serving the variants directlyu - without templates or template models. |
| Comment by Roman Kovařík [ 14/Feb/20 ] |
|
> Also - is there maybe some efficiencies around resolving the actual content that should be served based on the traits? I guess not at first since we talking about just serving the variants directlyu - without templates or template models Our caching of pages/components variants needs resolving even if items are already cached but it's pretty fast. |
| Comment by Christopher Zimmermann [ 14/Feb/20 ] |
|
OK. I guess my main input is simply that it should be performant. If its performant without caching then that's great. |
| Comment by Christopher Zimmermann [ 31/Mar/20 ] |
|
Question from a user in the documentation: "Are there any examples of how I could use delivery API to get component level content matching a certain Personalization Trait value? Looking to see if I could query by a trait value and get back a page's content with the matching component variations only and not all of the variations." |