PerplexDigital / Perplex.ContentBlocks

Block based content editor for Umbraco
MIT License
31 stars 15 forks source link

Accessing a (header) content block that is on a duplicated page through the published content cache causes it to return the original content block #64

Closed royberris closed 2 years ago

royberris commented 2 years ago

Accessing a (header) content block that is on a duplicated page through the published content cache causes it to return the original content block.

When you have a header block on a page, and you duplicate the page. The header block on the duplicated page has the same key as the header block on the original page. This only seems to happen when you get the content of the content block through the published content query. Same thing happens when you create a page from a template where a header block is present.

For example: We have a overview page which has children using content blocks. On the overview page list items we get the title and intro text that is in the header content block to display this on the list item in the overview page. If I render the header directly from the page itself, that is fetched from the published content request, there is no problem.

For example:

var overviewPage; // overview page node;
var children = overviewPage.Children();
foreach (var child in children)
{
  var heroElement = child.ContentBlocks.Header.Content;
  // The heroElement.Key now has the same value for pages that are duplicates or created from templates.
  // The values of the hero element are the same as the original content.
}

In above example any changes to the original element will reflect in to all the duplicates. So if I would get the 'Title' attribute and change that on the original node. It is reflected back in to the duplicated node. (Probably because they reference the same item in the database?).

Workaround So to fix this there is a workaround I found. If I go to a duplicated page, copy the hero content block. Remove the content block. Save and publish. Paste the content block back. Save and publish. The hero now has it's own key. Navigating to it from the example above now is no problem.


I'm not sure if this is a Umbraco bug in duplication or if this is a Content Blocks bug. I'm guessing the second, but might have something to do with Umbraco's logic when duplicating?

I'm running Umbraco 9.5.3 with Content Blocks 2.1.4

PerplexDaniel commented 2 years ago

How is the page duplicated? The entire node is copied in Umbraco I assume? There is code in place (see here) that handles copied nodes (using Umbraco's ContentCopyingNotification) and updates all Content Block keys of the header and blocks.

We perform similar logic when you copy a block client side within the ContentBlocks UI, that happens in Angular but has the same effect -- the copied block is assigned a new key.

I will have to do a test locally to see if the notification handler is perhaps not triggered. I'll get back to you probably next week though, not sure if I have time today.

To make sure I test the same thing, you copy a node by using Umbraco's "Copy" feature right?

image

PerplexDaniel commented 2 years ago

@royberris

I just did a quick test in a test website running 9.5.3 ContentBlocks 2.1.4 and when copying content nodes containing only a header block via the UI I see the Key property of the header block is unique on every page. I run the same foreach loop as you posted and see different GUIDs.

If you can post the steps to reproduce this I can have another look. Make sure to include how the nodes are duplicated (UI / IContentService, etc).

royberris commented 2 years ago

@PerplexDaniel we might've had some miscommunication with the client about how they created the pages. They are apparently created from a template which has the content blocks prefilled on it.

PerplexDaniel commented 2 years ago

Closing this then as it seems like a different issue. If you think we can support the template scenario in some way in the package please create a new issue.