Possible SiteSync Bug

Posted by Community Admin on 04-Aug-2018 18:19

Possible SiteSync Bug

All Replies

Posted by Community Admin on 09-Dec-2014 00:00

When a *page* is created as a redirect, its *sf_page_node.content_id* is set to null because there is no content, which is fine.

 The page is synced, and this null flows to the next environment.

When the page is edited to now be an actual page and not a redirect, an sf_page_data record is created for the page, and *sf_page_node.content_id* is populated respectively.

But when trying the next sync, the page fails that *sf_page_data* record is not found for the particular page, giving a NOTRES error in the *Synchronization.log*

 

 

Item information: id = '35b2b160-81b5-64c2-a3a8-ff0200665429'; type = 'Telerik.Sitefinity.Pages.Model.PageNode'; provider = 'OpenAccessDataProvider'; action = 'Updated'
Error details:Telerik.OpenAccess.Exceptions.NoSuchObjectException: No row for Telerik.Sitefinity.Pages.Model.PageData ('sf_page_data') GenericOID@9b9ed1cc PageData content_id=3bb2b160-81b5-64c2-a3a8-ff0200665429 NOTRES
   at DynamicModule.ns.Wrapped_OpenAccessPageProvider_d5191026084d4695a598f69ddbbc582e.FlushTransaction()
   at Telerik.Sitefinity.Data.TransactionManager.DoWithConnections(Connections originalConns, Action`1 action, IEnumerable`1 conns, Int32 prevConnsCount)
   at Telerik.Sitefinity.Data.TransactionManager.FlushTransaction(String transactionName)
   at Telerik.Sitefinity.SiteSync.PermissionConverter.ImportProperty(Object instance, PropertyDescriptor prop, Object value, Type type, Object args)
   at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid6[T0,T1,T2,T3,T4,T5](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)
   at Telerik.Sitefinity.SiteSync.Serialization.SiteSyncSerializer.SetProperty(PropertyDescriptor prop, Object value, Object instance, Object args)
   at System.Dynamic.UpdateDelegates.UpdateAndExecuteVoid5[T0,T1,T2,T3,T4](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)
   at Telerik.Sitefinity.SiteSync.Serialization.SiteSyncSerializer.SetProperties(Object destination, Object source, PropertySetPredicate setPredicate, Object args)
   at Telerik.Sitefinity.SiteSync.Serialization.SiteSyncSerializer.SetProperties(Object destination, Object source, Object args)
   at Telerik.Sitefinity.SiteSync.SiteSyncImporter.ImportItem(String transactionName, Type itemType, Guid itemId, SiteSyncObject item, String provider, ISiteSyncImportTransaction importTransaction)
   at Telerik.Sitefinity.SiteSync.PagesImporter.ImportItem(String transactionName, Type itemType, Guid itemId, SiteSyncObject item, String provider, ISiteSyncImportTransaction importTransaction)
   at Telerik.Sitefinity.SiteSync.SiteSyncImporter.<>c__DisplayClassa.<ImportInternal>b__2(FluentSitefinity app)
   at Telerik.Sitefinity.SiteSync.SiteSyncImporter.RunInSpecificCulture(String culture, String transaction, Action`1 func, Action`2 logAction)

 

The backend Pages UI is broken (in the receiving environment) with an alertbox with the NOTRES error.

 

If I remove the page from the receiving environment (thru database deletes as the UI is broken) will the page be re-created on the next sync ??

How can I fix these types of errors ?

 

 

 

Posted by Community Admin on 09-Dec-2014 00:00

Sitefinity Version is 7.0 5100

Posted by Community Admin on 12-Dec-2014 00:00

Hello Ernesto,

Yes, if you delete the page and then sync it should do the trick, although I do not advise you to do this in the database directly, but rather use the API: Deleting pages

Before trying the above, this indeed looks like a reported bug in our system, which origin we were not able to identify and the issue is caused when the node type of a group or redirect page is set to Standard, in other words SItefinity is looking for a PageData as it considers the page as a standard one, but group or redirect pages does not have PageData.

We have a code snippet to fix this issue in multisite environment, so I could suggest to run it first and see if this solves it:

var multisiteContext = SystemManager.CurrentContext as MultisiteContext;
            var sites = multisiteContext.GetSites().ToList();
    
            var pman = PageManager.GetManager();
            pman.Provider.SuppressSecurityChecks = true;
  
            foreach (var site in sites)
            
  
                var nodes = pman.GetPageNodes().Where(p => p.RootNodeId == site.SiteMapRootNodeId && p.NodeType == Telerik.Sitefinity.Pages.Model.NodeType.Standard);
                foreach (var node in nodes)
                
                    var pagedata = pman.GetPageDataList().Where(d => d.NavigationNodeId == node.Id);
                    if (pagedata.Count() == 0)
                    
                      node.NodeType = Telerik.Sitefinity.Pages.Model.NodeType.Group;
                    
                
            
            pman.SaveChanges();

You feedback will be most valuable, so I will appreciate to update me for the result.

Regards,
Vassil Vassilev
Telerik
 
Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Sitefinity CMS Ideas&Feedback Portal and vote to affect the priority of the items
 

Posted by Community Admin on 12-Dec-2014 00:00

Thank you Vassil,

to confirm, I will run this snippet on the destination environment (?).

Posted by Community Admin on 12-May-2015 00:00

Exact same error on my production server.  Please confirm if running the above against your production database fixed the issue?  I'm in hot water here, we have a production site down because of this issue.

Posted by Community Admin on 15-May-2015 00:00

Hi,

The bug for this issue has been logged and fixed in Sitefinity 8.0.
The query provided above by Vassil will not delete the problematic page, it ensures that pages that have no PageData (the object where widgets and page layouts can be placed) are converted to group pages

The problem can be resolved with DB query that removes the content_id of the problematic page.

UPDATE [Databasename.[dbo].[sf_page_node]
SET content_id = null
WHERE title_ = 'The problematic page's title here'

The issue is recreated by the below steps, avoid them if the site is not running Sitefinity 8.0 where this is fixed.

1. Setup 2 servers in Sitesync
2. Create a normal page on source server and sync it to destinatio
3. Go back to source server and change that page to group or redirect

4. Sync the page to destination again.

Regards,
Stanislav Velikov
Telerik
 
Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Sitefinity CMS Ideas&Feedback Portal and vote to affect the priority of the items
 

Posted by Community Admin on 04-Jun-2015 00:00

[quote]Stanislav Velikov said:Hi,

The bug for this issue has been logged and fixed in Sitefinity 8.0.
The query provided above by Vassil will not delete the problematic page, it ensures that pages that have no PageData (the object where widgets and page layouts can be placed) are converted to group pages

The problem can be resolved with DB query that removes the content_id of the problematic page.

UPDATE [Databasename.[dbo].[sf_page_node]
SET content_id = null
WHERE title_ = 'The problematic page's title here'

The issue is recreated by the below steps, avoid them if the site is not running Sitefinity 8.0 where this is fixed.

1. Setup 2 servers in Sitesync
2. Create a normal page on source server and sync it to destinatio
3. Go back to source server and change that page to group or redirect

4. Sync the page to destination again.

Regards,
Stanislav Velikov
Telerik
 
Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Sitefinity CMS Ideas&Feedback Portal and vote to affect the priority of the items
 

[/quote]

 

Glad I saw this before asking our DBA to revert our corrupted database. Glad this is fixed in 8.0. I guess we'll have to upgrade soon. Thanks for posting the workaround. 

This thread is closed