Possible SiteSync Bug
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 ?
Sitefinity Version is 7.0 5100
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();
Thank you Vassil,
to confirm, I will run this snippet on the destination environment (?).
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.
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'
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
[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'
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
[/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.