Hi,

This is indeed an interesting case. For Commerce 9+ the unpublished node might not be in CatalogNode table and therefore referenceConverter.GetContentLink(code) do not return it. I'll file a bug to see if we should do something about this - but no promise (about it'll be fixed).

Regards,

/Q

Thanks Quan!

Hi,

I have time to check this issue today and it seems that for entirely new node or entry, that code should still work (the data is saved to CatalogNode/CatalogEntry table). However if you have a published node and then create a draft version of it then it does not work - is that the scenario you mentioned? 

/Q

Hi,

Yes, I think the issue has to do with the draft version.

Just did some testing on my own and this is the problem:

I create a new node and save it. The node gets the code "Gratis_1". I look in the table CatalogNode where Code = 'Gratis_1' and I get a hit. So far all good.
Now I change the code to "123456" but the node in CatalogNode table is not updated. I still find a row with Code = 'Gratis_1' but no node with '123456'.
I then publish the node and then I find a node with the code '123456'.

I tried to change the code on a already published node and the problem is the same so it has nothing to do with if the node is published or not.

So I guess that the problem is that the CatalogNode code is not updated before you publish your change. Maybe it is a bit more complicated then. I mean before you publish your change on a pubilshed node the code should still be the old value, but if the node never has been published the code should update right away in the table.

Do you agree, or maybe I'm missing something?

Thanks for your time Quan!

/Kristoffer

Hi guys,

Sorry for jump in but just want to confirm that I can reproduce the problem as Kristofer said in comment above now.

@Kristofer: The point "if the node never has been published the code should update right away in the table." is make sense to me but maybe we need some more discussion to decise should we go head with this way or not. We will let you know then.

Thanks for your detail info.

/Ba

Hi Ba!

Thanks for your input. Looking forward to hearing from you.

/Kristoffer

Can describe the use case where you need to do this? Where do you get the code you want to resolve from?

Thanks,

Magnus

Hi Magnus!

So what happens is this. Our customer has an ERP from where we they import all their products. Every product has a category code which should match the code on the node in Episerver.
Before they publish the node and the products underneith they want to se what it looks like on the web so they create a new node and change the code without publishing it, and then start the import job. Since the code of the Episerver node is not changed before it is published the products cannot find their nodes when being imported so nothing is being imported.

The problem is that when the node is published it is pushed into the search engine and you can search for the node and also it is shown in a megemenu.

Of course there is many ways to solve this by adding a property to the node "Don't show in megamenu", "Don't index" and so on and that we could easily do. Or you could publish the node and then change the "Start publish" date so this is not a big problem. I just want you to analyse the problem and decide if this is a bug or something you have to live with.

Thanks Magnus, let me know if you have any more questions.

/Kristoffer

Thanks for the quick response and detailed explanation.

While your use case is very reasonable, changing the behavior to support it isn't as simple as it might first appear.

At first it seems reasonable to update code (or perhaps all properties) in the main tables whenever a draft (not-yet-published) content is saved. But it creates a number of hard to solve problems, for example what to do if there are multiple drafts for the content.

Another approach is to expand the code-to-contentlink resolving to include drafts. But it leads to similar issues - should it match any draft, the latest draft, the common draft? What if multiple content have drafts matching the code? Do we need to enforce uniqueness of codes across published as well as unpublished content?

So we're still debating if we can/should fix this.

The import code, is that a custom implementation? If so, can't that create the node with the correct code when importing the entries? It can create the node as not published/active.

Another possible workaround is to override the Code property in your node content type, and make it required:

public class MyNode : NodeContent
{
    [Required]
    public override string Code { get; set; }
}

This will make it appear in the create screen in the UI and give a chance to set the code. This initial change will be propagated to the main tables and work as you expect in the import. 

Thanks Magnus!

A lot of good tips there and yes it is a custom implemention.
I think I will go for the override-required fix. That will absolutly solve the problem with out affecting anything and that only requires a few lines of code.

I see, there are a lot of problems to solve here for you and I can easily fix mine so maybe you just should let it be? :)

Looking forward to hearing you descion.

/Kristoffer

Hi Magnus!

Almost...
No a big issue, but I override the Code and set the property to [Required]. When I create the node The Code field is shown, but it is not a textbox instead it is a "Change" text.
I if press "Change" text textfield is show and the field is validtated as required, but if I don't press "Change" I can create a node without adding a code and the node gets a generated code.

This is not a big issue for us, just explain for the editor what needs to be done but maybe this should be considered as a bug since you can create a node without entering a value? I'm not sure.

Thanks again!

/Kristoffer

Thanks for the feedback. It can probably be considered a bug even though the interaction pattern is a bit off, simply because a property editor like this is not supposed to be used on the required field screen. I'll log the bug and we'll see.

Meanwhile, as a workaround, you can add another attribute to kill the "PreviewableText" editor type and revert it to the default textbox: Just add [UIHint("")]. This is probably better UX in your case as well.

Works like a charm, thanks again!