Questions & Answers

[rbitdd]

Hello,

I moved some pages in the pagestore and since that I have some errors like this:

29.04.2013 17:09:08.141 ERROR ($CMS_REF(#nav.ref)$ at 12, 15): Error resolving reference - cannot get page 183086 for page ref 'standardseite_23' (id=353242)
    inside of: Template 'Standardseite' (id=182590)
    inside of: $CMS_TRIM(level:3)$ - at 1, 26
    inside of: $CMS_RENDER(template:"navigation", personalNode:rootPersPortPreview)$ - at 80, 6
    inside of: Format Template 'navigation' (id=314845)
    inside of: $CMS_IF(  ! ss_pmmRoot.isEmpty )$ - at 144, 2
    inside of: $CMS_VALUE(fr_pt_pmm)$ - at 144, 31
    inside of: $CMS_REF(#nav.ref)$ - at 12, 15

the page with this ID still exists and is also released. Only the folders in which I moved the pages into are not released.

I released one of these folders and some of my errors were solved...

We use since a couple of days 4.2.484. I'm not sure, whether we had this errors before...

Looking forward for feedback.

Best regards

Diana

[rbitdd]

It seems, that releasing the folder won't help always.

[rbitdd]

Now I found a folder in the pagestore which is renamed and the generation throws the error.

In the history of this folder I found this:

As you can see, the information "releasedby" is disappeared. But the releasedRevision is still known.

As far as I know it doesn't matter whether the folder in the pagestore is released or not, as long as you do not need any information from the pagestore (e.g. metadata). Have there been changes?

Has anybody else seen / problems with this behavior?

[broszeit]

Hello,

this is a strange behaviour. I'm trying to reproduce you behaviour but i'm not able to get this error.

Could you try to recalculate the reference graph of the project?

In the project configuration you should find a schedule "Repair references" which recalculates the reference graph.

Probably this might solve you problem.

Regards

Rouven

[Hendrik]

Hello,

I'm not sure if the following explanations will solve your problem.. give it a try. It's very important to release the moved element and its new parent before your release the old elements parent if you want to generate between the two releases. An element always needs a valid parent in the release store to rerieve the element from the release store, otherwise problems like you described them can occur.

So, if you moved pages into another folder and released (or deleted) the old parent folders without releasing the new parent folder, then the elements have no valid parent entry in the content repository which causes such errors you described.

This behaviour is NOT new..

[rbitdd]

@Hendrik: Have you seen the changes in this thread? Unfortunately I was wrong when I created this thead. I'm not talking about the sitestore, it is about the pagestore.

Shouldn't it be indifferent whether the parent folder in the pagestore has an release state or not?

@Rouven: Repairing the references didn't help.

[Hendrik · Accepted solution]

The store type doesn't matter, the behaviour is the same in each store. The key is that an element which has been released needs a parent which is also released, otherwise the element is not accessible from the release store. The element itself stores the ID of the parent element, and on the other hand a parent element stores a list of its child element IDs.

Assumpting you now move a released element

• from a parent which is released to a parent which has never been released. If you then release the element, it contains a parent ID from a parent which is not in the release store. This constellation causes a not from the release store retrievable element. FirstSpirit throws an error..
• from a (old) parent which is released to a (new) parent which is also released. Then you release the old parent. In this case the moved element contains a parent ID in the release store from a element which doen't have the element in his child list. This causes also not from the release store retrieveable elements. FirstSpirit throws an error..

The folowing scenario illustrates what I mean:

1.) Create a folder testFolderOne and testFolderTwo in the page store root, add a page testPageOne to page folder testFolderOne and release everything.

2.) Move the page testFolderOne to folder testFolderTwo via drag&drop

3.) Release testFolderOne (the old parent of testPageOne).

4.) Try to get testPageOne from the release store, e.g. via BeanShell and see how FirstSpirit throws an error because the element can not be retrieved..

You could take a look in the content repository with the repository browser to see the relationship between parent and child elements, this would help to understand my description.

[rbitdd]

That means that moving an element in the pagestore make a new release of the parent folder absolutely necessary. I hope that I can explain this to my customer...

I ask myself what might happen if I would release testFolderTwo and not testFolderOne. Then would testPageOne be child of two Elements at the same time in the release store...

And further which is the parentID of the testPageOne?

[Hendrik]

It is very important that an element has always a valid parent, which means the whole parent chain elements relationships must fit togehter. Or in other words, the elements reachability in the release store has to be guarantee. If a parent in the release store contains invalid child elements ID entries the effect is not as fatal as elements without valid parent ID because only a warning appears in the generation log..

We wrote a lot of precondition checks in our project to avoid described inconsistency in the parent / child relationship.. I hope you don't have to

Back to you sample: Check it out which ID the method getParent().getId() after releasing testFolderTwo will be returned, I mean it's already the ID of the new parent.