Staging task not created when page is updated by code

Sylvain C. asked on December 15, 2021 10:17

Hello, I am working on my ASP.Net Core site (hotfix: 13.0.55). When, I update a page through the admin UI, the staging task is created indicating that the page has been updated.

However if I do the exact same modification using some code in my admin site such as:

            CMS.DocumentEngine.TreeNode page = new DocumentQuery<CMS.DocumentEngine.TreeNode>()
                            .Path("/Meetings/SharePoint-events/Event-TEST-03", PathTypeEnum.Single)                                
                            .OnSite("MySite")
                            .Culture("en-us")
                            .TopN(1)
                            .FirstOrDefault();            

                page.DocumentName = "Updated meeting name";
                page.SetValue("EventTitle", "Updated article title in English V2");

                // Updates the page in the database
                page.Update();

The staging task is not created.

What could explain this behaviour?

Thank you,

Sylvain

kentico 13 core

Correct Answer

Sylvain C. answered on December 15, 2021 11:26

Thank you David, I tried it but unfortunately it didn't create the staging task.

using (new CMS.Base.CMSActionContext() { LogSynchronization = true })
                {
                    //your code

            CMS.DocumentEngine.TreeNode page = new DocumentQuery<CMS.DocumentEngine.TreeNode>()
                            .Path("/Meetings/SharePoint-events/Event-TEST-03", PathTypeEnum.Single)
                            .OnSite("MySite")
                            .Culture("en-us")
                            .TopN(1)
                            .FirstOrDefault();                

            page.DocumentName = "Updated meeting name";
                page.SetValue("EventTitle", "Updated article title in English V4");

                // Updates the page in the database
                page.Update();
            }

I have tried some code from K12.

For getting the page, I used:

var page= DocumentHelper.GetDocuments()
            .Path("/Meetings/SharePoint-events/Event-TEST-03", PathTypeEnum.Single)                            
            .Culture("en-US")
            .OnCurrentSite()
            .TopN(1)
            .FirstOrDefault();

In that case, when I update the page, even without using the DocumentSynchronizationHelper.LogDocumentChange, the staging task is created.

So it looks like DocumentHelper.GetDocuments() takes care of the staging while DocumentQuery<CMS.DocumentEngine.TreeNode>() does not... Does it make sense? DocumentQuery<CMS.DocumentEngine.TreeNode>() is used everywhere in the API documentation while DocumentHelper.GetDocuments() is not and is only available in k12 documentation.

I am confused, as they are so many ways of accessible the pages (DocumentHelper.GetDocuments(), DocumentQuery<CMS.DocumentEngine.TreeNode>(), tree.SelectNodes()) and it is unclear to me whcih one should be used in which situation (performance, workflow, staging)...

0 votesVote for this answer Unmark Correct answer

Recent Answers

David te Kloese answered on December 15, 2021 10:35

Believe you need to add something like:

DocumentSynchronizationHelper.LogDocumentChange(document, TaskTypeEnum.UpdateDocument, Tree);

It's basically to avoid API document changes triggering a lot of staging tasks unintended. So you have to create them purposely.

0 votesVote for this answer Mark as a Correct answer

Sylvain C. answered on December 15, 2021 10:50 (last edited on December 15, 2021 11:00)

Thank you David, I have edited my code accordingly:

CMS.DocumentEngine.TreeNode page = new DocumentQuery<CMS.DocumentEngine.TreeNode>()
                                .Path("/Meetings/SharePoint-events/Event-TEST-03", PathTypeEnum.Single)                                
                                .OnSite("MySite")
                                .Culture("en-us")
                                .TopN(1)
                                .FirstOrDefault();

            DocumentSynchronizationHelper.LogDocumentChange(page, TaskTypeEnum.UpdateDocument, Tree);

            page.DocumentName = "Updated meeting name";
                page.SetValue("EventTitle", "Updated article title in English V2");

                // Updates the page in the database
                page.Update();

It works, the task is created.

But it means that I need to add this line each time I am updating a page (TaskTypeEnum.UpdateDocument) or when I am creating a new page (TaskTypeEnum.CreateDocument) or when I am deleting a page (TaskTypeEnum.DeleteDocument) using the code.

It is going to be a burden in my code as I am creating multiple pages, then updating some attachments, creating some other cultures, removing old pages, etc... Everything is done by code and used to work fine for the staging using K12.

I didn't need to do so in Kentico 12. Just using page.Update() or page.Insert(parentNode) or page.Delete() was creating the staging tasks automatically. Isn't there a higher level property to enable the staging task for all page manipulation?

Thank you again for your help

Sylvain

0 votesVote for this answer Mark as a Correct answer

David te Kloese answered on December 15, 2021 11:16

Can you try using the CMSActionContext?

using (new CMS.Base.CMSActionContext() { LogSynchronization = true})
{
   //your code
}

There are more properties like LogWebFarmTasks, LogEvents or LogExport.

See

https://devnet.kentico.com/docs/13_0/api/html/Properties_T_CMS_Base_CMSActionContext.htm

0 votesVote for this answer Mark as a Correct answer

Juraj Ondrus answered on December 16, 2021 08:41

SelectNodes() and new DocumentQuery< TreeNode >() are working with tree node - so they work with published data and other operations are not handled (workflow, staging etc.). Therefore these are bit faster but then, if you want to use staging, you will lose some time with the extra LogDocumentChange() - so, I would say that in this case it will be a draw.

It really depends on the project details and specs, it vary project by project. If you are sure you won't be using workflows in the future, you want to have it fast and simple, I would use SelectNodes - but also no staging. I would maybe use this for some smaller, simple and straightforward projects where is not expected too much maintenance in the future.

Or, if you just need to get the published version of the page, use the SelectNodes, if you want to do any of the CRUD operations, use GetDocuments.

0 votesVote for this answer Mark as a Correct answer