Feature Request : Use the reference tracking to provide a better editor experience

[dawoe]

With the release of 8.6 media tracking was introduced. But the backoffice UI could do with some improvements to provide a better experience.

Since I have a popular package (Nexu) that does the same so tried to see how it lines up.

Having tested it noticed that also content usage is being tracked, not only media.

On a media item you can see where the item is being used

But on content this information is missing. And it is useful there as well.

Another great feature I have in my package is that when editor tries to delete or unpublish something he or she get's warned that the item is in use, with a list of where it is being used.

This is completly missing in backoffice at the moment. So a editor can still delete stuff and potentialy breaking his website.

How can you help?

I think these problems can be tackled in a serie of small pull requests.

1. Display the references on a content item
2. Warn a editor during the deletion of a media item.
3. Warn a editor during the deletion of a content item
4. Warn a editor when he tries to unpublish.
5. Implement step 2-4 for bulk actions in list views

I don't think the references need to be shown in the dialogs for unpublish/delete because the list is available on the info tab.

When we have this in place we can think about future features like when a user wants to delete a image, let him choose a new image that should be used instead.

But I would like to hear if HQ is open for this before doing any effort on this.

TODO List

• [x] https://github.com/umbraco/Umbraco-CMS/issues/8692
• [x] https://github.com/umbraco/Umbraco-CMS/issues/8699
• [x] https://github.com/umbraco/Umbraco-CMS/issues/8693
• [x] https://github.com/umbraco/Umbraco-CMS/issues/8694
• [x] https://github.com/umbraco/Umbraco-CMS/issues/8695
• [x] https://github.com/umbraco/Umbraco-CMS/issues/8696
• [x] https://github.com/umbraco/Umbraco-CMS/issues/8697
• [x] https://github.com/umbraco/Umbraco-CMS/issues/8698

Update Until we are feature complete al the PR's will be targeted at v8/item-tracking branch. Once everything is done this can go into v8/contrib

Dave

[nielslyngsoe]

Hi @dawoe

If we already have trustworthy data about the references I don't see any reason why we don't show this. And use it to warn users about the references when unpublishing or deleting content.

But I have to underline that it requires that the data is trustworthy, we need to make sure that we have all types of references gathered, otherwise, it will act as a false safety. :-)

But with that said I will go ahead and say that PRs for such improvements are very VERY welcome!

I think for a start it will be good if you split the request up into the different pieces that you see are needed to ensure a good experience, and then we can have more specific conversations in each of these.

For a start I will add a few notes on top of my head in regards to the 5 topics:

1. Display the references on a content item
   • Super good, this can be part of the Info-tab
2. Warn a editor during the deletion of a media item.
   • Yes, why don't we do this already? :-P
3. Warn a editor during the deletion of a content item
   • Yes, this will be great.
4. Warn a editor when he tries to unpublish.
   • Yes, I see a few details that we can specify as the PR comes together. My main thought is how this will work in terms of Variants since the references are on node-level, right?. not because I think that will have a huge effect, but we might need to have a less aggressive dialog in this scenario, as there might be a fallback version available and therefore it's not that bad if the content is removed/unpublished. Maybe the reference even comes from a varying property in a German variant meaning that if the user unpublishes the referenced Danish variant it's not that relevant to notify the user about this reference.
5. Implement step 2-4 for bulk actions in list views. Yes, very important, even more important in this context since the user is less aware in this higher context.

We should also make sure to check references from child content-nodes, I guess that's a general thing for the above topics.

Thanks for your awareness, this will improve life for editors massively as it will provide trust to the features.

[dawoe]

Hi @nielslyngsoe

Regarding to variants and child nodes. I have both things in place in Nexu. So I can see what we can take from there.

I'll split up in smaller issues now that I have the green light.

Dave

[nzdev]

@dawoe I think the built in tracking only works for content/media that has been saved since the media tracking feature was implemented vs Nexu works on existing content as well. Umbraco may need some sort of rebuild the tracking similar to Nexu for this to be really useful for older, large sites.

[dawoe]

Hi @nzdev

Good point. Did not know that. I will check if it is actually the case. Otherwise a dashboard could come in handy do rebuild the tracked relations. Like I have for Nexu

Dave

[nzdev]

Hi @dawoe,

Agreed. I think it's quite important as not every relation may be currently trackable. As new parsers/data types are created there is a need to rebuild the tracked relations, so even a new site starting on 8.6 may be missing relationships.

I'm quite keen to see this done as it could be paired with a sort of lazy load for media that is not currently in use. Typically content is unpublished and the media it was referencing is still loaded at start up. Tracking paired with a policy on what to load lazily vs at boot could make a big difference for some sites.

[nul800sebastiaan]

Hey ho @dawoe!! Great ideas and a lot of issues you're generating from that, I'll label them all as part of the same project. I will need to talk to some people at HQ to see how far we want to take this and then I expect I can encourage small PRs to come in indeed (I don't see any objections, just want to double check).

[dawoe]

I tried to give it a go for the first item on the list. Seems everything is tied to media now for displaying in the backoffice. So the first step is to decouple that for easier development of the other features.

[filipbech]

This looks great! Thanks for all your work!

[hartvig]

This is amazing, Dave. Would be wonderful to get in the core.

[dawoe]

During testing of the PR by @poornimanayar she discovered that current tracking of references does not take variants in to account. Making it hard to show to editors in which variant it is used. This can become a issue in sites with multiple languages and possible segments. Maybe this is something that needs to be changed in core.

I see 2 possible solutions

• Extend the relations table and api to be able to store culture and segment variants
• Move away from the relations to store this references.

Probably something we can improve on as we have the UI parts in place. Probably will need some guidance on that from @Shazwazza on how to proceed.

[dawoe]

In my nexu package it was easy for a editor to see for a editor in which variant and even in which property the link was made. In my v7 version I misused the comment field in the relation table for this. For the V8 version I moved away from relations and had my own tables to store the information

[melvinvanrookhuizen]

If I can help out on testing the package and providing editor experience on using it, I am here. Just let me know.

[nul800sebastiaan]

As you have noticed from the feedback we had a chat at HQ about this and would love to encourage this one! I will mark the related issues as up for grabs as well.

I can't tell from your latest comments if you're completely stuck right now? Let us know and I'll see how we can get you some help with moving it forward. 👍

[dawoe]

Hi @nul800sebastiaan

I can proceed now once PR #8703 is merged. That contains the work I need to build upon for the other issues.

We can update what I'm going to build to take multi language variants into account when core is ready for that. See the comment from @Shazwazza in the PR.

Dave

[poornimanayar]

@nul800sebastiaan @Shazwazza I have tested the media tracking and it works for non-variants but not for variants. I have not tested content tracking yet but can test that. I believe @dawoe needs the API controller he developed in #8703 to do the next set of changes. Given that the content and media item tracking does not work for variants can we segregate the API alone out into a separate PR? What do you think?

[dawoe]

Hi @poornimanayar

I think it's best that I can proceed with my UI enhancements, but I need the first PR to be merged to be able to continue with the next set.

I think we can update the work I have done and will do once variant tracking is supported in core.

Dave

[kmeilander]

Is this feature still being worked on? I've been trying to figure out if there is away to show everywhere a content item is referenced, and so this is exactly what I need. However it looks like this was never finished for some reason. Was there a blocker that came up or something, or did it just go stale?

[umbrabot]

Hiya @dawoe,

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: