K13 widget substitution

Aaron Macdonald asked on November 7, 2022 02:17

Hello

We have a scenario with the following requirements using K13 .NET framework platform:

Editors need to create a range of variants for a single page with widgets on it.
Only one variant is active at a time.
Only one URL is used to access the active variant.

It feels like there should be a simple solution whereby a parent page has child page variants, and the parent retrieves and renders the active variant data.

However this does not seem possible when widgets are involved, as the widget data is connected to the actual page instances.

Could someone please explain if it's possible to substitute widgets from one page onto another, or whether there is a better solution here?

The only other solution might be a URL rewrite rule that would need to be programmatically modified, which would be ugly.

TIA

mvc widget

Correct Answer

Aaron Macdonald answered on November 8, 2022 23:49

Thanks Dimitry the URL swap is a possible solution, but we don't think it's ideal for the client.

Juraj re: discrepancy between live and admin you're correct. We've been able to overwrite widget data now on a parent page from a child page for both the published and latest versions.

As this seems to be non-standard activity, can we be sure that it won't have any unexpected impacts if we are just updating this widget data in the thread of a controller action?

For the benefit of anyone trying to do the same thing, there are two different actions required to update widget data on the published and latest version.

To update the published version, as mentioned above you can use an IDocumentCultureDataInfoProvider to get the parent's DocumentCultureDataInfo, update its DocumentPageBuilderWidgets property, and then set the modified entity.

To update the latest version you can retrieve the latest VersionHistoryInfo from the parent page's VersionHistory property, then modify its NodeXML inner text, and set the modified entity with an IVersionHistoryInfoProvider. Specifically it's the XML element named DocumentPageBuilderWidgets that needs to be updated.

0 votesVote for this answer Unmark Correct answer

Recent Answers

Juraj Ondrus answered on November 7, 2022 05:33

What is the purpose of the multiple variants of a page? Is it something like content personalization? Content personalization is an on-line marketing technique that creates pages with different content depending on the circumstances in which they are viewed. For example, you can build pages that offer special content for different types of visitors or dynamically change for each user according to the actions they performed on the website. If this is what you are looking for, please see the documentation.

0 votesVote for this answer Mark as a Correct answer

Aaron Macdonald answered on November 7, 2022 07:05

Hi Juraj

The use case is not content personalization. As per their requirements the client wants to have variants of a page, which they can share internally for review, and periodically make one variant active and accessible on the same URL.

We could do this easily if there were no widgets involved, but as mentioned we're not sure how it could be done with widgets.

0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on November 7, 2022 08:01

So, what about using workflows, or advanced workflows where you can push the page through an approval process and then publish given version if it is OK? In advanced workflows you can even have multiple branches and go through different approvals...but ouot of the box, there is no such a feature available.

0 votesVote for this answer Mark as a Correct answer

Dmitry Bastron answered on November 7, 2022 08:30

Hi Aaron,

I think the easiest would be to have multiple pages with multiple URLs, where only "active" version would be published. Then, when you need to switch it, simply unpublish the current version, swap the URLs and publish the other.

0 votesVote for this answer Mark as a Correct answer

Aaron Macdonald answered on November 7, 2022 22:50 (last edited on November 8, 2022 07:37)

Thanks for the responses.

An advanced workflow is probably not what the client wants in this case and might cause confusion.

Dimitry when you say 'swap the URLs' do you mean programmatically alter page names/locations?

My colleague Tom Allen pointed to the answer on this devnet question: https://devnet.kentico.com/questions/is-there-a-way-to-get-the-widgets-on-a-page-programmatically.

Following that line of thought if we use the IDocumentCultureDataInfoProvider to set DocumentCultureDataInfo.DocumentPageBuilderWidgets on the parent page from a child page, we are seeing the expected result rendering on the live site but not on the admin site. In the admin site the parent page retains its original widget configuration for reasons unknown.

Can someone please advise if we can take this approach without breaking anything, and why we would be seeing a discrepancy between live and admin?

0 votesVote for this answer Mark as a Correct answer

Dmitry Bastron answered on November 8, 2022 08:43

Aaron, by 'swapping the URLs' I mean you could prepare pages A (/main-url), B (/url-1) and C (/url-2) where only A for example would be published. Then, when you want to 'change the variant' you unpublish A and publish B. Then swap their URLs to be A(/url-1) and B (/main-url). I think you can do this programmatically as well: - store these pages as siblings - hook into page create/update event and when publishing one page - unpublish all siblings and update URLs however needed

The discrepancy between Admin and MVC you mentioned could be due to Admin site caching widgets on page so when you amend those via code it could still store the cached version maybe? Do you still have this discrepancy if you restart Admin site?

0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on November 8, 2022 09:11

What is the code for updating the DocumentPageBuilderWidgets? Are you sure you are updating the latest edited version and not the latest published version? Especially if the pages are using workflows, the admin UI displays the latest edited version and live site the latest published version. So, if you are updating the value directly in the CMS_Document table, this one holds the published version data. (please see this to understand how and where is what content stored in the DB).

Please check that you are using the right API to work with pages.

0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on November 9, 2022 09:39

"As this seems to be non-standard activity, can we be sure that it won't have any unexpected impacts if we are just updating this widget data in the thread of a controller action?"

I do not know all the code and details so I really cannot give you any answers on this. IF you want to be sure, I would suggest scheduling an ad-hoc session with our solution architect to check your code.

0 votesVote for this answer Mark as a Correct answer

Aaron Macdonald answered on November 14, 2022 00:46

Thanks Juraj, this approach does seem to work so we'll keep an eye on it during testing to check that nothing unexpected occurs.

One caveat - The above code does not play well with page builder. The overwrite works but you may not see the results reflect in page builder until you reload the page. Not ideal but we think this will suffice for the client.

0 votesVote for this answer Mark as a Correct answer