Relations Only Save Format

[Hendy]

Since changing the relation mapping behaviour in v1.5.0 the Relations Only Save Format no longer works (see:http://our.umbraco.org/projects/backoffice-extensions/nupickers/questionssuggestions/66666-dotnetcheckboxpicker-relation-mapping-does-not-work#comment-222190)

[dgx]

There is still a bug here. Saving once properly saves the relation, but saving again removes it.

"picker.SavedValue" is null on the second save, causing the relation to be removed.

[Hendy]

@dgx thanks for the feedback 👍 I'll investigate again (pretty sure I had tested multiple saves)

Arh I think I know what's happening, because the value is wiped, if the item is saved again without the picker being changed then the value stays empty, and the server side event will wipe the relation. Perhaps the fix is to force the save value to be set on load.

[torleifhalseth]

I'm experiencing the same issue. Did you get the chance to look more at this ?

"Save and Publish" and "Save" both creates and keep existing relations . "Publish" removes existing relations.
Publish removes existing relations because property is null when retrived at event handler.
It looks like the "Publish" action in umbraco runs this action. Because the "relation only" doesn't save any data to the node the "relationProperty" is null.

I could not find any solution to this problem because i dont know what triggered the "ContentService.Saved" event. I thought i might retrive the node relations through the relation service and add it to the published node if the event triggering ContentService.Saved was "Publish".

Any ideas @Hendy?

[aztekweb]

We're also seeing this issue. Hoping to see it resolved as it's a great feature.

[dnwhte]

Any movement on this issue?

[Hendy]

Hi @danwhite85, thanks for the reminder - hopefully it won't be too tricky to fix - as above, we could always re-inflate the value so that it's saved then wiped - or perhaps, always save the value,and just ignored it when querying ?

[enkelmedia]

@Hendy could we help in some way? I would love to solve this asap.

[mrflo]

Hi I got the issue as well with the XmlPrefetchListPicker. Did someone find a solution ?

[torleifhalseth]

Any luck solving this issue @Hendy?

[alecrt]

Any news on that?

[pantryfight]

Hi folks, just wondering if there's been any movement on this and/or when the above fix might see it make it's way into a release? One of my clients is having big problems with this. If push comes to shove I'll write my own property editor to solve their problems but I do like me some nuPickers. :) Thanks for all your hard work.

[Hendy]

Hi @pantryfight I'd like to be able to fix this as soon as possible (as it's a significant issue), but I think we still need to figure out exactly how relations should be working to be able to refactor, so unfortunately I can't give you a date / time, other than in the next release.

@vnbaaij has submitted PR #105 as a quick fix (but ideally we would rather not have to save the value)

Do you have any thoughts on the best approach to fix ?

Thanks,
Hendy

[hfloyd]

Several days ago in a separate thread, @Hendy suggested that perhaps the solution would be to run the original AJAX save routine UNLESS it is a new node (Id=0), in which case, the newer server-side routine would handle it. (#130 (comment))

So, for those of you on this thread with some skills & time, perhaps you can investigate that possibility? I'd look into this, except that I'm not as familiar with the internals of how the AJAX used to run, so someone else would probably be able to fix it quicker than I right now :-)

Incidentally, I have a site going live within the next couple weeks that has this serious problem, and if I can't figure out a reasonable solution very soon, I'll have to re-work this relation to instead be a MNTP. I'd rather not, but data stability is critical, after all.

I wonder if I change the picker to use a "Save Format" other than "Relations Only" - will that fix the issue? (Since the picker wouldn't be showing as "NULL" on content-node save?) Does anyone have any experience where that was NOT a good idea?

Thanks, everyone!

[vnbaaij]

@Heather the problem with the server side code is that it performs a save of the content node for every picker property in th doctype. Not only slow but also leaves the node in an incorrect state after saving. My pr disables this behavior. It does however duplicate the data saved: once as csv in the property and a record for every relation selected. Something we can live with very well in our solution. We don't use the csv value in our rendering, but use the relation data for that

[hfloyd]

@vnbaaij : I'm not the one best positioned to make a decision on the right fix for this issue, since I'm not familiar enough with the code. I just wanted to reference @Hendy's latest comments about it, to keep the conversation moving. Thanks for your contribution.

[simoazzo]

I encountered the problem with the latest release, where for the first initial save is alright but when deleting and modifying, it is not working well, related to relationships.

Any idea when this fixed will be soon fixed?

Thank you.

[simoazzo]

Hendy,

When the next release will be issued?

[simoazzo]

Hi,
May I ask when this bug issue will be solved please for the next release?

thank you.

[Hendy]

Hi @simoazzo, unfortunately I've not spent any time looking at this issue recently - is this something you could help solve ?

Thanks,
Hendy

[simoazzo]

Hi Hendy,

I wish that I can help, but I don't have so much time to fix it. As I seen above, the issue has been for a long time but I don't know exactly what is happening. For an older real ease everything is working fine, but the latest relaxer no. There is something wrong when edit or delete relationships.

I would be very happy if you can sort this out, because as you said in the previous posts, it is a significant issue..

thank Hendy.

Appreciate.

Kind Regards

[simoazzo]

Hi Hendy,

Are there any updates on this please?

thank you

Kind Regards

[Hendy]

Hi @dgx @thalseth @aztekweb @danwhite85 @enkelmedia @mrflo @alecrt @pantryfight @hfloyd @vnbaaij @simoazzo Sorry it's taken so long to fix this ! but it'll be out in the next release (v1.6.0).

(You can also find it in the latest prerelease, which also includes the caching of picked 'relation only' values so there's no subsequent db hits on the front-end)
NuGet Package:
Umbraco Package (zip file):

[alecrt]

I still have problems with LucenePrefetchListPicker and Relations Only save format.

In the backend I have a list-view of nodes each with a property of type LucenePrefetchListPicker - save only format.
When I edit one of them and then press Save & Publish button, the page seems to be saved and published correctly but if a look back in the list-view it's only saved but not published. If I take a look at the public published page, in fact, changes are not visible.

If I then publish the page directly from the listview, the publish process works fine, all changes are reflected except the LucenePrefetchListPicker property data which is wiped out.

Any ideas?

[Hendy]

Hi @alecrt I'm not sure I understand the issue you're having related to nuPickers - when using the Relations Only save format, the saved data is indeed wiped (this is to avoid having duplicate data which may become stale - the main source of the data for all pickers of this type is then the relations data, and not a local saved value).

[Hendy]

@alecrt I should add, that to retrieve the values, you can let the PropertyValueConverter handle returning a Picker obj for the current context (which you can then use the .PickedKeys property), or you can create a Picker obj using the extension method in nuPickers.Extensions on IPublishedContent. eg. content.GetPicker("alias"); or you can create a Picker obj with new Picker(id, "alias");
HTH, Hendy

[alecrt]

Hi Handy,

thank you for your fast reply. The problems i have are two:

• the first one is ralated to publish. I can't publish a page with a property of type LucenePrefetchListPicker - save only format from page edit-form. As I said no error appears, but the page seems only saved and not published to the xml cache.
• the second one is publishing from outside the page itself: i.e. from the listview. In this case publish works fine BUT the relations are removed from umbracoRelation table.

[Hendy]

1. when you save and publish are other property editors saving to the XML cache ? (the LucenePrefetchListPicker in Relations Only save format, will not save a value locally into the XML cache), so I'm not sure on the issue here.

2. this sounds it could be an issue with nuPickers (I've never tried relations only in a list view, but can't see what difference this should make - as I'd expect the same save event with same parameters). I'll setup a test and investigate.

[alecrt]

1. yes, DB speaking: all other properties has been saved correctly in CmsContentXml table and versionId matches the latest cmsContentVersion for the node. What it's weird is in cmsDocument table: the newest version IS NOT the published one. Like the node was only saved but not published.

2. Thank you!

[Hendy]

1. so this is expected behaviour then ? as Relations Only does not save a value, but queries relations for its data.

[Hendy]

Hi @alecrt I've just tried a test for 2) an Xml CheckBox picker using Relations only on items within a list view, and it is working as expected regarding the data - although the UI does indicate that the item was saved, and not published (the green overlay icon), but this appears to be an issue outside the scope of nuPickers.

Can I ask which version of Umbraco you are using ? (I've just tried with 7.5.13)

[Hendy]

Arh, yes there is an issue with publishing again on the item when in the listview and the value being cleared. This is because, normally when editing an item with Relations Only, the value is populated on load, so that when it is saved, the relation can be updated, and then the value cleared, but.... because the list view doesn't actually open the item, the value isn't set - the only way I can think of resolving this is to store a value locally rather than wiping it. (wanted to avoid storing a value, as this could become stale). Perhaps instead we could store an value to indicate that 'hey this hasn't been set yet' so the server side event can then ensure existing relations are kept - it's currently seeing an empty value, so thinking the user has removed selected options.

However the issue of saving and not publishing when editing the item within a list view appears to be an issue with Umbraco.

[alecrt]

Hi @Hendy,

thankyou for your little investigation. I'm on Umbraco 7.5.11.

What's strange is that the issue of saving and not publishing in my environment is not happening from the listview but from the inner edit-page "save & publish" button.
One more side note: If I remove the nupicker property from the document type, save and publish works fine.

[Hendy]

@alecrt I witnessed the same thing - save & publish inside the inner edit page - perhaps it's because the picker says "my value is x", click "save & publish" and then an event in nuPickers will read the "my value is x" update the relations data, and then remove the "my value is x" - so Umbraco then sees that the value has changed, so thinks the published version is different to current.

A way to resolve this may be to store a value that isn't wiped - trouble is this value needs to be identifiable as a token specific to nuPickers, but in such a way that a regular csv format doesn't think it's a regular key.

[alecrt]

Crystal clear @Hendy!
Thank you very much for confirming the same issue.

[alecrt]

Hi @Hendy
any news on this?

[HeinPauwelyn]

@Hendy will this issue been solved?

[mirhat]

I too am having this problem