[MGNLSTK-1259] Bootstrapped demo content is missing auto generated areas Created: 25/Oct/13  Updated: 07/Nov/13  Resolved: 30/Oct/13

Status: Closed
Project: Magnolia Standard Templating Kit (closed)
Component/s: demoproject
Affects Version/s: 2.6.1
Fix Version/s: 2.6.2, 2.7

Type: Bug Priority: Critical
Reporter: Federico Grilli Assignee: Jozef Chocholacek
Resolution: Fixed Votes: 0
Labels: regression
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Date of First Response:
Sprint: 5.1.2

 Description   

To reproduce

  • dbl-click on a leaf page (one w/o children) in website
  • w/o doing any change, go back to the tree view
  • you'll see that the modification date has been updated and the page status is now modified.
    The issue seems to affect only leaf nodes. It was introduced in 5.1.1 (I checked 5.1 and that is OK)

A little debugging showed that the issue seems to be in info.magnolia.jcr.wrapper.LastUpdateNodeWrapper.addNode(String, String) starting at line #210
where the code reads

if (RepositoryConstants.WEBSITE.equals(this.getSession().getWorkspace().getName()) && NodeTypes.Page.NAME.equals(primaryNodeTypeName)) {
            // no LUD update on adding subpages
        } else {
            this.updateLastModified();
        }

while primaryNodeTypeName is mgnl:area (a non optional area is auto created). The reason why this happens only on leaf nodes is probably that pages above in the hierarchy are bootstrapped with those areas already created.



 Comments   
Comment by Jan Haderka [ 25/Oct/13 ]

Affected pages are not leafs but all pages that have auto generated areas that we're not generated before activating the page. This problem stems from the fact that many such areas were defined only after pages were created and status was set to activated on author instance. The fact that page status changes to modified is correct since page structure is indeed different between author and public. Even when page is opened also on public and area or component is generated it will be generated with different uuid. However to prevent such confusion demo project content should be indeed red ported with auto generated areas already created.

Comment by Christopher Zimmermann [ 28/Oct/13 ]

Is this a typo? "However to prevent such confusion demo project content should be indeed red ported with auto generated areas already created."
This should be "content should be indeed re-imported" right?

Comment by Christopher Zimmermann [ 29/Oct/13 ]

Agreed in meeting with Daniel, Philipp, Tobias that the demo project files should be updated so that all auto generated content is generated and in published state.
Probably this will involve:

  • Running system with STK.
  • Use something to crawl the system to trigger all pages to generate their auto-generated content. (like wget)
  • Activate all content so that it is "green".
  • Export new bootstrap files.

Ideally also code generated content will also be activated - investigate how the dynamically generated events pages in the demo project are created.

Comment by Jozef Chocholacek [ 30/Oct/13 ]

I have fixed the bootstrap files. Anyway, there are still those dummy events, that are generated on module installation. They could be fixed by creating the required (autogenerated) area subnodes like metaNavigation, extras etc. during the installation, I am just not sure it's worth the effort (such areas would have different UUIDs on author and public, just as the dummy events have).

Comment by Christopher Zimmermann [ 30/Oct/13 ]

As the symptom we are attempting to solve is the bizzare behaviour that just openeing a page in the page editor causes it to be modified and the activation state to change - I think its still work correcting this behaviour for the dynamically generated events as long as its not too much work.
It will create a better impression on users getting familiar with the system in that they will not be confused by this unforseen behaviour.

Generated at Mon Feb 12 07:34:52 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.