[MAGNOLIA-1263] links are sometimes resolved wrongly after a move of a page (session is not updated) Created: 08/Dec/06 Updated: 23/Jan/13 Resolved: 06/Nov/07 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | templating |
| Affects Version/s: | 3.0.1 |
| Fix Version/s: | 3.5 RC1 |
| Type: | Bug | Priority: | Critical |
| Reporter: | Philipp Bärfuss | Assignee: | Philipp Bärfuss |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||
| Date of First Response: | |||||||||
| Description |
|
This dosn't happen regularely, but it can happen that after a move of a page the link is still pointing to the old place. This is obviousely a session updating problem and needs some investigation. In case this happens a restart of the container heals the system. In case you can't do this you can copy the page instead of moving (ugly but working) |
| Comments |
| Comment by Chris Allan [ 08/Dec/06 ] |
|
Just to clarify, to those that it does happen to, it does happen regularly. It is 100% guaranteed to happen!!! |
| Comment by Chris Allan [ 08/Dec/06 ] |
|
And just to further clarify, the problem does not only apply to existing links not getting updated. If, following the moving of a page, you try and create a link to it, the new link will point to the old page location. |
| Comment by Chris Allan [ 08/Dec/06 ] |
|
Hmm, on second thoughts maybe my first 'clarifying' wasn't perfectly clear. When I said 'those' that it happens to I mean those people that it happens to, not those pages i.e. it does happen to me, and it does happen with every single page that is ever moved. |
| Comment by Philipp Bracher [ 08/Dec/06 ] |
|
Does closing and reopening the browser help? |
| Comment by Chris Allan [ 08/Dec/06 ] |
|
Not in the slightest, neither does clearing out all the cache or any other files. |
| Comment by Philipp Bracher [ 08/Dec/06 ] |
|
This implies that the system session is not updated. Thanks for the information. |
| Comment by Philipp Bracher [ 15/Dec/06 ] |
|
Can you execute this page, after the problem occures. put the file in the docroot and call it directly |
| Comment by Philipp Bracher [ 09/Feb/07 ] |
|
Some more news about this issue. I run into the same situation and was able to debug a bit. The situation occured after:
In the text the correct link tag was saved (maux-de-gorge) <a href="${link:{uuid: {311af940-...},repository: {website},workspace: {default},path: {/ch/fr/news/maux-de-gorge}}}"> the uuid is correct and the fall pack path too (maux-de-gorge) Since for saving the user session is used, this is not a surprise. Then I run the attached jsp to check if there were any pending changes: No there weren't Now I created the following code: Content node = MgnlContext.getSystemContext().getHierarchyManager(repository).getContentByUUID("311af940..."); node.getParent().refresh(false); node = MgnlContext.getHierarchyManager(repository).getContentByUUID("311af940..."); The result was: /ch/fr/news/halsschmerzen So we can finally say that:
Conclusion
Hint:
|
| Comment by Philipp Bracher [ 06/Nov/07 ] |
|
we had no such experiences anymore with jr 1.3 |