Try our conversational search powered by Generative AI!
AI OnAI Off
EpiServer/Optimizely architecture for different headers
The one page override is cleaner but as you said lacks the central management.
The only thing I'm thinking of with adding properties to the blocks is the annoyance of going in to each block. So I was thinking could you add a ProperyList with 2 ContentAreas. Property1 a drag and drop list of pages, property 2 the Block to render. Then you've got a root mapping of pages to blocks in your raw root page?
Aug 30, 2021 14:17
So the way I understand it:
- The menu is defined on a block in a specific content area on the home page so it can be personalized.
- Using an Override content area on other pages is undesirable because it's not centrally controlled.
Why not create a new Visitor Group Critereon for that returns a positive result if the user is on a specific page by using the PageRouteHelper class: https://world.optimizely.com/documentation/developer-guides/CMS/personalization/example-create-your-own-visitor-group-criteria/
Edited,
Sep 02, 2021 12:06
Thank you for your answers! By experience from my company the solution we are currently going with is an override header on CMS pages, but with the extension of all pages always looking up at their ancestors. The nearest ancestor which the page have with a header is the one that is going to be used. This means that the Content Editors still only needs to administor the headers a few places instead. And the performance impact will scale with the ancestor depth instead of the number of children. This should in theory have much less performance impact, while still being a generic solution.
Sep 14, 2021 7:07
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
Hi all,
I am in need of some EpiServer/Optimizely architecture recommendations and advices, and I hope some of you would be able to provide me with some valid feedback.
Context:
I am working on an EpiServer CMS project for a large website. Most general configuration is setup on the frontpage which works as a root page for all the CMS pages. The architecture looks a bit like this:
The website contains a header with menu items displaying the pages which lives under the root page (front page). This header is a CMS block which lives in a ContentArea on the frontpage, and works with personalization (so that it can be different dependant on several cookie settings).
The challenge:
There have been a new requirement. It should be possible to display a very similar, but different header on certain CMS pages (the CMS pages for which it should be shown is dynamic and it should be controlled by the content editors). The different header should be managed completely by its own as it can contain very different menu items (basically it should be managed as a seperate block). My question is then how could this be handled in a good way?
The current suggestions/solutions:
Extend the current header CMS block with a ContentArea-property (lets call it "PagesToShow") where pages for which it should be shown can be added, it should also be working for child pages. Eg.: if "Articles" from above tree is added to the ContentArea the header should be shown on both the "Articles", "Article1" and "Article2"-page. If no pages are added to "PagesToShow" the header should be shown on all pages. In this solution a content editor can make a duplicate of the already used header, and then configure the differences on the new header, and afterwords configure which pages the new header should be shown. The practical implementation of this then requires the FrontPage to be able to have more headers in the ContentArea where the original header lives. The frontpage should then filter the header based on the pages in their "PagesToShow"-property. This means that on each page load (which happen on every page change) the frontpage will be checking all headers in the ContentArea, and checking all children pages on their "PagesToShow"-property and then display the header which contains the current page. We are a bit worried in my team if this can have a to big performance impact. Especially if the number of pages where the new header should be shown can be up to 100 pages.
Another solution could be to have an "Override"-header on each CMS page. If that page is set the header should be overridden by the current pages header. The concerns about this solution is that it might become very difficult to administor for content editors, as they need to go into every CMS page and add the new header block they have created.
I really hope some of you guys would be able to enlighten me with pros/cons/thoughts about how this can be done. I look forward seeing your answers.