Umbraco-CMS
Umbraco-CMS copied to clipboard
Block list very slow to / fails to render labels when using {{ propertyName | ncNodeName}}
Block list very slow to / fails to render labels when using {{ propertyName | ncNodeName}}
Umbraco version
I am seeing this issue on Umbraco version: 8.12.2
Reproduction
Bug summary
When using the block list with a block that contains a multinode tree picker, I want to display the name of the selected node on the block, similar to if I had used the multinode treepicker directly and allowed multiple items. The node name on each block either loads very slowly or does not load at all.
Specifics
Google Chrome on Windows - latest
Steps to reproduce
Create a document type with a block list editor property.
The block list editor contains one block with a multinode treepicker on the content model with alias = article.
The block has the label expression
{{ article | ncNodeName }}
Create / publish the above then add multiple items to the block list editor.
Expected result
Labels should reliably and quickly update to show the name of the article selected on the content model.
Actual result
Label fails to load or loads on the order of minutes the name of the article selected on the content model.
This item has been added to our backlog AB#21097
Thanks @nzdev, not sure where this is coming from. I am assuming you have a large amount of content?
@nul800sebastiaan I do have a large amount of content, however the multinodetreepicker loads multiple items quickly. I think the blocklist is loading one item per request.
Sorry, I meant of course to ask if you have many blocks! But yes I suspect the number of requests are not very optimized,
About 10 blocks
Hi @nzdev I'm trying to do a very similar thing to you where I have a block type element containing a multinode treepicker but I can't manage to render the contents of the treepicker. Could you show me how. I realize this is not specifically what the issue is regarding but I just can't find anything else through searches.
Thanks in advance.
@mrgiao There is a label field on the block editor definition. If you use "{{ propertyName | ncNodeName}}" as the label and replace "propertyName" with the name of the property containing the multinode tree picker it will then work, sometimes.
On topic, I worked around the slowness/reliability issue by making our own ncNodeName and set a config property in EditorModelEvents which is a cache of the names of all the contents, then read this cache first in ncNodeName directive.
I'm also seeing this v8.15.0.
I have a Multinode Tree Picker that's limited to a max of 1 item, the label for the Block List Item is Testimonial Quote | {{testimonial | ncNodeName}}
, the label name never seems to load if I just sit and wait for it.
Interestingly, I've noticed a couple of quirks:
-
If I click into a different content node, from the Tree, and then click back into the content node I was originally on, the label loads instantly.
-
If I add another one to the block list, then the one that's in a nested list loads instantly, but the "outer" one does not.
-
The labels load in when I drag/drop to reposition the blocks.
Hiya @nzdev,
Just wanted to let you know that we noticed that this issue got a bit stale and might not be relevant any more.
We will close this issue for now but we're happy to open it up again if you think it's still relevant (for example: it's a feature request that's not yet implemented, or it's a bug that's not yet been fixed).
To open it this issue up again, you can write @umbrabot still relevant
in a new comment as the first line. It would be super helpful for us if on the next line you could let us know why you think it's still relevant.
For example:
@umbrabot still relevant This bug can still be reproduced in version
x.y.z
This will reopen the issue in the next few hours.
Thanks, from your friendly Umbraco GitHub bot :robot: :slightly_smiling_face:
@umbrabot still relevant This bug can still be reproduced in version 9.4.0-rc
gif:
My test blocklist item contains a Multinode TreePicker that's limited to 1 item.
The block label:
It seems to fail to load the ncNodeName
on the initial load of the content item, but clicking onto another content node and back causes it to load.
FYI, the "loading" is nicely replaced with the name of the node, once the containing page is published... But still annoying to have to press "Save & Publish" to have the labels update..
We're experiencing this issue in 9.4.3
As the ncNodeName filter makes a server request to retrieve the name, the value 'loading...' is returned. This filter has no mechanism to update the label, which means that though the request is complete slightly after, the UI is still stuck with 'loading...' This then works the second time the label is written/updated as the name is cached and therefore it can be returned instantly from the filter.
If this worked well in Nested Content it must be because Nested Content updated the labels offen. This is not the case in Block List Editor as the label only updates when there is a change of some sort, like sorting or Save & Publish.
I'm not sure if a filter can be made so it triggers an update, but this would be needed for such to work well.
This issue is also present in Umbraco v10.0.1.
So I might have a solution for the use-case of {{ propertyAlias | ncNodeName }}
; the issue seems to be that block labels are interpolated, and they are only interpolated once in their lifecycle. This might have been working differently in v8, but at least in v10 this is what I'm seeing.
First and foremost it is possible to mark a filter as $stateful
, which is easy, but the label is still interpolated and it needs to be compiled instead. This can be done by adding a new directive that creates a new scope and uses the $compile
service.
It could still be a problem in the property editor overlay, where you can't run $compile
but I think it's okay to use $interpolate
here at least since the node name would already be cached. If you select a new article, the title won't be updated until you reopen the dialog, but I think that is an okay tradeoff:
I'll try and create a PR on my working branch.
A fix has been merged into the v10/dev channel and is being considered for 10.2 or 10.3. Thank you everyone for your feedback with this issue!
Fixed in https://github.com/umbraco/Umbraco-CMS/pull/12909