1

We have a personalization rule that depends on two values that are changeable by end-users on a page, using two dropdowns. The personalization rule works fine on a page load (we know which values are currently set), but when one of the values is changed by a user after a page is rendered we need to check the personalization rule again to verify if the user can still see components, which has the personalization rule applied. We would like to achieve this without having to reload the page.

Now, we think that it could be solved in two ways:

  1. Re-render components on the server and replace their HTML on the frontend.

  2. Check the rule again forgiven components in the current page's context and hide components, for which the rule is not met.

Do you know if either of these options is feasible, and if so, how could it be implemented?

2

Not without reloading the page.

Your question is based on faulty assumptions. You assume that those two components are the only components on the page that would be affected by personalisation and/or conditional rendering. In reality anything on the page could be under such control and no single component should assume "control" of the entire page execution scope.

You could be looking to technologies such as JSS if you want to achieve a page refresh without the visible "page reload". But the entire page would need to be processed for rendering conditions to be executed and meaningful.

| improve this answer | |
  • Thank you for the response. – Karol Szyszko Jul 9 '19 at 7:34
0

What Mark wrote in his answer is absolutely correct. Sitecore does not mechanisms to execute conditional rendering personalization without executing a request.

But there is always some space for workarounds (or hacks, however we call it).

What you could do is an ajax call back to Sitecore with the same url as the page. When you receive html back from server, replace the content of <body> with the new <body> from the server. But there are already 2 issues with that:

  1. We don't want to track 1 extra page visit - I don't know if Sitecore ignores ajax call by default. If not, you would need to write a custom processor that would make sure that ajax requests are not tracked.

  2. All the user interactions with page (like your dropdown selection) are lost.

To work around the 2nd issue, you could think about adding some markers around the components which you want to update with their new versions from the server, like:

<!-- START: UNIQUE ID OF A RENDERING IN PRESENTATION DETAILS -->
<html of the component>
<!-- END: UNIQUE ID OF A RENDERING IN PRESENTATION DETAILS -->

And after the ajax response comes back from the server, only replace bits between the markers (or remove parts of the html if the markers are not present in the new ajax response).

With all of that said, you need to remember you're working around Sitecore mechanisms and it's possible it won't work in some cases and every upgrade of Sitecore version may have impact on your solution.

Now it's your decision, if the requirement to update bits of the page using personalization options is so important that you cannot do a full page reload and maybe if those conditions even should be handled by personalization.

| improve this answer | |
  • Thank you for the reponse. Do you have any suggestions though how could this be solved using other approach than by personalization? – Karol Szyszko Jul 9 '19 at 7:35
  • No one will be able to give you an answer to that question if they don't know the full requirements and all the possible test cases. – Marek Musielak Jul 9 '19 at 7:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.