Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content Templates does not trigger generation of new Keys #13698

Closed
nielslyngsoe opened this issue Jan 18, 2023 · 5 comments
Closed

Content Templates does not trigger generation of new Keys #13698

nielslyngsoe opened this issue Jan 18, 2023 · 5 comments

Comments

@nielslyngsoe
Copy link
Member

nielslyngsoe commented Jan 18, 2023

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

10.4

Bug summary

When a document containing a Block Grid Editor is created as a Content Template.
And this Content template is used to create documents. Then the Blocks does not get new keys, which it should. cause we use the key for some caching. So first cached data will affect the others.

See the original issue reported here:
umbraco/Umbraco.BlockGrid.Example.Website#6

Specifics

No response

Steps to reproduce

Setup something with Block Grid Editor, I would prefer something that is nested.
Make a Content Template from it.
Create two pages based on the content template.
View the first page, in backoffice, and inspect Network traffic.
Retrieve the ContentUDI of the first layout item, of the Property Value.
Verify that the other page created from the same Content Template got the exact same ContentUDI in their.

I would expect that every Document created from a Content Template got new ContentUDI.

Notice the ContentUDI is referenced between items of layout and data.

The same goes for SettingsUDI. but that is referenced between layout and settingsData.

Notice:
This does not happen then Copying documents, but to me the Create from Content Template feature should be using the same features as the Copy Feature.

Expected result / actual result

I would expect that every Document created from a Content Template gets new ContentUDI and SettingsUDI, that has to happen for all Blocks and the data of them, no matter the amount of nesting.

@elit0451
Copy link
Member

As Niels said, copying a document created from a content template updates the values correctly (even for the nested blocks - ex: each block from the Two Column Layout has a different contentUdi than the blocks in the original content node).

A few more notes:

  • To see the contentUdi in the Network tab, check the response from umbraco/backoffice/umbracoapi/content/GetById:
    • inside variants[] > expand an element
    • inside tabs[] > expand an element
    • inside properties[] > expand your block grid property (where editor: "Umbraco.BlockGrid")
    • expand the value of value
    • expand the value of layout
    • and you will see the contentUdi of the element - those should be different for the different content nodes

  • To check the contentUdi of the nested blocks (ex: each block from the Two Column Layout):
    • Continue from above ⬆️
    • inside areas[] of the element which contains the contentUdi of the block grid > expand an element
    • inside items[] > expand an element
    • and you will see the contentUdi for each nested block - those should also be different for each content node made from a content template

Most likely, fixing this issue would provide a guideline on how to fix #13413

@jerpenol
Copy link

jerpenol commented Mar 2, 2023

This issue is now tagged with affected/v11 and affected/v10, but as mentioned in #13901 this also occurs on 8.17.0

@nikolajlauridsen
Copy link
Contributor

I've added the tag now, that's an oversight, sorry about that 😅

@jerpenol
Copy link

jerpenol commented Mar 2, 2023

@nikolajlauridsen No problem at all! Thanks for adding the tag :)

@Zeegaan
Copy link
Member

Zeegaan commented Jan 10, 2024

This should now be fixed in #15541

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants